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 skills add doodledood/manifest-dev --skill walk-prgit clone --depth 1 https://github.com/doodledood/manifest-devWrote 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/doodledood/manifest-dev/walk-pr)<a href="https://agentmods.dev/skills/doodledood/manifest-dev/walk-pr"><img src="https://agentmods.dev/badge/skills/doodledood/manifest-dev/walk-pr.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.1 | $0.00089 | $0.01014 |
| Opus 5 | $0.00044 | $0.00507 |
| Sonnet 5 | $0.00018 | $0.00203 |
| Haiku 4.5 | $0.00009 | $0.00101 |
Grade A, and why
walk-pr 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 today.
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 — 25 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Walk the user through a PR or large diff one sub-changeset (SC) at a time — a group of files that makes sense together — and one review topic at a time within it.
Reader model. The reviewer lives in the repo but has zero context on this PR. Codebase vocabulary is shared ground; vocabulary the PR introduces is not — new types, modes, modules, domain terms need explicit introduction before downstream content uses them.
Attention contract. Every mode of this skill serves the same contract: high-level orientation first, one idea active at a time, and depth — rationale, code, diffs, long text — only when the reviewer asks for it. In chat that is the one-SC/one-topic discipline below; in canvas it is a visual map with everything textual behind taps. Whenever a presentation choice arises, the failure to avoid is the text wall: never put more in front of the reviewer than the current idea needs.
Open with orientation. Present a PR primer before the change overview: a one-paragraph problem statement in workflow vocabulary, plus — only when load-bearing — a concept glossary (workflow-level definitions, not type signatures), a component sketch, or a reading hint. Then a categorized overview (load-bearing vs scaffolding/data, biggest-signal-first); skip both on trivial diffs.
Per sub-changeset, depth on demand. The always-visible surface per SC is a one-sentence behavior summary (what changes for the user) and a one-sentence verification probe (how to observe it works). Everything else — boundary view, topics, diff — is depth the reviewer expands only on SCs that need it.
Inside the depth — boundary-first. Open with a boundary view: ≤3 short paragraphs at module-boundary altitude — new/changed types, signatures at module edges, dependency-edge shifts, contract changes — load-bearing pieces only, no inventory. Diff hunks are per-file, on-demand evidence, not the default exposition. Then topics.
Topic shape. Surface review topics (probes, trade-offs, recommendations) one at a time. Each topic = two declarative sentences: a concrete framing of the concern in codebase vocabulary, then the recommended call. No nested clauses, no embedded justification, no narrated reasoning. Put rationale, code excerpts, and alternatives in supporting material (a follow-up message or on-demand probe), not the headline. Wait for the user's response before advancing. Don't batch — "thoughts on all of these?" is the failure mode this skill prevents. Hold positions under pushback when evidence still supports them.
Triage, then post. Capture the user's response per topic. When the walk completes, triage every captured item — topic responses and free notes alike — into three kinds: settled calls that become draft comments; questions the reviewer raised that you must answer first — from the code, the repo's ADRs, and any design doc the PR implements (fetch it; design-vs-implementation deviations are prime review material) — because investigation routinely flips or reshapes the would-be comment; and drops that generate nothing. Then confirm the proposed comments with the reviewer one at a time — a batched approval table recreates the overload the walk exists to prevent — each line-anchored where it ties to a specific code location, file-level or PR-level otherwise. Once all items lock, post them as a single PR review using the available GitHub review mechanism. Whether and how the PR's author addresses the comments is the manifest workflow's job downstream, not /walk-pr's.
--canvas. Load references/CANVAS_MODE.md. The HTML artifact replaces chat as the walkthrough surface — and it is a picture, not a document: one persistent system map of the PR with a stepped story, pinned review topics, comment-anywhere, and diffs in an on-demand drawer, generated once upfront and opened immediately. The user navigates self-paced and hands the consolidated review bundle back to chat, where the triage above takes over. Input = PR number, PR URL, diff range, or nothing (infer the current branch's PR; fall back to the diff against the repository's actual remote-tracking default branch).
What ships with it
2 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.
- today Changed 6acc4f9cdbbc
- 7d ago First seen · 25 lines · 89 tokens per session scan A 6577fae14253
walk-pr is a skill published in the GitHub repository doodledood/manifest-dev (72 stars, last pushed yesterday), licensed MIT. It adds 89 tokens to every session and 1,014 once invoked, about $0.0004 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.
Other skills, from other repositories
triage-aging-prs
Drive an aging pull-request backlog to zero. Inventories every open PR, finds the STRUCTURAL blockers first (a required check that can never run, a reviewer that never fires, chronically red CI), triages every unresolved review thread in parallel and VERIFIES each finding against the code before fixing it, then merges…
review-comments
Systematically pull, categorize, and address all PR review comments — code change requests, questions, and suggestions. This skill fetches comments via gh api, groups them by file, implements fixes, handles disagreements diplomatically, and pushes a single commit. You should not try to handle PR review feedback…
merge-pr
Safely merge PR with verification and Linear integration. ALWAYS use when the user says 'merge the PR', 'merge this', 'ship it', or wants to merge an approved pull request. Runs tests, checks CI, verifies approvals, squash merges, cleans up branches, and moves Linear ticket to Done.
create-pr
Create pull request with automatic Linear integration. ALWAYS use when the user says 'create a PR', 'open a pull request', 'ship this', 'ready for review', or wants to push changes and create a GitHub PR. Handles commit, rebase, push, PR creation, description generation, and Linear ticket update.
describe-pr
Generate or update PR description with incremental changes. ALWAYS use when the user says 'describe the PR', 'update PR description', 'generate PR description', or after pushing new commits to an existing PR. Supports incremental updates that preserve manual edits.
pr
Comprehensive PR/issue review - analyzes architecture, tests, identifies unrelated changes mixed in, drafts review comment or issue comment. Use when user asks to review a PR, check a PR, look at PR changes, or comment on an issue.