Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/w00fx/spec-anchored-agentic-development/shapegit clone --depth 1 https://github.com/w00fx/spec-anchored-agentic-developmentWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00078 | $0.02330 |
| Opus 5 | $0.00039 | $0.01165 |
| Sonnet 5 | $0.00016 | $0.00466 |
| Haiku 4.5 | $0.00008 | $0.00233 |
Grade A, and why
shape scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 194 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Identify the target from the argument and pick the mode:
- An idea or ongoing discussion → interview toward a capability
spec (
/to-specwrites 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 (
/to-specapplies 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 /to-spec'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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 194 lines · 78 tokens per session scan A 02ec43af5a29
shape is a command published in the GitHub repository w00fx/spec-anchored-agentic-development (5 stars, last pushed 7d ago), licensed MIT. It adds 78 tokens to every session and 2,330 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
spec-kitty-standalone
This host should read Spec Kitty's canonical standalone-invocation skill pack at.
OPSX: Apply
Implement tasks from an OpenSpec change (Experimental).
research
Gather external knowledge into §R so build grounds in facts, not hallucinations. Every finding cites a source.
validate-design
Interactive technical design quality review and validation.
sync-linear
Sync current work with Linear ticket status.
kiro-validate-design
Command "kiro-validate-design" from gotalab/cc-sdd, covering technical design validation, core task, execution steps, important constraints and tool guidance.