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.
git clone --depth 1 https://github.com/GregorBiswanger/featherspecWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/gregorbiswanger/featherspec/sdd-architecture-scan)<a href="https://agentmods.dev/commands/gregorbiswanger/featherspec/sdd-architecture-scan"><img src="https://agentmods.dev/badge/commands/gregorbiswanger/featherspec/sdd-architecture-scan.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00024 | $0.04259 |
| Opus 5 | $0.00012 | $0.02129 |
| Sonnet 5 | $0.00005 | $0.00852 |
| Haiku 4.5 | $0.00002 | $0.00426 |
Grade A, and why
sdd-architecture-scan 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 8d 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 — 280 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/sdd-architecture-scan — Deep Architecture Scan
The user may name a focus path after the command; then every phase below applies to that subtree only, and the final merge touches only its entries.
Speak plainly, in DocLanguage, throughout: assume the user has never seen this
workflow. Every question and every gate opens with one short line saying why it is
asked and what the answer changes, and every term of art (worklist, unit, tier,
scout) gets a one-clause introduction on first use. Minimal and precise — one line
of why, never a lecture.
Where am I? (state router — the files decide, not the conversation)
- No
.sdd-scan/_worklist.md→ run Phase A, then stop at the worklist gate. - Worklist exists with pending units → run Phase B on pending units only.
- All units done but the update merge not yet confirmed → run Phase C. The user saying "distill what we have" also runs Phase C — a full re-distillation from the reports, even after a confirmed merge; refreshing dates or markers alone is not a distillation. Otherwise, after a confirmed merge, a re-invocation has nothing left but the cleanup question.
On a fresh start — say what this buys and costs (once, in DocLanguage)
On a fresh start (no worklist yet) this briefing is the first visible output —
before any question and before Phase A runs, and equally when /sdd-setup routed
here. Three short, plain points (~6 lines total), then proceed:
- Value: the fingerprint replaces exploration. Agents in every later session — in both tools — jump straight to the right place instead of searching, and technical planning (specs, reviews, onboarding) starts from a shared, verified map.
- Cost: the scan is token-intensive — scouts read code in isolated contexts. Name a planning figure (~50k tokens per analysis unit; large repositories multiply), say that cost scales with the models in use and can get expensive, and that a capable model pays off for synthesis while the scouts inherit the session model — choosing a cheaper model for the scan session, or pinning one locally in the scout agent files, is the biggest cost lever.
- Levers: the worklist gate is the cost dial — defer units (they stay visible under
unmapped:), setshallowtiers for periphery, rescan later with a focus path; the scan resumes from its files at any point.
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.
- 8d ago First seen · 280 lines · 24 tokens per session scan A 9133e6fd01c2
sdd-architecture-scan is a command published in the GitHub repository GregorBiswanger/featherspec (48 stars, last pushed 8d ago), licensed MIT. It adds 24 tokens to every session and 4,259 once invoked, about $0.0001 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-30.
Other commands, from other repositories
speckit.companion.doctor
Report on a spec's run health — unfinished steps, unjournaled tasks, step bleed, drift you can judge, a step that closed having verified nothing, a step that closed without the file it promised, and why completion did not land (read-only, retroactive, never halts).
kiro-validate-gap
Command "kiro-validate-gap" from gotalab/cc-sdd, covering implementation gap validation, core task, execution steps, important constraints and tool guidance.
sddp-prd
Command description: Create or refine the canonical product document. Argument hint: [rough product idea, users, domain, or market opportunity] Command category: project-bootstrap Prerequisites: none.
sddp-specify
Command description: Create a feature specification from a feature description. Argument hint: [feature description] Command category: feature-delivery Prerequisites: project-instructions.
sddp-amend
Command description: Propagate a bootstrap change across canonical project artifacts and the project plan. Argument hint: [project-level change to propagate across bootstrap artifacts] Command category: project-bootstrap Prerequisites: project-instructions, product-document, technical-context, project-plan.
sddp-systemdesign
Command description: Create or refine the canonical software architecture document. Argument hint: [project description, docs, constraints, or architecture inputs] Command category: project-bootstrap Prerequisites: none.