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-acceptgit clone --depth 1 https://github.com/Habib0x0/spec-driven-pluginWhat 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.00907 |
| Opus 5 | $0.00008 | $0.00453 |
| Sonnet 5 | $0.00003 | $0.00181 |
| Haiku 4.5 | $0.00002 | $0.00091 |
Grade A, and why
spec-accept 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/spec-accept Command
Perform user acceptance testing (UAT) to verify the implementation satisfies all spec requirements. This bridges the gap between "code works" (spec-tester) and "the right thing was built" (acceptance).
Philosophy
Automated tests verify correctness. Acceptance testing verifies value. The spec-tester checks that code passes tests per task; the spec-reviewer checks security and code quality; the acceptor verifies that every EARS acceptance criterion in requirements.md traces to verified, reviewed tasks and that non-functional requirements are met. This is the last gate before release.
The acceptor does NOT re-run functional or security tests — it reads results from tasks.md (tester verification) and references reviewer assessments. It focuses on traceability, non-functional gaps, and formal sign-off.
Workflow
1. Locate the Spec
If a spec name is provided as an argument, use it. Otherwise:
- Check
.claude/specs/for available specs - If only one spec exists, use it automatically
- If multiple exist, ask the user which spec to accept via AskUserQuestion
2. Pre-flight Check
Read tasks.md and verify implementation status:
- If tasks are still incomplete, warn the user: "X of Y tasks are still incomplete. Acceptance testing works best on completed features. Want to proceed anyway or finish implementation first?"
- Use AskUserQuestion: "Proceed with partial testing" / "Finish implementation first"
3. Ask About Testing Scope
Use AskUserQuestion:
- Full acceptance test — Test all requirements and acceptance criteria
- Specific requirements only — Let me pick which requirements to test
- Non-functional requirements only — Focus on performance, accessibility, data integrity
If "Specific requirements only," follow up asking which requirement IDs to test.
4. Spawn the Acceptor Agent
Delegate to the spec-driven:spec-acceptor agent via the Task tool.
Pass the agent:
- The spec directory path (
.claude/specs/<feature-name>/) - The testing scope (full, specific IDs, or non-functional only)
- Any relevant context about how to run the app (if known from design.md or codebase)
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 · 97 lines · 15 tokens per session scan A 11a8ddf6802c
spec-accept 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 907 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.
ship
Deliver the increment. Then go live with a rollback you have run.
sruja-bugfix-triage
Systematic workflow for triaging and fixing bugs with architecture grounding.
triage
AI-powered reachability triage for dependency vulnerabilities. Scans for CVEs then searches your source code to estimate whether each vulnerable API is actually called. Outputs a prioritized FOUNDINSOURCE / UNCERTAIN / NOTFOUNDINGREP report.
smart-help
Context-aware help that suggests relevant commands.
crossframe-essay
使用 CrossFrame Essay 把用户给出的主题、素材或问题写成中文批判性洞察文章。.