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 skills/greglas75/zuvo/plannpx skills add greglas75/zuvo --skill plangit clone --depth 1 https://github.com/greglas75/zuvoWrote 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/skills/greglas75/zuvo/plan)<a href="https://agentmods.dev/skills/greglas75/zuvo/plan"><img src="https://agentmods.dev/badge/skills/greglas75/zuvo/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.00053 | $0.11175 |
| Opus 5 | $0.00026 | $0.05587 |
| Sonnet 5 | $0.00011 | $0.02235 |
| Haiku 4.5 | $0.00005 | $0.01117 |
Grade A, and why
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 yesterday.
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 — 662 lines — stays where its author put it; the contents beside it link to each section on GitHub.
zuvo:plan
Create a detailed, task-by-task implementation plan. Every task follows the TDD protocol: RED (failing test) -> GREEN (minimal code) -> Verify -> Commit.
Input Resolution
Determine the planning input. Two modes: spec-driven (from brainstorm output) or inline (from user description).
Step 1: Look for a spec
- If the user provided an explicit path (e.g.,
zuvo:plan docs/specs/my-spec.md), use that file - Otherwise, search:
Glob("docs/specs/*-spec.md") - If multiple specs exist, present the list and ask the user which one to plan against
Step 2: Determine mode
- Spec found with
status: Approved→ spec-driven mode. Read spec in full. This is the source of truth. - Spec found without
status: Approved→ Print: "Spec exists but is not approved. Using it as reference in inline mode." Treat spec as context, not authority. → inline mode. - No spec found → inline mode.
Inline mode requirements
The user's message (argument to zuvo:plan) IS the planning input. Extract:
- Goal: what they want built
- Scope: which files/areas are affected (explore codebase if not stated)
- Constraints: any stated requirements
If the user's description is too vague to plan against (less than one sentence, no clear deliverable), ask ONE clarifying question. Do not block — a couple of sentences is enough to plan from.
Set planning_mode: "inline" or planning_mode: "spec-driven" — this affects the plan document header and review phase.
Artifact Detection
Check if a plan already exists:
Glob("docs/specs/*-plan.md")— look for existing plans- Spec-driven mode: match by
spec_idfield. If a matching plan exists, ask the user whether to revise or start fresh. - Inline mode: skip this check (no spec_id to match against)
- If no plan exists, proceed to Phase 1
Mandatory File Loading
Phase 0 — Bootstrap (load before any work)
CORE FILES LOADED:
1. ../../shared/includes/codesift-setup.md -- READ/MISSING
2. ../../shared/includes/env-compat.md -- READ/MISSING
3. ../../shared/includes/quality-gates.md -- READ/MISSING
4. ../../shared/includes/tdd-protocol.md -- READ/MISSING
5. ../../shared/includes/session-state.md -- READ/MISSING
6. ../../shared/includes/acceptance-proof-protocol.md -- READ/MISSING
7. ../../shared/includes/provided-artifact-supremacy.md -- READ/MISSING
8. ../../rules/file-limits.md -- READ/MISSING
9. ../../shared/includes/run-logger.md -- DEFERRED (completion)
10. ../../shared/includes/retrospective.md -- DEFERRED (completion)
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 662 lines · 53 tokens per session scan A 172f322ab5b7
plan is a skill published in the GitHub repository greglas75/zuvo (6 stars, last pushed yesterday), licensed MIT. It adds 53 tokens to every session and 11,175 once invoked, about $0.0003 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-09-03.
Other skills, from other repositories
ring:running-dev-cycle
Running the backend dev cycle: implements every task in a rolling-wave plan.md (ring:writing-plans format) for a Go/TS service, driving specialist agents through Gate 0 implementation/TDD, Gate 8 parallel review, and Gate 9 validation per epic, elaborating later phases at each phase boundary. Use when starting or…
ring:instrumenting-streaming-events
Instrumenting streaming events: wires lib-streaming event emission end-to-end into a Lerian Go service via a 13-gate cycle (catalog, Builder bootstrap, Emit sites, outbox, HTTP manifest, NoopEmitter fallback, integration and chaos tests), dispatching ring:backend-go under TDD. Consumes the validated…
ring:implementing-tasks
Implementing a single planned task (Task N.M.T) end-to-end: selects the right backend agent by language and service type, drives one TDD RED->GREEN turn, then verifies coverage, lint, license headers, runtime, and delivery before handoff. Runs as Gate 0 before ring:reviewing-code. Use to drive ONE task inside an…
auto-loop
TDD-based autonomous development loop with checkpoint recovery and observability changelog.
workflow
Run the complete 5-step development workflow: focus problem → prevent over-development → test-first (TDD) → document → smart commit. Use when starting a new feature, or when the user runs /workflow or asks for the full development flow.
test-first
Drive one feature through a strict TDD Red-Green-Refactor cycle with checklists for each phase. Use when implementing new functionality test-first, or when the user runs /test-first.