--- name: specify description: Use when the design is already settled — a long in-context design discussion, an exhaustive tracker issue, or a ratified design handed over by brainstorm — and a spec must be produced from those sources with review but without an interview. The spec-production core: applies the feature-acceptance criterion, writes the spec under docs/specs, runs the parse and grounding-check gates, takes user sign-off, hands off to planner. Bounces to brainstorm the moment the sources do not resolve a load-bearing design decision. Co-equal third entry path alongside brainstorm and tdd. --- # specify — spec-production entry path > **Violating the letter of these rules is violating the spirit.** ## Overview `specify` is where a settled design becomes an approved spec. It takes **given sources** — a long in-context design discussion, an exhaustive tracker issue, settled design docs, or a ratified design narrative handed over by `brainstorm` — and produces the spec the planner consumes: with review, but **without an interview**. It is the **sole home of the spec-production gates**: the feature-acceptance criterion, the write-spec step, the `grounding-check` hard-gate, and the user-review gate. Whichever way design work enters — fresh through `brainstorm`'s discovery, or directly from sources that already resolve the design — it passes through `specify` to become a spec. `specify` carries the universal invariant **no plan without an approved spec**. `specify` is the *producing* half of a deliberate split. `brainstorm` owns *deciding* — interview, approaches, ratification. `specify` owns *producing* — rendering that decision into the canonical artefact and clearing the gates. The split is the toolchain's deepest discipline applied one level up: `tdd → implement` and `debug → implement` split RED from GREEN across two dispatches so the spec stays honest; `specify` splits deciding from producing so the producing phase reads the decision as a *source* rather than making it inline. `specify` is a core pipeline node: it is the gate before `planner` on every design path that is not a bug fix or a test-specifiable feature. Where `tdd` is one entry path among three (chosen when behaviour is test-specifiable), `specify` sits on every prose-design path — it is not bypassed for those. ## When to Use / Skipping Triggers: - The design is settled in the sources and a spec must be written: an exhaustive issue body, a long in-context design discussion, or a ratified design `brainstorm` just handed over. - A cycle-scope spec is missing for settled work and one is needed. **Use the named alternative instead for:** - A genuine design fork — the sources do **not** resolve a load-bearing decision. Use `brainstorm` (its discovery is what resolves the fork). `specify` itself bounces here the moment it detects this (see The Iron Law and Step 1.5). - A test-specifiable feature — the RED executable-spec is the spec. Use `tdd` directly. - An observed bug — use `debug` directly (RED-first). - A tidy iteration — use `audit` directly. - A trivial mechanical edit — per the project's CLAUDE.md carve-out. **Skipping a gate is never permitted.** The interview is `brainstorm`'s, and its absence here is the whole point — but the *production gates* (criterion, grounding-check, user-review) are non-negotiable regardless of how the work entered. "The issue looks exhaustive, skip the grounding-check" is the reactive-deference failure this skill must not reintroduce. ## The Iron Law ``` THE SOURCES MUST RESOLVE EVERY LOAD-BEARING DESIGN DECISION BEFORE THE SPEC IS WRITTEN. IF WRITING THE SPEC FORCES A CHOICE BETWEEN PLAUSIBLE DESIGNS THE SOURCES DO NOT RESOLVE, STOP AND BOUNCE TO brainstorm. DO NOT SILENTLY PICK ONE. THE PRODUCTION GATES — ACCEPTANCE CRITERION, GROUNDING-CHECK, USER-REVIEW — ARE NON-NEGOTIABLE REGARDLESS OF ENTRY PATH. NO PLAN, SCAFFOLDING, OR DOWNSTREAM SKILL UNTIL THE SPEC IS APPROVED — BY THE USER, OR (UNDER /boss) BY THE AUTO-SIGN GATE: ALL OBJECTIVE GATES GREEN AND A UNANIMOUS ADVERSARIAL spec-skeptic PANEL. MODEL SELF-CONFIDENCE ALONE IS NEVER APPROVAL. ``` Every clause is non-negotiable. The precondition gate is what makes the no-interview path legitimate rather than merely convenient: it is the honest fork-check that `tdd`'s "is this test-specifiable?" is for test work. ## The Process ### Step 1 — Explore / re-ground context Before producing anything, establish what the sources actually say: - **Direct entry** (from sources): read the sources in full — the tracker issue body, the in-context design discussion, any settled design docs. This IS the design input. Then `git log -5 --format=full` for the current state of the project. - **Chain entry** (from `brainstorm`): the ratified design narrative is already in-context. Re-ground lightly — fresh `git log`, the files the design touches — rather than re-deriving it. - If the project has a design ledger (its CLAUDE.md project facts), walk to the contracts the work touches. Note any `status: aspirational` source: its code is a target, not verified fact. ### Step 1.5 — Precondition gate (bounce-back) Enumerate the **load-bearing design decisions** the spec must encode — the choices that, decided differently, would change what ships. For each, ask the honest question: > Do the sources **resolve** this, or am I about to **pick** it > myself? If every load-bearing decision is resolved by the sources, proceed to Step 2. If even one is unresolved — the sources leave a genuine fork between plausible designs with real trade-offs — **STOP and bounce to `brainstorm`** (see Error handling / The Bounce-Back). Do not silently pick one and bake it into the spec; a guessed design ratified into a spec is harder to dislodge than an open question, and it is exactly the reactive-deference failure the gate exists to prevent. Genuine doubt about whether the sources resolve a decision *is itself* the fork signal — it resolves to a bounce, not to a guess. **Reconciliation comment (lagging-issue case).** A load-bearing fork can be resolved by the in-context design discussion yet still be listed *open* by the tracker issue that seeded the cycle — the issue lags the conversation. When that holds (entry is in-context **and** a tracker issue still carries a now-resolved fork as open), record the resolution as an auditable issue comment **before** writing the spec, via the project's issue-tracker comment command (`tea comment ` for Gitea; a heredoc body per the `issue` skill's conventions). One comment, this exact shape: ``` ## Design reconciliation (specify, in-context entry) Spec: . The fork(s) below are still listed open on this issue; they were resolved in the in-context design discussion. - **Fork: ** → . Provenance: . ``` The comment must carry **provenance**, and the distinction is load-bearing: it is the *record of a user decision* (legitimate — the user settled the fork in discussion, you are minuting it), never a *new orchestrator decision* dressed as settled (illegitimate). A bare `decision: B` with no provenance is the latter. If you cannot point to a real user statement, that is the signal that *you* picked the fork, not the user — which is a Step-1.5 bounce, not a comment. The comment is *persistent and auditable* (author + timestamp, in the forward queue) — which is exactly why it, and not your ephemeral confidence, is what a downstream `scope-fork` juror reads to confirm the fork is settled (see Step 6). Recording it keeps the forward queue honest in either run mode; under `/boss` it is *load-bearing* — without it the `scope-fork` juror sees only the stale issue body and (correctly) blocks. Provenance enforcement is not yours to self-certify: you *write* the comment, the adversarial `scope-fork` juror *checks* it carries provenance (Step 6). Writing a provenance-less comment does not buy a pass — the re-dispatched juror blocks on it. Gitea writes are pre-authorized (per `~/.claude/CLAUDE.md`); post the comment without a confirmation prompt. **Issue-less in-context entry.** If the cycle has *no* tracker issue — the design was settled in pure chat — there is no existing artefact to comment on, so *create one*: open a new tracker issue that records the resolved fork(s) with provenance, under the same discipline as the reconciliation comment above. The body takes this shape: ``` ## Design record (specify, issue-less in-context entry) This issue seeds . The design was settled in an in-context discussion with no prior tracker issue; this records it. Load-bearing fork(s) resolved: - **Fork: ** → . Provenance: . ``` The body names the *work*, not the spec file — the spec does not exist yet at Step 1.5 (its number is assigned only in Step 3). This new issue is the cycle's seeding issue from here on: the `scope-fork` juror reads it via the project's issue show command — its index handed to the juror in the Step-6 carrier (the `seeding_issue` field, below) — exactly as it reads any seeding issue. A *new issue* is the right artefact where a spec-note is the wrong one — a provenance note *inside the spec* is self-referential (the spec asserting its own sources settle it) and stays banned, but a separate issue is independent (author + timestamp, in the forward queue, juror-readable without opening the spec), as auditable as a reconciliation comment. Creating it is what lets the `scope-fork` juror ratify the resolution here, instead of blocking for lack of an auditable source. The provenance gate is unchanged and load-bearing: the new issue records *user* decisions, never fresh orchestrator ones. No real user statement for a fork means *you* picked it — a Step-1.5 bounce, not an issue to manufacture. You *write* the issue; the adversarial `scope-fork` juror *checks* the provenance, and a provenance-less body buys no pass. Create it via the project's issue-create command (the `issue` skill's mechanics — `tea issues create` for Gitea), title and label per the project's vocabulary as in the Step-5 failure-mode procedure. Gitea writes are pre-authorized, so create it without a confirmation prompt. **Capture the new issue's index** the moment it is created and carry it into the Step-6 panel as the `seeding_issue` field — it is the only way the `scope-fork` juror knows which issue to read. An issue created but never handed to the panel is invisible to the juror, which leaves the fork looking picked and the creation pointless. ### Step 2 — Apply the project's feature-acceptance criterion The project's `CLAUDE.md` declares the criterion a feature must satisfy to ship. Apply it now, prospectively. The typical shape is some combination of: - the project's intended audience naturally reaches for the feature, - the feature measurably improves correctness or removes redundancy, - the feature reintroduces no class of failure the project's core constraint exists to eliminate. If the project declares no criterion, the default is "the feature solves a real user-facing problem and does not contradict a stated design commitment". The orchestrator applies the criterion; do not delegate it to the user. **The criterion is unjudgeable without concrete code.** For any cycle with authoring or consumer surface, the spec MUST contain the actual program / invocation / configuration a user would write — and that example *is* the criterion's empirical evidence. A prose assertion ("a user naturally reaches for X") with no shown code is the unfalsifiable hand-wave the criterion exists to prevent: write the code the user would write, then judge whether it is what the criterion demands. For an infrastructure cycle with **no** user surface there is still concrete code: show the code the cycle *delivers* — frequently a test fixture whose correct behaviour is rejection — plus a *minimal, honest* slice of the north-star program the infrastructure serves. "No surface so no code to show" is the rationalisation to refuse. **Code lifted from an aspirational source is a hypothesis, not evidence.** If the concrete code here is lifted from a design-models file (or any `status: aspirational` source, per Step 1), it carries no validation by default. Treat it as the spec's most suspect bytes: flag it as a target, not verified fact. ### Step 3 — Write the spec Path: under `docs/specs`, named per the fixed naming convention — `NNNN-slug.md`, 4-digit per-directory counter (see `docs/conventions.md`). Determine the next free number by scanning the directory. Structure: ```markdown # — Design Spec **Date:** YYYY-MM-DD **Status:** Draft — awaiting user spec review **Authors:** orchestrator + Claude ## Goal ## Architecture ## Concrete code shapes ## Components ## Data flow ## Error handling ## Testing strategy ## Acceptance criteria ``` `## Concrete code shapes` is mandatory and **leads with the user-facing program**: the worked author example for a surface cycle (= the Step-2 empirical evidence), or — for a no-surface infra cycle — the code the cycle *delivers* (often a must-fail fixture) plus a minimal honest north-star slice. The before → after implementation shape (struct / signature / match-arm) for each load-bearing change follows as an explicitly secondary subsection, never first. Prose may *explain* code, never *replace* it. Exact bytes / line-numbers remain the planner's job — the spec owns the *shape*, shown. ### Step 4 — Self-review Inline checklist (not a subagent dispatch): 1. **Placeholder scan:** any "TBD", "TODO", incomplete sections, vague requirements? Fix. 2. **Internal consistency:** sections must not contradict. Architecture must match component descriptions. 3. **Scope check:** focused enough for one plan, or does it need sub-cycle decomposition? 4. **Ambiguity check:** could any requirement be read two ways? Pick one and make it explicit. 5. **Concrete-code check:** does `## Concrete code shapes` exist and carry before → after code for every load-bearing change (plus the worked user-facing example for a surface cycle)? A load-bearing change described only in prose is a self-review failure to fix. Fix issues inline. ### Step 5 — Grounding-check (hard-gate) Dispatch the read-only `grounding-check` agent. The agent reads the just-written spec with fresh context, extracts its load-bearing assumptions about *current* behaviour of the codebase, and for each searches the workspace for a currently-green test that ratifies it. Dispatch carrier — the fields `spec_path` and `iteration_scope`, defined authoritatively under **Carrier contract** in `agents/grounding-check.md` (note `spec_path` is an *absolute* path). That table is the single source for those fields; it is deliberately not restated here, so the two files cannot drift. The agent returns `PASS` / `BLOCK` / `INFRA_ERROR`. Interpretation: | Agent status | Orchestrator action | |--------------|---------------------| | `PASS` | Proceed to Step 6. The report goes into the chat for the record. | | `BLOCK` | Present the report to the user. User either: (a) accepts discard → execute the failure-mode procedure below; or (b) overrides in free chat ("Test `<path>::<name>` ratifies that") → log the override note and proceed to Step 6. | | `INFRA_ERROR` | Abort. The spec stays as-is on disk; debug the workspace out-of-band and re-dispatch the agent. | **Failure-mode procedure (no-override `BLOCK`):** 1. Delete the just-written spec file from the working tree (`rm <spec_path>` — a shell delete, NOT `git rm`; never committed). 2. Open a backlog issue (via the project's issue-tracker create command) pointing forward to a future re-design. Include: - **Title:** one-line identity of the deferred work - **Label:** matching the project's vocabulary (`feature` / `bug` / `idea`; promote to `BLOCKER` if the unratified mechanism is on a core-functionality path) - **Body:** short description plus two structured lines: - `depends on: <name of the unratified mechanism>` - `context: <why this is deferred>` If the deferred work needs its own spec on resumption (multi-iteration, cross-subsystem), file it as a **milestone container** instead of a single issue. 3. Tell the user the spec was retired and which backlog entry was filed. No commit is needed — the issue tracker is the live store. After the failure-mode procedure runs, the session ENDS. There is no Step 6, no Step 7. The idea is parked until the dependency ships. **Re-dispatch on any post-PASS edit.** The PASS report is bound to the exact bytes of the spec at dispatch time. Any subsequent edit — polish, a user-requested change, a wording tighten — invalidates the PASS report and requires a fresh dispatch of `grounding-check` before the Step-6 sign-off and commit. Step 5 is the *last* step that touches the spec file; nothing slips between it and the commit. ### Step 6 — User-review gate The spec sits in the working tree as an unstaged file. Tell the user: > Spec written to `<path>` (uncommitted). Please review it and let me > know if you want changes before we start the implementation plan. > The orchestrator will commit it once you approve. Wait for the user's response. If they request changes, edit the file in place (still uncommitted), **re-run Step 4 AND re-dispatch Step 5** (the previous PASS report no longer covers the edited bytes), then return here. Only proceed after approval AND a fresh Step 5 PASS. The orchestrator commits the approved spec after sign-off (suggested commit subject: `spec: <cycle> <topic>`). The skill does not perform the commit itself. The spec is an ephemeral active-cycle artefact: it lives in the repo only for its own cycle and is `git rm`'d at cycle close (see `docs/conventions.md` § Lifecycle). **In `/boss` (autonomous):** `specify` is dispatched autonomously — it is bounded (no interview). It runs the criterion, parse, and grounding-check gates without a checkpoint. At *this* gate the orchestrator signs in the user's place, but only through the **auto-sign gate** below — never on its own confidence. The gate exists because the orchestrator that wrote the spec is the worst-placed party to judge it, so it is built to *not* rely on that confidence. The human sign-off pause is not the default here; it is where the gate **escalates** — a spec that cannot clear the gate routes to a problem-state notify ("spec X ready, please sign off") and waits for the user, exactly as a plain pause would. Run the gate in two stages: 1. **Objective gates (all must already hold — these are facts, not judgements):** - Step 1.5 precondition gate passed cleanly — no load-bearing fork was silently picked (if one had been, `specify` would have bounced, so reaching here is the evidence; do not re-decide it). - Step 4 self-review clean, **including the placeholder scan** (no `TBD` / `TODO` / incomplete section). - Step 5 `grounding-check` returned **`PASS`** — *not* an overridden `BLOCK`. An override needs a human; with no human in the loop a `BLOCK` can never be overridden, so any non-`PASS` grounding result denies auto-sign outright. If any objective gate is not green, **do not run the panel** — fall straight to the human sign-off pause (the default-slot behaviour above), carrying the failing gate in the notify. 2. **Adversarial panel (unanimous-or-nothing):** dispatch the read-only `spec-skeptic` agent **five times in parallel**, once per lens — `criterion`, `grounding`, `scope-fork`, `ambiguity`, `plan-readiness`. Carrier per dispatch: `spec_path` (absolute), `iteration_scope`, the single `lens`, and `seeding_issue` — the index of the cycle's seeding issue (the lagging issue reconciled in Step 1.5, the issue Step 1.5 created for an otherwise issue-less cycle, or `none` if the cycle has neither) for the `scope-fork` juror to read; the other four lenses ignore it. Each juror tries to *refute* the spec along its lens and returns `SOUND` / `BLOCK` / `INFRA_ERROR`. Auto-sign requires a **unanimous `SOUND`** — that never changes. What the partition below adds is a bounded path to *reach* that unanimity for defects the orchestrator can repair without judging the spec. The five lenses split by what a `BLOCK` actually means: | Lens class | Lenses | A `BLOCK` means | |------------|--------|-----------------| | **Editorial** | `criterion`, `ambiguity`, `plan-readiness` | The spec is under-*articulated*: missing worked evidence, a requirement readable two ways, scope too broad for one plan. Repairable by editing the prose without settling any new design or fact. A `criterion` repair may only *supply or sharpen the worked evidence the criterion already demands* (paste the concrete before → after / user-facing code the spec implied) — it may **not** soften what the criterion requires or re-judge acceptance, and if the missing evidence cannot be shown without picking an un-settled design, that is a `scope-fork` in disguise: leave it, and the re-dispatched `scope-fork` juror escalates it. | | **Design** | `scope-fork`, `grounding` | The *ground is not settled*: the sources do not resolve a load-bearing fork, or a load-bearing assumption is not ratified by a green test. The orchestrator may **never** settle these in the user's place. | Resolve the panel against that split, in a bounded loop (`round` starts at `0`): | Panel outcome this round | Orchestrator action | |--------------------------|---------------------| | All five `SOUND` | **Auto-sign.** Commit the spec yourself (subject `spec: <cycle> <topic> (boss-signed)`), send the informational auto-sign notify (see `boss` § Notifications — names the capability in user terms and states the plan is proceeding and a reply vetoes), then proceed to Step 7. No pause. | | Any `INFRA_ERROR` | **Escalate.** Fall back to the human sign-off pause; the notify carries the failing dispatch. | | Any **design**-lens (`scope-fork` / `grounding`) `BLOCK` | **Escalate.** No self-correction — this is exactly the judgement the gate refuses to make for the user. Fall back to the human sign-off pause, carrying *all* lens findings this round. | | Only **editorial**-lens `BLOCK`(s), and `round == 2` | **Escalate.** The self-correction budget is spent. Fall back to the human sign-off pause, carrying the findings *and* the per-round correction history. | | Only **editorial**-lens `BLOCK`(s), and `round < 2` | **Self-correct.** Edit the spec in place to address each editorial finding (each names its `§section` / offending text / defect). Then **re-run Step 4 self-review and re-dispatch Step 5 `grounding-check`** — the edit invalidated the prior `PASS` (see "Re-dispatch on any post-PASS edit"); if `grounding-check` does not return `PASS`, escalate. Increment `round` and re-dispatch all five lenses from the top of this table. | **Re-loop limit: ≤ 2 self-correction rounds. The 3rd unresolved editorial `BLOCK` escalates** — same shape as the per-task re-loop limit in the implement loop (`../implement/workflows/implement-loop.js`). Three properties keep this loop honest, not a way to grind the panel into submission: - **The panel stays the sole arbiter.** The orchestrator never judges the spec; it only edits in response to a juror's finding, and a fresh panel re-adjudicates. "The spec looks good to me" still never signs. - **Re-dispatch is all five lenses, every round.** This is the backstop. If an editorial repair silently *launders* an unsourced design decision into the spec (resolving an ambiguity by picking an un-settled fork), the re-run `scope-fork` / `grounding` jurors now `BLOCK` on it — and a design `BLOCK` escalates. The only thing the loop can converge to autonomously is a spec whose every lens is `SOUND` *and* whose only repairs were editorial. - **Escalation is the panel doing its job**, not a failure — it routes the spec to the human who was going to review it anyway, the moment a real design question surfaces or the budget runs out. **Auto-sign commits on `main` are forward-only like every other commit.** A later user veto is a forward correction (revert / revised spec / `git checkout` of downstream working-tree work), never a history rewind — same discipline as any other orchestrator call (see `boss` § Direction freedom). ### Step 7 — Hand off to `planner` The terminal state of `specify` is invoking `planner`. NO other skill is invoked from `specify`. NO direct jump to `implement`. Hand off carries: - path to the spec under `docs/specs` - iteration scope ("the first iteration covers section X+Y of the spec") ## The Bounce-Back `specify` returns to `brainstorm` whenever the precondition fails — the sources do not resolve a load-bearing design decision (Step 1.5), or a `grounding-check` `BLOCK` reveals an unratified mechanism the user does not override (Step 5 failure-mode routes to a re-design). On a precondition bounce: 1. Nothing was written yet (the gate fires *before* Step 3), so there is no working-tree artefact to discard. 2. Invoke `brainstorm` with the unresolved design question as the cycle request. From there the normal `brainstorm → specify → planner` 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 spec — the same discipline `tdd` applies when behaviour is not test-specifiable. ## Handoff Contract | Direction | Carrier | |-----------|---------| | user / issue (design settled) → `specify` | the sources: issue body, in-context design discussion, design docs | | `brainstorm` → `specify` | ratified design narrative (approaches chosen, constraints, sections approved) — in-context; brainstorm writes no spec file | | `specify` → `grounding-check` (Step 5) | `spec_path` (absolute) + `iteration_scope` | | `specify` → `spec-skeptic` panel (Step 6, `/boss` only) | `spec_path` (absolute) + `iteration_scope` + one `lens` per dispatch (five in parallel) + `seeding_issue` (index for the `scope-fork` juror to read, or `none`) | | `specify` → `planner` (Step 7, on PASS or overridden BLOCK) | path to spec + iteration scope | | `specify` → `brainstorm` (precondition bounce) | the unresolved design question as a cycle request; no spec written | | `specify` → issue backlog (Step 5, no-override BLOCK) | new issue naming the unratified dependency; spec file deleted from the working tree | ## Common Rationalisations | Excuse | Reality | |--------|---------| | "The issue looks exhaustive — skip the grounding-check / criterion too" | The interview is what `specify` skips, by design. The production gates are not the interview; they are what keeps the spec honest no matter how it entered. Skipping a gate because the sources look thorough is the exact reactive-deference failure this skill must not reintroduce. | | "There's a small open fork but the sources mostly decide it — I'll pick the rest" | "Mostly decided" with one real fork left is an unresolved design, and a guessed design baked into a spec is harder to dislodge than an open question. That is the bounce-back trigger — stop and go to `brainstorm`. | | "Genuine doubt whether the sources resolve this — but bouncing feels like overkill" | Doubt about whether the sources resolve a decision *is* the fork signal. It resolves to a bounce, not a guess. The bounce is cheap (nothing is written yet); a wrong guess in a ratified spec is not. | | "The shape is clear from the prose, I don't need to paste the code" | If it's clear, pasting it is free; if pasting it is hard, it wasn't clear. The acceptance criterion is unjudgeable without the worked code. | | "Just polishing a wording after PASS, no need to re-dispatch" | The grounding-check report attests to specific bytes. A polish edit changes the bytes; the attestation no longer covers them. Re-dispatch is cheap. | | "It's in a model doc / the design ledger, so it's canonical" | A `models` / RFC / proposal doc holds aspirational code — a target, not verified fact. Flag code lifted from a `status: aspirational` source as such; it is not ratified contract. | | "In `/boss` this spec looks solid — I'll sign and move on" | Your sense that it looks solid is the exact signal the auto-sign gate refuses to trust. Signing requires all objective gates green AND a unanimous `spec-skeptic` panel. If you find yourself wanting to sign on confidence, that is the cue to run the gate, not to skip it. | | "One lens blocked on something minor — I'll sign anyway since the rest passed" | The panel is unanimous-or-nothing by design. You never *sign over* a `BLOCK`. An editorial `BLOCK` you may *repair* (within the ≤ 2-round budget, with a full re-panel after); a design `BLOCK` routes to the human. Neither is overruling a juror — that is the whole point of replacing your eye with five independent ones. | ## Red Flags — STOP - An unresolved design fork silently picked instead of bounced (any flavour) - "The sources are thorough, skip a gate" thoughts (any flavour) - A load-bearing change described in prose with no before → after code block; a surface cycle with no worked user-facing example - Lifting code verbatim from a `status: aspirational` source without flagging it as a target, not verified fact - Editing the spec file after a Step 5 PASS without re-dispatching - (auto-sign) About to sign a spec in the user's place on confidence — without all objective gates green AND a unanimous `spec-skeptic` panel; signing over any `BLOCK`; self-correcting a *design*-lens (`scope-fork` / `grounding`) `BLOCK` instead of escalating; or re-dispatching only the blocked lens rather than all five, or past the 2-round self-correction budget - (auto-sign) Running the panel before the objective gates are green, or running it outside a `/boss` session (interactive runs take the user's signature directly) - Jumping straight from spec to `implement` (must go via `planner`) - Running an interview here (that is `brainstorm`'s job — if the work needs one, bounce) ## Cross-references - **Output target:** `../planner/SKILL.md` — only valid next skill. - **Discovery front-end / bounce-back target:** `../brainstorm/SKILL.md` — produces the ratified design `specify` consumes on the chain path, and reclaims the work when the sources do not resolve a design fork. - **Sibling fast path:** `../tdd/SKILL.md` — the same bounce-to-`brainstorm`-on-fork discipline, for test-specifiable work; its RED executable-spec is the spec, so it skips both `specify` and `planner`. - **Agent dispatched:** `agents/grounding-check.md` — dispatched in Step 5 as a hard-gate. Reads the spec with fresh context and reports PASS / BLOCK / INFRA_ERROR. - **Agent dispatched (auto-sign):** `agents/spec-skeptic.md` — dispatched in Step 6 five times in parallel (one per lens) under a `/boss` session. Each juror tries to refute the spec along its lens; a unanimous `SOUND` is what lets the orchestrator sign in the user's place. An editorial-lens `BLOCK` (`criterion` / `ambiguity` / `plan-readiness`) is self- corrected in a bounded loop (≤ 2 rounds, full re-panel each round); a design-lens `BLOCK` (`scope-fork` / `grounding`), an `INFRA_ERROR`, or an exhausted budget falls back to the human sign-off pause. - **Ad-hoc dispatch.** The orchestrator MAY also ad-hoc dispatch `../planner/agents/plan-recon.md` during Step 1 when the work enters code territory not recently read; discretionary, not part of the standard process. - **Project feature-acceptance criterion:** declared in the project's `CLAUDE.md`. Applied prospectively in Step 2.