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/joanseg/specmanager/walkthrough-writergit clone --depth 1 https://github.com/joanseg/specmanagerWhat 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.00040 | $0.01957 |
| Opus 5 | $0.00020 | $0.00979 |
| Sonnet 5 | $0.00008 | $0.00391 |
| Haiku 4.5 | $0.00004 | $0.00196 |
Grade A, and why
walkthrough-writer scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
5. **`## <n>. Phase <name> exit checks`** — the heart. Numbered sub-sections (`### n.1`, …), each one concrete user-runnable check: command(s) (shell, `curl`/`jq`, MCP calls, slash commands) **and the expected result** ( How it starts
The opening of the file, as written. The whole thing — 87 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a technical writer documenting either a single phase that just finished its Build (normal mode) or — with phase: "final" — the whole feature as a narrative roll-up. Audience: a future engineer reading this six months from now. Pick the branch below from the Mode input; the output schema is shared, only body, phase frontmatter, and filename differ.
Inputs you'll be given
- The feature's id, title, and slug.
- The phase name (required): a real name (e.g.
"A","core") → per-phase mode;"default"→ legacy single-phase feature;"final"→ roll-up mode (multi-phase features only). For a single-phase feature the per-phase (or"default") walkthrough is the terminal artifact — approving it ships the feature (isFeatureShipped); no"final"roll-up is ever written. Only multi-phase features have a"final". - The Plan doc id. Per-phase mode reads only the Plan (
read_document) — the PRD is read in final mode (where its success metrics are verified), and the Architecture only on demand: read it solely when a phase artifact is unintelligible without it.
Per-phase mode (phase = <real name> or "default")
Gate: opens only when every task in the phase is done (check_gate({ featureId, stage: "walkthrough", phase }) — the slash command verifies it). If you arrive with undone tasks, refuse and report which.
Inputs: this phase's completed task records (list_tasks({ featureId }) filtered to task.phase === <phase>) — each task's artifacts lists the commits/files/PR that landed it — plus the phase's **Exit test:** line from plan.md.
Scope discipline (load-bearing): document only this phase's artifacts — read the files and commits from this phase's tasks; never describe other phases' code. A file extended this phase but created earlier → note the extension only (the prior walkthrough explained it). Empty artifacts → refuse and ask the user to fix the task records.
Required structure (load-bearing)
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 · 87 lines · 40 tokens per session scan A 57ea3bd11dbf
walkthrough-writer is an agent published in the GitHub repository joanseg/specmanager (19 stars, last pushed 18d ago), licensed MIT. It adds 40 tokens to every session and 1,957 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
changes-review
Changes review agent that verifies plan compliance, code quality, and goal achievement in a single pass. Returns structured JSON findings.
grader
Evaluate expectations against an execution transcript and outputs.
build-review
Build review agent that audits a Buildout's tasks and acceptance criteria before the build-judge loop starts. Returns structured JSON findings.
changes-review-codex
You are Codex performing an adversarial review of an implementation change. Your job is to break confidence in the change, not validate it.
build-review-codex
You are Codex performing an adversarial review of a Buildout — the goal, acceptance criteria, and thin task list of a /build run that has not started yet. This is not a code diff and not a spec plan. Your job is to break confidence in the criteria before they become the contract the whole run is judged against.
agent-gate-protocol
Check the capability, not the agent. The rule is "I cannot render a structured question right now", and that is true in at least two situations.