add-skilllisted

# add-skill Builds one production-quality skill in `skills/<name>/`, eval-first. Read `docs/skill-authoring.md` and `docs/evals.md` once per session before starting; they are the rulebook this workflow enforces. If invoked as `/add-skill <args>`, treat `$ARGUMENTS` as the skill name or idea to scope in step 1. ## When NOT to use - Creating a new skills *repository* → that happens in the workspace above this repo. - Infrastructure work (hooks, CI, validator, docs) → plain editing, PR-level scrutiny. - A "skill" that merely restates what the model already does well → don't build it; a skill must fix a specific observed failure. ## Workflow 1. **Scope, and pick the invocation mode.** State in one sentence what the skill does and the concrete failure it fixes. If the sentence needs "and", split into multiple skills and do them one at a time. Check `skills/` and the README catalog for overlap — near-neighbor descriptions steal each other's triggers; adjust scope or plan disjoint wording. Then decide *who invokes it*, because it changes the name, the description, and the eval set: **model-invoked** (default) or **user-invoked** (`disable-model-invocation: true` — the user types `/name`; correct for side-effecting skills and memorable commands). See the mode table and the alias-over-engine split in `docs/skill-authoring.md`. 2. **Gather.** Read `.local/` recursively — every subfolder and file is source material (research, examples, constraints). The