feat(specify): add spec-production entry path; split brainstorm

Add `specify` as a third co-equal entry path into the dev cycle: it
produces an approved spec from already-settled sources (an exhaustive
issue, a long in-context design discussion, or a design brainstorm just
ratified) with review but no interview. This is the producing half of a
deliberate deciding/producing split — `brainstorm` shrinks to optional
discovery, `specify` becomes the sole spec-production gate before
`planner`, mirroring the RED->GREEN split that keeps tdd/debug honest.

What moved:
- brainstorm/SKILL.md: stripped of the hard-gate, the acceptance
  criterion, write-spec, self-review, grounding-check, user-review, and
  planner-handoff steps; terminal state is now handing a ratified design
  narrative to specify. Steps renumbered 1-5 (production steps left).
- specify/SKILL.md (new): the production core, with a precondition gate
  (Step 1.5) that bounces to brainstorm the moment the sources do not
  resolve a load-bearing decision — the same discipline tdd uses.
- The grounding-check agent moved brainstorm/agents/ -> specify/agents/
  (no-orphan-agents: it lives under its dispatcher), refs repointed.
- boss/SKILL.md: Entry-path reflection is now three-way (tdd / specify /
  brainstorm). specify dispatches autonomously (bounded, no interview)
  and pauses at its user-review gate; only a fresh brainstorm cycle
  stays a pre-dispatch bounce-back.
- pipeline.md, README, profile-schema, the profile template, and the
  migration layout updated so every pipeline rendering agrees; specify
  is a CORE node (not opt-in, unlike tdd) carrying gates: [planner].

Design alternative rejected: parallel sibling skills sharing a
docs/spec-production.md (extract-to-doc). Chosen extract-and-chain
instead — the shared surface is ~70%, so a shared doc would either
become the skill body or drift; chaining keeps one executed home for the
gates.

Verification (prose repo, no test suite): the spec's internal-
consistency grep suite (no two-path drift, no direct brainstorm->planner
edge, specify referenced in every rendering, grounding-check single home
under specify, specify structural completeness) all green. Orchestrator
inspection additionally fixed two dead step-refs the plan under-scoped
(a "(Step 4)" lift-validation pointer and a "Skipping Step 7
self-review" red flag, both pointing at steps brainstorm no longer has)
and corrected six pre-existing brainstorm->planner renderings in
pipeline.md and tdd that predated this cycle.

Known follow-ups (non-blocking): the committed spec writes
`skills/specify/` in places (typo; skill dirs are repo-top-level) — to
be corrected separately. The grounding-check hard-gate was degenerate
for this very cycle (this repo has no profile and no test suite); the
skip is documented in the spec and the session.

tdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tdd
-description: Use when a feature description or tracker issue has test-specifiable behaviour — the "how it should work" can be pinned as a single failing test. Authors a minimal RED executable-spec and hands the GREEN side to implement mini-mode, exactly as a bug fix is handled. The alternative entry path to brainstorm→planner for test-specifiable work; bounces back to brainstorm the moment the behaviour is not test-specifiable (genuine design forks). Distinct from the per-task TDD the implementer already practices inside implement.
+description: Use when a feature description or tracker issue has test-specifiable behaviour — the "how it should work" can be pinned as a single failing test. Authors a minimal RED executable-spec and hands the GREEN side to implement mini-mode, exactly as a bug fix is handled. The alternative entry path to brainstorm→specify→planner for test-specifiable work; bounces back to brainstorm the moment the behaviour is not test-specifiable (genuine design forks). Distinct from the per-task TDD the implementer already practices inside implement.
 ---
 
 # tdd — executable-spec-first entry path
@@ -11,7 +11,7 @@ description: Use when a feature description or tracker issue has test-specifiabl
 
 For work whose desired behaviour is expressible as a test, the
 test *is* the spec. This skill is the alternative to the
-`brainstorm → planner` design path: instead of a prose spec the
+`brainstorm → specify → planner` design path: instead of a prose spec the
 user approves, it produces a single minimal **RED executable-spec**
 that says "this is how it should work", then treats that test
 exactly like a bug to be fixed — handing the GREEN side to the
@@ -74,7 +74,7 @@ prevent, and it is no less a failure for being dressed as a test.
 This skill is an opt-in entry path. A project enables it by
 listing a `tdd` phase in its profile `pipeline:` block (see
 `docs/profile-schema.md`); a profile that omits it keeps
-`brainstorm → planner` as the only design entry path.
+`brainstorm → specify → planner` as the only design entry path.
 
 ## The Iron Law
 
@@ -153,7 +153,7 @@ orchestrator:
    worse than no test).
 2. Invokes `brainstorm` with the design question the agent
    surfaced as the cycle request. From there the normal
-   `brainstorm → planner → implement` path runs.
+   `brainstorm → specify → planner → implement` path runs.
 
 The bounce-back is not a failure of this skill; it is the skill
 correctly refusing to ratify an un-chosen design into a test.
@@ -211,6 +211,11 @@ iteration and gets queued for a separate one.
   This is the same mini-mode handoff `../debug/SKILL.md` uses.
 - **Bounce-back target:** `../brainstorm/SKILL.md` — reclaims the
   work when the behaviour is not test-specifiable.
+- **Sibling fast path:** `../specify/SKILL.md` — the other bounded
+  entry path that shares this skill's bounce-to-`brainstorm`-on-fork
+  discipline. Where `tdd` owns work whose behaviour one assertion can
+  pin, `specify` owns work whose design the sources already resolve;
+  both fall back to `brainstorm` when their precondition fails.
 - **Sibling RED-first skill:** `../debug/SKILL.md` — same two-stage
   RED→GREEN shape, but triggered by an observed bug rather than a
   new-behaviour description.