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/habib0x0/spec-driven-plugin/spec-retrogit clone --depth 1 https://github.com/Habib0x0/spec-driven-pluginWrote 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/habib0x0/spec-driven-plugin/spec-retro)<a href="https://agentmods.dev/commands/habib0x0/spec-driven-plugin/spec-retro"><img src="https://agentmods.dev/badge/commands/habib0x0/spec-driven-plugin/spec-retro.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 | $0.00015 | $0.01223 |
| Opus 5 | $0.00008 | $0.00611 |
| Sonnet 5 | $0.00003 | $0.00245 |
| Haiku 4.5 | $0.00002 | $0.00122 |
Grade A, and why
spec-retro 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 3d 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 — 169 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/spec-retro Command
Analyze a completed spec's lifecycle to generate a retrospective — what went well, what caused friction, and what to improve next time. This closes the feedback loop for continuous process improvement.
Philosophy
Without retrospectives, the same mistakes repeat. This command automates the data gathering (progress logs, debugging cycles, reviewer rejections, spec changes) and facilitates a structured conversation about process improvements.
Workflow
1. Locate the Spec
If a spec name is provided, use it. Otherwise auto-detect from .claude/specs/.
2. Gather Data
Collect metrics from the spec's lifecycle:
From progress.md (append-only session log):
- Number of implementation sessions
- Tasks that required multiple attempts
- Integration issues logged
- Blockers encountered
From tasks.md:
- Total tasks planned vs. completed
- Tasks added mid-implementation (scope creep?)
- Task complexity distribution
- Which phases had the most tasks (Setup, Core, Integration, Testing, Polish)
From git log (use Bash):
- Number of commits for this feature
- Time span from first to last commit
- Frequency of "fix" or "debug" commits vs. feature commits
- Number of authors involved
From acceptance.md (if exists):
- First-pass acceptance rate
- Criteria that failed initially
From release.md (if exists):
- Any post-deployment issues noted
From spec history (if git tracks changes):
- Number of times requirements.md was modified after initial creation
- Number of times design.md was modified after initial creation
- Scope changes during implementation
3. Automated Analysis
Before involving the user, analyze the data for patterns:
Positive signals:
- High first-pass acceptance rate
- Few debugging cycles
- Tasks completed in order (good dependency planning)
- No spec modifications during implementation (requirements were solid)
Friction signals:
- Tasks requiring 3+ debugging cycles → requirements or design gap
- Reviewer rejections → implementation quality or spec ambiguity
- Many "fix" commits → incomplete testing or unclear acceptance criteria
- Spec modifications mid-implementation → requirements changed or were incomplete
- Integration tasks failing → architecture missed dependencies
- Scope additions → brainstorming/requirements phase was rushed
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.
- 3d ago First seen · 169 lines · 15 tokens per session scan A 5831d354b204
spec-retro is a command published in the GitHub repository Habib0x0/spec-driven-plugin (10 stars, last pushed 3mo ago), licensed MIT. It adds 15 tokens to every session and 1,223 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-31.
Other commands, from other repositories
receipts
Find the receipt. A dated line, or it did not happen.
sruja-bugfix-triage
Systematic workflow for triaging and fixing bugs with architecture grounding.
crossframe-essay
使用 CrossFrame Essay 把用户给出的主题、素材或问题写成中文批判性洞察文章。.
optimize-costs
Find cost savings in infrastructure without sacrificing quality or performance.
cost-estimate
Infrastructure + third-party + LLM token cost breakdown.
story-pack
读取：docs/story-$ARGUMENTS-.md、docs/GLOBAL-CONTEXT.md（只读）、docs/PRD.md（只读） | 写入：docs/story-$ARGUMENTS-exec-pack.yaml（仅 PASS 时写入；纯 YAML；不包含 ） | 模板：N/A.