feat(skills): ship adopter-facing agent skills, installed by init

[tpouyer]

An adopter meets this framework through a CLI with 30-odd commands, a lifecycle module written in
Python, and docs/extending.md. What they do not get is anything their AI client can read to help
them use it — so the client either guesses at the framework or the adopter reads the docs to it.

Ship skills for that, in the repository, installed by init.

Shape

• A skills/ directory at this repository's root, one directory per skill.
• init installs them into the adopting repository at a path their client already reads:
  .claude/skills/ for Claude Code, .agents/skills/ for clients reading the neutral location.
  Installed there, they load automatically — no configuration step, which is the whole point (O2).
• Also installable from skills/ directly, outside init, for a repository that adopted before
  this existed or wants only some of them.

Two areas

1. General use. Installing, init, history, implement, fix, review, doctor,
provision, report, eval. What an adopter does in their first month.

2. Advanced use. Extending without forking (O8): custom prompts and bodies, a verb the
framework does not ship, a strategy, a pack, a review lens of one's own (O9).

The rule that decides what goes in them

Deterministic scripts for everything a script can do; model prose only where a script genuinely
cannot. That is O7 applied to the skills themselves — "what part of this is arithmetic wearing a
prompt?" — and it is what separates a skill from a wall of documentation with a YAML header.

Most of what an adopter needs is deterministic and already exists as a command: doctor answers
whether the controls are in place, ls renders the container, show-prompt renders a composition,
report counts runs. A skill whose body re-describes those in prose is a second, staler copy of
--help. A skill that runs them, reads the output and tells the adopter what to do about it is
worth having.

Prose earns its place where judgment is genuinely required: which strategy suits a verb, whether a
lens is worth adding, why a refusal is the control working rather than a bug.

Open questions

Genuinely open, and the issue should not pretend otherwise:

• How they are packaged. The ask names installing from skills/ "using npm skillz". Whether
  that is a specific tool, an npm package this repository publishes, or a plain copy performed by
  init needs settling before anything is built — it decides whether skills/ has a
  package.json, and whether a non-init install is a documented command or a third-party tool's
  concern.
• Two locations or one canonical plus a copy. .claude/skills/ and .agents/skills/ holding
  the same content is two copies in an adopter's repository, and two copies drift. A symlink, a
  single canonical location with the other pointing at it, or init --skills <path> are all
  answers; which one depends on what clients actually tolerate.
• Whether they are versioned with the framework. A skill describing in-lockstep implement is
  wrong the day a flag changes. _write_trampoline pins the framework version into what it writes
  for exactly this reason. Do skills pin too, and does doctor notice when installed skills are
  older than the installed framework?
• What keeps them true. A skill that names a command or a flag which no longer exists is the
  README capability matrix's problem in a new place, and GATE-DOCS-1 already solves that shape:
  a runs row must name a symbol or command that exists. The same walk over the skills is the
  obvious candidate, and without something like it these go stale silently.

Acceptance

• skills/ exists at this repository's root with the two areas covered, and every skill that can
  be a script is a script.
• init installs them where the adopting repository's client reads them, and says it did.
• A test walks the skills and fails on a command, flag or symbol that does not exist — the
  GATE-DOCS-1 shape, so a skill cannot name something the framework stopped shipping.
• The packaging question above is answered in the issue before the code, not discovered during it.

Objectives

O2 — onboarding is light. What a person has to work out for themselves should be the thing
nobody could have discovered for them, and "which command answers this" is not that. O8 —
extended without forking, and the path to do it is discoverable without reading our source; a skill
is that path arriving where the adopter already is. O7 — deterministic first, applied to the
skills themselves rather than only to the verbs.