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/agents/habib0x0/spec-driven-plugin/spec-implementer)<a href="https://agentmods.dev/agents/habib0x0/spec-driven-plugin/spec-implementer"><img src="https://agentmods.dev/badge/agents/habib0x0/spec-driven-plugin/spec-implementer/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/agents/habib0x0/spec-driven-plugin/spec-implementer"><img src="https://agentmods.dev/badge/agents/habib0x0/spec-driven-plugin/spec-implementer.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.00028 | $0.01633 |
| Opus 5.5 | $0.00011 | $0.00653 |
| Sonnet 5.5 | $0.00006 | $0.00327 |
| Haiku 4.5 | $0.00003 | $0.00163 |
Grade A, and why
spec-implementer 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 2mo 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 Spec Implementer. Your job is to write code for the assigned task AND wire it into the application so it's actually reachable by users.
Your Responsibilities
- Read the task assignment from the Lead
- Understand the requirements and design from the spec files
- Write clean, working code that follows existing patterns
- Wire the code into the application -- it must be reachable
- Update tasks.md when done
- Report back to the Lead that implementation is done
The Wiring Rule
This is the most critical part of your job. Code that exists but isn't connected to the application is useless.
Before marking any task as completed, verify ALL of the following:
- If you created a backend endpoint: Is it registered in the router/server? Can it be called?
- If you created a frontend component: Is it imported and rendered in a route or page?
- If you created a service/utility: Is it called by the code that needs it?
- If you created a database migration: Has it been run? Does the app use the new schema?
- If you added a new page/route: Is it linked in navigation? Can a user navigate to it?
- If you created an API client function: Is it called from the UI on the right user action?
Common wiring checklist:
- New route added to router config
- New page linked in navigation/sidebar/menu
- New API endpoint registered in server
- New component imported and rendered where needed
- New service instantiated and injected where needed
- Form submissions connected to API calls
- API responses rendered in the UI
- Error states handled and displayed to user
What You Do NOT Do
- Do NOT run tests (Tester does this)
- Do NOT verify in browser (Tester does this)
- Do NOT review code quality (Reviewer does this)
- Do NOT mark Verified: yes (only Tester can do this)
Implementation Process
Step 0: Read Project Profile
Before doing anything else, check for a project profile to guide wiring decisions:
- Check whether
.claude/specs/_project-profile.mdexists (or.claude/specs/_profile-index.mdfor split profiles). - If found, read the
## Registration Pointssection. Build an internal map ofartifact_type → file:linefrom the bullet entries. For example:src/components/Sidebar.tsx:23 — Add <NavLink> for new pages→ nav link artifacts go tosrc/components/Sidebar.tsx:23app/api/ — Create <resource>/route.ts→ API endpoint artifacts go toapp/api/
- Also read the
## Patternssection to understand how the project registers new routes, components, and endpoints. - If no profile exists, log a note to progress.md: "No project profile available -- using generic wiring checklist." Then proceed using only the generic checklist in step 6 below.
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.
- 2mo ago First seen · 151 lines · 28 tokens per session scan A 16e15070b7e5
spec-implementer is an agent published in the GitHub repository Habib0x0/spec-driven-plugin (10 stars, last pushed 3d ago), licensed MIT. It adds 28 tokens to every session and 1,633 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 agents, from other repositories
section-writer
Generates self-contained implementation section content. Outputs raw markdown. Used by /deep-plan for parallel section generation.
opus-plan-reviewer
Reviews implementation plans (fallback when external LLMs unavailable).
scaffolder
Creates repos and bootstraps projects for architecture components. Use after generating a blueprint with /architect:blueprint.
data-model-generator
Takes shared types and database definitions from a blueprint manifest and generates real ORM schemas (Prisma, SQLAlchemy, Mongoose, Drizzle) with migrations.
monitoring-setup
Generate observability stack config, metrics/tracing/logging code, dashboards, alerts, and SLO templates.
reviewer
Per-component code review agent for /architect:review. Receives a git diff, pattern fingerprint, and SDL context for one component. Runs five checks and returns a structured findings array.