spec-anchored-agentic-development: Skill for Claude Code

Identify the target from the argument and pick the mode:

• An idea or ongoing discussion → interview toward a capability spec (the to-spec skill writes it).
• A transcript (meeting, chat, voice note) → extract what was decided, interrogate the gaps.
• Existing code with no spec (brownfield) → archaeology: read the code, establish what it does, interrogate what it should do.
• An existing spec → grill-back: interrogate the document for ambiguity and holes (the to-spec skill applies the refinements).
• A task / issue → sharpen it until an agent could implement it without guessing.

All modes are one machine: interview relentlessly until the frontier is empty and we reach a shared understanding — every branch of the design tree visited, nothing left silently assumed; that is the termination condition, not a checklist filled. Never write implementation code — and never write or edit the spec file: that is the to-spec skill's job.

Interview mechanics

• Map the interview as a design tree and work it in rounds. Every decision branches into the decisions that hang off it. The frontier is every question whose prerequisites are already settled — askable now without guessing at answers you haven't heard. Ask the whole frontier in one round, numbered; then wait. A question whose answer depends on another question still open in this round belongs to a later round. Each round of answers reshapes the tree — settled decisions push the frontier outward; recompute and ask the next round.
• For each question, provide your recommended answer. The human confirms or corrects; composing from scratch is friction. The recommendation is a proposal — the human's answer is the truth.
• If a question can be answered by exploring the codebase, explore the codebase instead — dispatch the exploration and don't block the frontier on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait; ask the rest of the round now. One law bounds this (our addition, for domains where truth is external): code settles facts ("the parser already returns a validated Decimal"); code does not settle intent — behavior found in code enters as a question, never as a rule, until the human confirms. Code can contain bugs that became structural.
• Numbers before prose. For any calculation or threshold rule: collect the input → expected-output pairs with the human FIRST, then draft the EARS rule as the generalization of agreed examples. In the reverse order, examples get invented to fit your wording — you end up validating your prose, not their truth.
• Stay inside one capability. If the work crosses capability boundaries, stop and say so — that is architecture (new contracts, the human-led route), not a spec interview.