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.** 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. 2. **Gather.** Read `.local/` recursively — every subfolder and file is source material (research, examples, constraints). Then research beyond it: web-search the topic for current facts, official docs, and prior art; verify anything load-bearing against primary sources, and cross-validate contested or high-stakes facts (external APIs, schemas, security claims) with /cross when available. Verified facts a skill depends on go into `skills/<name>/references/` as cleaned, tracked files — never ci