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/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-accept)<a href="https://agentmods.dev/commands/habib0x0/spec-driven-plugin/spec-accept"><img src="https://agentmods.dev/badge/commands/habib0x0/spec-driven-plugin/spec-accept/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/habib0x0/spec-driven-plugin/spec-accept"><img src="https://agentmods.dev/badge/commands/habib0x0/spec-driven-plugin/spec-accept.svg" alt="Reviewed on agentmods" width="80" 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.00015 | $0.00907 |
| Opus 5.5 | $0.00006 | $0.00363 |
| Sonnet 5.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 1mo 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.
- 1mo 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 5mo ago), licensed MIT. It adds 15 tokens to every session and 907 once invoked, about $0.0001 per session on Opus 5.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
generate-tests
Generate unit, integration, and e2e test suites from scaffolded project with framework-appropriate coverage.
load-test
Generate load testing scenarios (k6/Locust) from API contracts with realistic traffic patterns.
kill-mutants
Analyze surviving mutants from a mutation testing run and write targeted unit tests to kill them. Re-runs mutations to confirm kills.
mutate
Run mutation testing to verify test quality. Builds a custom mutation tool or uses an existing framework, runs mutations, and reports the mutation score with surviving mutants.
record
Record a browser walkthrough of a URL using Antigravity (agy). Generates .webm video, screenshots, and a report. Auto-converts to MP4 if ffmpeg is available.
test-audit
Use when writing, reviewing, or pruning tests. Three modes, one value bar: a four-question gate before any new test is written, a focused audit of one scope, and a campaign over a whole repo or subsystem that removes the least useful tests under a coverage guard. Every delete, merge, or repair carries written evidence…