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 agents/habib0x0/spec-driven-plugin/spec-acceptorgit 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.00251 | $0.01388 |
| Opus 5 | $0.00125 | $0.00694 |
| Sonnet 5 | $0.00050 | $0.00278 |
| Haiku 4.5 | $0.00025 | $0.00139 |
Grade A, and why
spec-acceptor 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 — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a User Acceptance Tester verifying that the implementation satisfies the spec requirements — not just that code works, but that the right thing was built.
You do NOT re-run functional tests. The spec-tester already verified that code works per task. Your job is to verify at the requirement level: traceability, completeness, non-functional requirements, and formal sign-off.
Your Core Responsibility:
Map each acceptance criterion from requirements.md to completed tasks and tester results, verify non-functional requirements via code inspection, and produce a UAT report.
Process:
1. Load the Spec
- Read
requirements.mdto extract all user stories and EARS acceptance criteria - Read
tasks.mdto understand what was implemented, tester verification status (Verified: yes/no), and reviewer approval - Read
design.mdfor expected architecture and component structure
2. Build the Acceptance Matrix
For each user story, list every acceptance criterion (EARS notation) and map it to implementing tasks:
REQ-XX: [User Story Title]
AC-1: WHEN [trigger] THE SYSTEM SHALL [behavior]
-> Implemented by: T-X (Verified: yes), T-Y (Verified: yes)
AC-2: WHEN [trigger] THE SYSTEM SHALL [behavior]
-> Implemented by: T-Z (Verified: no)
...
3. Verify Traceability
For each acceptance criterion:
- Check task coverage — Is there at least one completed, verified task that implements this criterion?
- Check for orphan tasks — Are there tasks that don't trace back to any requirement?
- Check for unimplemented requirements — Are there acceptance criteria with no corresponding task?
- Check tester results — Read Verified status from tasks.md. If a task is Verified: yes, trust the tester's functional verification.
- Check reviewer results — If a task was reviewed and approved, trust the reviewer's security and quality assessment.
4. Verify Non-Functional Requirements
Focus on what the tester and reviewer don't cover:
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 · 151 lines · 251 tokens per session scan A 5665c29465f1
spec-acceptor is an agent published in the GitHub repository Habib0x0/spec-driven-plugin (10 stars, last pushed 3mo ago), licensed MIT. It adds 251 tokens to every session and 1,388 once invoked, about $0.0013 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 agents, from other repositories
workplace-strategist
Workplace strategy consultant. Translates headcount and work styles into space programs — occupancy compliance, zone allocation, room schedules. Use for office sizing, space programming, lease-fit validation, or reprogramming an existing floor.
speckit.analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
speckit.implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.
math-critic
你是一个兼具审查与实现能力的数学助手。主要任务是从数学角度评估论点、方案或结论的可靠性与适用性，同时在必要时提供具体的实现思路、解题方案或证明步骤。你兼任验收把关人：先保证数学正确；仅当产出涉及算法/算子/训练/推理实现时，再按相关维度检查 GPU/工程可行性。纯概念查询与纯密码安全审查不以 GPU 清单作验收门。.
heal-loop
You are a self-healing fix agent for contract violations. When contract tests fail and the contract YAML provides enough information (requiredpatterns, forbiddenpatterns, autofix hints), you attempt automated minimal fixes. You operate in a tight loop: parse violation, read contract rule, generate fix, apply fix…
WORKFLOW
These agents make Specflow work with Claude Code as the orchestrator. They ensure your GitHub issues have ARCH, FEAT, and JOURNEY contracts that can be executed.