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-plangit clone --depth 1 https://github.com/Connorrmcd6/vibe-specWrote 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/connorrmcd6/vibe-spec/spec-plan)<a href="https://agentmods.dev/commands/connorrmcd6/vibe-spec/spec-plan"><img src="https://agentmods.dev/badge/commands/connorrmcd6/vibe-spec/spec-plan.svg" alt="Measured on agentmods" 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 | $0.00049 | $0.00603 |
| Opus 5 | $0.00024 | $0.00302 |
| Sonnet 5 | $0.00010 | $0.00121 |
| Haiku 4.5 | $0.00005 | $0.00060 |
Grade A, and why
spec-plan 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 4d 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 4 of the Vibe-Spec spec-driven workflow: generating the
phase plan files. See the vibe-spec skill
(${CLAUDE_PLUGIN_ROOT}/skills/vibe-spec/reference/00-workflow.md) for the
phase-doc conventions.
By default this produces one plan file for every phase in the index, so the user ends with a complete set and can start a fresh session on any phase.
What to do
-
Read
docs/project-spec.mdand find the phase index. If there's no phase index, tell the user to run/spec-phasesfirst. -
Determine the set of phases to generate:
- If
$ARGUMENTSnames a specific phase, generate only that one (use this to (re)generate a single phase). - Otherwise, generate all phases listed in the index. Skip any phase whose plan file already exists unless its content is just a stub, so re-running is safe and won't clobber work in progress.
- If
-
For each phase in the set, create its plan file at the path named in the index (e.g.
docs/plans/phase-1-foundation.md). Open every file with this header:# Phase 1 — Foundation | Field | Value | |-------|-------| | **Scope** | Project scaffold, data ingestion | | **Detail level** | High-level | | **Status** | Planned |Valid statuses:
Planned→In Progress→Complete. Detail level starts High-level here and is promoted to Detailed in/spec-implement. -
Fill in each plan at a high level — enough structure to understand scope and sequence, not full implementation detail. For each stack area a phase touches, pull the relevant
vibe-specreference file (e.g.05-prisma.mdfor schema work,07-auth.mdfor auth) and capture the documented approach and key conventions so each phase doc doubles as an architecture reference. When a phase establishes a documented invariant worth governing, note it should be anchored as a Surface hub claim during implementation (20-surface.md).
Keep every plan high-level — full detail comes when you implement. When done, list the
plan files you created and tell the user they can now start a fresh session and run
/spec-implement on the first phase.
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.
- 4d ago First seen · 50 lines · 49 tokens per session scan A 0b06194ba33f
spec-plan is a command published in the GitHub repository Connorrmcd6/vibe-spec (9 stars, last pushed 1mo ago), licensed MIT. It adds 49 tokens to every session and 603 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.
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.
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.
devops
When /devops is invoked, immediately execute the following steps to create, configure, or manage DevOps infrastructure, CI/CD pipelines, and deployment configurations.
audit-code
When /audit-code [target] is invoked, immediately execute the following steps to analyze code quality, security, and adherence to project standards.
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.