Borrowing it
Nothing to install: this file belongs to kurcontko/mnemotree. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/kurcontko/mnemotree/main/.claude/skills/review-fanout/SKILL.mdgit clone --depth 1 https://github.com/kurcontko/mnemotreeWrote 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/kurcontko/mnemotree/review-fanout)<a href="https://agentmods.dev/skills/kurcontko/mnemotree/review-fanout"><img src="https://agentmods.dev/badge/skills/kurcontko/mnemotree/review-fanout/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/kurcontko/mnemotree/review-fanout"><img src="https://agentmods.dev/badge/skills/kurcontko/mnemotree/review-fanout.svg" alt="Reviewed on agentmods" width="80" 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.00081 | $0.01718 |
| Opus 5.5 | $0.00032 | $0.00687 |
| Sonnet 5.5 | $0.00016 | $0.00344 |
| Haiku 4.5 | $0.00008 | $0.00172 |
Grade A, and why
review-fanout 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 — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fan-out review
Nine lanes review the same diff at once, each with its own context and its own narrow question. You collect the reports and return one ranked summary.
Nine at once is more delegation than most work deserves. It is justified here because the user asked for this review by name and the lanes are genuinely independent — but any standing budget on concurrent subagents does not apply to this skill. Everything else still holds: each lane gets a written brief, lane reports are evidence rather than truth, and the user gets one integrated answer rather than nine relayed ones.
Scope
Resolve what to review in this order, and say which rule fired:
- The user named a scope — a branch, commit SHA, PR number or URL, or file paths. Review that.
- On a feature branch —
git diff main...HEAD(three-dot, from the merge base). Substitute the repo's actual default branch. - On the default branch with staged changes —
git diff --staged. - On the default branch with nothing staged —
git show HEAD.
Three-dot diffs exclude staged and working-tree changes. If rule 2 fired and the tree is dirty, say so and offer to include the working tree instead of silently reviewing a diff the user has already moved past.
Resolve the ref and confirm the diff is non-empty before spawning anything. A bad ref or an empty diff stops here, in front of the user, rather than inside nine workers.
Running the lanes
Launch all nine in a single message so they run concurrently.
Pick the most constrained worker available. A read-only agent that cannot edit
and has no Agent tool is ideal, because then a lane structurally cannot
rediscover this skill and fan out again — if a verifier-style agent is
installed, use it. Otherwise use a general-purpose subagent and rely on the
written rule below. Never grant a lane the Agent tool.
Every brief carries: the resolved scope and how to reproduce the diff, the state the work starts from, the lane's question, and the reporting contract below. Pass no model override — let each worker run on its own definition.
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 · 171 lines · 81 tokens per session scan A 335917e52f9d
review-fanout is a skill published in the GitHub repository kurcontko/mnemotree (6 stars, last pushed yesterday), licensed MIT. It adds 81 tokens to every session and 1,718 once invoked, about $0.0003 per session on Opus 5.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-10-26.
Other skills, from other repositories
code-review
Coordinate a delegated full multi-persona code review for a Moraine PR or local change. Use when asked to review a PR, run review agents, get code review feedback, or iterate on review feedback using all CodeReview personas: elegance, idiom, correctness, completeness, security, YAGNI, and scope. Invoking this skill is…
code-review-correctness
Review a PR through the CodeReviewCorrectness persona. Use when asked to check whether the implementation does the job correctly, avoids bugs and regressions, preserves data and API contracts, handles relevant edge cases, and has tests that would catch the important failures.
code-review-elegance
Review a PR through the CodeReviewElegance persona. Use when asked to review code for minimal design, architectural leverage, elegant abstractions, simplification, removing unnecessary moving parts, or finding the design move that sidesteps an entire class of problems.
code-review-idomatic
Review a PR through the CodeReviewIdomatic persona. Use when asked to check whether code is idiomatic for the implementation language, follows standard library and ecosystem conventions, avoids unnecessarily novel implementations, and matches established patterns in this repository.
code-review-security-review
Review a PR through the CodeReviewSecurityReview persona. Use when asked to check whether code is safe, avoids backdoors, vulnerable dependencies, injection attacks, auth bypasses, secret leaks, unsafe file/network behavior, and other security regressions.
code-review-yagni
Review a PR through the CodeReviewYAGNI persona. Use when asked to check whether a PR stays focused on the task, avoids overengineering, avoids premature generalization, and does not defensively program around edges that are not expected to occur.