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/inkatze/planwright/spec-walkthroughnpx skills add inkatze/planwright --skill spec-walkthroughgit clone --depth 1 https://github.com/inkatze/planwrightWrote 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/inkatze/planwright/spec-walkthrough)<a href="https://agentmods.dev/skills/inkatze/planwright/spec-walkthrough"><img src="https://agentmods.dev/badge/skills/inkatze/planwright/spec-walkthrough.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.00100 | $0.02480 |
| Opus 5 | $0.00050 | $0.01240 |
| Sonnet 5 | $0.00020 | $0.00496 |
| Haiku 4.5 | $0.00010 | $0.00248 |
Grade A, and why
spec-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 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.
How it starts
The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/spec-walkthrough
A standalone, read-only command that renders an existing spec bundle, or a
selected part of it, into a visual, plain-English artifact a human reads and
judges for themselves (REQ-A1.1, D-1). It lowers the cost of absorbing a
dense bundle so a reader can independently evaluate it at any lifecycle stage,
and it stands apart from /spec-kickoff precisely so that read stays
independent: the moment the authoring agent performs the comprehension,
independent review collapses into "the agent reviewed its own spec."
On a successful load the command assembles the bundle into a single
self-contained HTML file and writes it to the gitignored
.claude/walkthroughs/<spec>/ location (REQ-E1.1), naming the path in the load
report. The artifact carries the one-pager, the decision map, the drawn
dependency graph, and the teach-back; a partial --scope selector renders only
the sections in its scope (a single file, a requirement group, the decision set,
the task graph, or one decision plus its blast radius), and the framing adapts
to the bundle's auto-detected status (REQ-B1.2, REQ-B1.3).
Doctrine
Resolve and read these rule docs at run start via the rule-doc resolution
convention (scripts/resolve-rule-doc.sh <doc-name>, or the documented
PLANWRIGHT_ROOT/CLAUDE_PLUGIN_ROOT chain): spec-format (the bundle this
command reads conforms to the meta-spec — its file set, headers, and identifier
discipline govern what the scaffold loads and validates) and security-posture
(the identifier-charset and path-containment rules the scaffold enforces before
any read, and the data-hygiene rule for anything it later writes). Their
definitions govern wherever this skill names a concept. If one does not resolve,
halt with a clear message naming the missing doc and the chain consulted
(REQ-K1.7: a clear message is the graceful arm; proceeding without doctrine is
the opaque failure).
Doctrine manifest (the reading model above in machine-parseable form, per
doctrine/instruction-hygiene.md; run-start loads before work begins):
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 · 175 lines · 100 tokens per session scan A d6153e35412b
spec-walkthrough is a skill published in the GitHub repository inkatze/planwright (3 stars, last pushed today), licensed MIT. It adds 100 tokens to every session and 2,480 once invoked, about $0.0005 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 skills, from other repositories
accessibility-gate
Use as a pass/fail gate on any diff with a user-facing surface — by code-reviewer during review, by qa-engineer during the test pass, and by any IC before claiming a UI ticket done. This is the gate the plan called for instead of an accessibility specialist role. Triggers whenever a screen, component or state changes.
agent-isolation
Use before spawning any agent that writes files, and by every developer/fixer agent as its first and last action. Gives each agent its own git worktree, forbids blanket staging, and requires confirming a mutation actually landed. Triggers from /app-build, /app-audit, parallel-orchestrator, and any parallel agent…
architecture-builder
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the architecture", "pick the stack", or as part of /app-plan.
board-doctor
Use to validate docs/31-board.md before spawning any agent, and to verify a developer's "DONE" claim before moving a row to review. Triggers as step 0 of /app-build and /app-run, from /app-status, and any time the board looks inconsistent. Catches tickets the sprint loop cannot see.
brownfield-onboarding
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers the as-built architecture, and classifies remediation work as safe-to-auto-fix vs risky-needs-approval. Triggered by /app-onboard, /app-audit, and by /app-run when it detects a non-empty app…
business-model
Use when deciding or revisiting how the product makes money — pricing, tiers, trial shape, ad load, unit economics — by ceo when setting the model, by cpo when a scope decision turns on revenue, and by product-researcher when investigating willingness to pay. A pricing analysis is a document, not a standing role.