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/connorrmcd6/vibe-spec/spec-implementgit clone --depth 1 https://github.com/Connorrmcd6/vibe-specWhat 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.00036 | $0.00650 |
| Opus 5 | $0.00018 | $0.00325 |
| Sonnet 5 | $0.00007 | $0.00130 |
| Haiku 4.5 | $0.00004 | $0.00065 |
Grade A, and why
spec-implement 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.
What it actually says
You are running Step 5 of the Vibe-Spec spec-driven workflow: detailing and
implementing one phase. This step is iterative — run it once per phase, ideally in
a fresh session. See the vibe-spec skill
(${CLAUDE_PLUGIN_ROOT}/skills/vibe-spec/reference/00-workflow.md).
What to do
- Load context. Read
docs/project-spec.md(the V2 spec) and the target phase's plan file underdocs/plans/. Pick the phase from$ARGUMENTS, or default to the next phase whose status isn'tComplete. Also read the previous phase's plan so decisions carry forward. - Promote to detailed. Expand the phase plan from High-level to Detailed:
concrete files, schema, endpoints, and steps. Update the header's Detail level
to
Detailedand Status toIn Progress. For each stack area, consult the matchingvibe-specreference file and follow its conventions and gotchas exactly (e.g.01-scaffolding.mdfor project setup,05-prisma.mdfor schema,07-auth.mdfor auth,08-rbac.mdfor roles,10-testing.mdfor tests). - Implement the detailed plan. Use official CLI/init commands for boilerplate
wherever possible (
pnpm create next-app,pnpm prisma init,shadcn init). - Update the docs — this is not optional. If anything drifted during
implementation (design changes, bottlenecks, skipped or added features), update the
phase doc so it reflects reality, and update dependent phase docs and the V2 spec
where needed. Capture decisions made, not just TODOs. A stale spec is worse
than no spec — it actively misleads future sessions. Set the phase Status to
Completewhen done.- Govern the docs (if the project uses Surface). For any domain whose logic this
phase changed, add or update the relevant hub claim, then — once you've confirmed the
prose is true — run
surf verifyto re-seal it so the pre-commitsurf checkgate stays green. New invariant worth governing? Author a fresh claim withsurf new/surf suggest. Seereference/20-surface.md. This makes "keep the docs honest" a mechanical gate, not just a good intention.
- Govern the docs (if the project uses Surface). For any domain whose logic this
phase changed, add or update the relevant hub claim, then — once you've confirmed the
prose is true — run
End by summarizing what changed and telling the user to start a fresh session and run
/spec-implement for the next phase. If new phases became necessary, add them with
/spec-phases conventions and continue.
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 · 41 lines · 36 tokens per session scan A eb7448f876c6
spec-implement is a command published in the GitHub repository Connorrmcd6/vibe-spec (9 stars, last pushed 1mo ago), licensed MIT. It adds 36 tokens to every session and 650 once invoked, about $0.0002 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
cleanup-repo
When /cleanup-repo is invoked, immediately execute the following steps to analyze, organize, and clean up the repository structure when files are scattered and disorganized.
devops
When /devops is invoked, immediately execute the following steps to create, configure, or manage DevOps infrastructure, CI/CD pipelines, and deployment configurations.
magic-wand
When /magic-wand [issue description] is invoked, immediately execute the following steps to perform a comprehensive, expert-level analysis and fix when standard debugging approaches have failed.
audit-code
When /audit-code [target] is invoked, immediately execute the following steps to analyze code quality, security, and adherence to project standards.
brainstorm
When /brainstorm [topic] is invoked, immediately execute the following steps to collaboratively brainstorm, enhance, and plan new features for the app through an iterative product management workflow.
clean-code
When /clean-code [target] is invoked, immediately execute the following steps to remove redundant code, unused variables, dead code, debug statements, and other technical debt.