specmanager-walkthrough

A command that creates a review document for each completed phase of a planned feature, or a final document joining all approved phase documents.

In plain words
What is it for?
Use it to generate a walkthrough for a named feature phase, or to create the final feature-level roll-up when the feature has multiple phases.
Why use it?
It keeps implementation progress documented and prevents the feature summary from being created before every phase has been reviewed.

Command

Install

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.

agentmods
npx agentmods add commands/joanseg/specmanager/specmanager-walkthrough
Clone the repo
git clone --depth 1 https://github.com/joanseg/specmanager
Per session 36 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 848 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00036 $0.00848
Opus 5 $0.00018 $0.00424
Sonnet 5 $0.00007 $0.00170
Haiku 4.5 $0.00004 $0.00085

Measured 2d ago against content hash 39e48056a1e5, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

specmanager-walkthrough 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.

plugins/specmanager/commands/specmanager-walkthrough.md · 35 lines

How it starts

The opening of the file, as written. The whole thing — 35 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Generate a Walkthrough for $ARGUMENTS.

$ARGUMENTS is <featureId or slug> <phaseName | "final">.

  • phaseName is the exact name from plan.md's ## Phase <name> — <theme> headings (e.g. A, core). For legacy single-phase features that pre-date phased plans, use default.
  • final writes the feature-level roll-up that links every phase walkthrough. Only opens when every phase has an approved walkthrough.

Steps

  1. Parse the arguments. Split into <feature> and <phaseName>. If <phaseName> is missing, ask the user which phase (offer list_phases({ featureId }) to enumerate).
  2. Resolve the feature. list_features → match by id/slug.
  3. Single-phase final short-circuit (refuse early). If <phaseName> === "final" and list_phases({ featureId }) returns exactly one phase, refuse before touching the gate: "Single-phase feature: the per-phase walkthrough is terminal; there is no final roll-up. Run /specmanager-walkthrough <feature> <thatPhaseName> instead." Approving that single per-phase walkthrough ships the feature (isFeatureShipped). final is valid only for multi-phase features. Don't burn a gate round-trip or a subagent Task.
  4. Check the gate. check_gate({ featureId, stage: "walkthrough", phase: "<phaseName>" }). If closed, report reason and stop.
    • For a phase name: gate fails until every task in that phase is done.
    • For final: gate fails until every phase has an approved walkthrough (lists missing phases). (Only reachable for multi-phase features — single-phase final was already refused in step 3.)
  5. Confirm no draft already exists for this phase. list_documents({ featureId, stage: "walkthrough" }) and filter to frontmatter.phase === "<phaseName>". Don't duplicate.
  6. Invoke the subagent. Task({ subagent_type: "walkthrough-writer", prompt: ... }). Include:
    • Feature id, title, slug.
    • The phase name (REQUIRED — drives which mode the agent runs in: per-phase or final).
    • The Plan doc id.
    • Per-phase mode: the phase's exit-test line lifted from plan.md; hint that task artifacts for that phase are available via list_tasks filtered by phase.
    • Final mode: the list of phase walkthrough doc ids (look up via list_documents({ featureId, stage: "walkthrough" })) — pass them explicitly so the agent doesn't waste tokens searching.
  7. Sync CLAUDE.md. Call sync_claude_md.
  8. Report. Document id + file path (e.g. walkthroughs/<slug>/phase-<phaseName>.md, or walkthroughs/<slug>/feature.md for final). Suggest a user review pass before approving.

Read the full file on GitHub · 35 lines

Changes

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.

  1. 2d ago First seen · 35 lines · 36 tokens per session scan A 39e48056a1e5

Subscribe to this mod's changes

specmanager-walkthrough is a command published in the GitHub repository joanseg/specmanager (19 stars, last pushed 19d ago), licensed MIT. It adds 36 tokens to every session and 848 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-30.