Review every changed file in its own fresh context
Large changes overflow one reviewer's context, and the last files get the least attention. This graph lists the files first, then runs one review per file in parallel, each seeing only its own file, and merges and checks the results.
4 steps in 4 stages · 4 subagents · a kit of 9 files
Free. Built in your browser; nothing is uploaded. No API key, no account.
How it runs
Steps in the same stage start at the same time. Each subagent gets only what its incoming edges carry, and a step in a fresh context never sees the reasoning of the steps before it. A gate decides whether the work passes, and a failed gate re-runs the work it checks.
- Stage 1
List the files · Planner
sonnet · Read, Grep, Glob, Bash(git diff:*)
- Stage 2
Review each file · Worker
haiku · Read, Grep, Glob · fresh context · once per item of scope.files
- Stage 3
Merge findings · Writer
sonnet · Read
- Stage 4
GATE (Fresh Context) · Checker
opus · Read, Grep, Glob · fresh context
Gate: Every blocking finding names a file and line that exist, and no finding is listed twice.
Use it when
- Your changes touch many files.
- You want the same attention on file 30 as on file 1.
- You want a limit on how many reviews run at once.
Change these first
- Tune how many file reviews run in parallel and the most it may start.
- Filter the file list, for example to skip generated or lock files.
Need a workflow built for your team? Fixed-price packages
What you get
An orchestrating SKILL.md, one Claude Code subagent per step with its own tools and model, and the same skill as a Cursor rule. Your agent runs it with its own subagents; nothing on this site calls a model.
- .claude/skills/review-each-file/SKILL.mdorchestrator
- .claude/skills/review-each-file/graph.skill.mdgraph source
- .claude/agents/review-each-file-scope.mdsubagent
- .claude/agents/review-each-file-review-file.mdsubagent
- .claude/agents/review-each-file-merge.mdsubagent
- .claude/agents/review-each-file-gate.mdsubagent
- .skill-graph/.gitignoresupport
- .cursor/rules/review-each-file.mdcCursor rule
- README.mdreadme
---
name: review-each-file
description: "Lists the files a change touches, reviews each one in its own fresh-context run, merges the findings and gates them before reporting."
---
# review-each-file
Lists the files a change touches, reviews each one in its own fresh-context run, merges the findings and gates them before reporting.
This skill is a graph: each step has its own prompt and context, and only the payloads named below move between steps.
## Plan
Run the stages in order. Every model step runs in its own subagent; do not do a step's work yourself. Only command steps and approvals are yours to run. Steps in the same stage do not depend on each other: start them together, in one message with several subagent calls.
The input (`goal`) is the user's goal: their request, word for word, handed on under `### goal`. Ask for it if the user has not given one.
### Stage 1 · 1 step
- **LIST THE FILES** (`scope`) → subagent `review-each-file-scope`
- Hand it: the user's goal.
- Expect: `file_list` (json).
- Contract check (`file_list`): save its output to `.skill-graph/review-each-file/scope.json`, then run `node -e "const fs=require('fs');const d=JSON.parse(fs.readFileSync(process.argv[1],'utf8'));const k=['files','focus'];const ok=d!==null&&typeof d==='object'&&Array.isArray(d)===false;const m=ok?k.filter((x)=>Object.hasOwn(d,x)===false):k;if(m.length>0){console.error('Missing keys: '+m.join(', '));process.exit(1)}" .skill-graph/review-each-file/scope.json` with Bash. Exit code 0 passes.
- If a contract check fails: re-run this step once with its previous answer and the error output. If it fails again, stop and show the user the output.
- Hand-off by file: save its output, verbatim, to `.skill-graph/review-each-file/scope.json`. Later steps get that path, not the text.
### Stage 2 · 1 step
- **REVIEW EACH FILE** (`review_file`) → subagent `review-each-file-review-file` · fresh context · one run per item, up to 6 at a time
- Take the list: the `files` array in the JSON of LIST THE FILES (`scope`). If it is not an array, stop and report. If it is empty, skip this step: its output is `[]`.
- If the list has more than 40 items, stop before starting any run and tell the user how many there are.
- Start one run of the subagent per item, up to 6 at a time (several subagent calls in one message); start the next as one finishes.
- Hand each run: its item: one entry of `files` from the JSON of LIST THE FILES (`scope`); the `focus` value from the JSON of LIST THE FILES (`scope`), as the path `.skill-graph/review-each-file/scope.json`. Nothing else: no notes of your own, no other step's reasoning, no earlier conversation.
- Expect, per run: the result for its item. Checks and gates below apply to each run on its own; a retry re-runs only the runs that failed.
- Output: a JSON array of the runs' results, in item order. That array is what later steps get.
- Hand-off by file: save its output, verbatim, to `.skill-graph/review-each-file/review_file.json`. Later steps get that path, not the text.
### Stage 3 · 1 step
- **MERGE FINDINGS** (`merge`) → subagent `review-each-file-merge`
… 37 more lines in the kitOr let Claude adapt it
Add Skill Graph to Claude Code as a connector, then ask. Claude loads this starter, changes it for your project, checks it and hands you the kit.
Set up the connectorAsk Claude
Use Skill Graph: get the review-each-file template, adapt it to this project, validate it until it has no errors, and compile it for Claude Code.The graph file
The whole workflow is one Markdown file, graph.skill.md: the steps and edges in the frontmatter, one prompt per step below it. The guide explains every field.
graph.skill.md · 92 lines
---
name: review-each-file
description: Lists the files a change touches, reviews each one in its own fresh-context run, merges the findings and gates them before reporting.
spec: skill-graph/2
handoff: file
topology:
nodes:
- id: goal
type: input
label: CHANGE TO REVIEW
- id: scope
type: orchestrator
label: LIST THE FILES
model: sonnet
tools: [Read, Grep, Glob, "Bash(git diff:*)"]
output_format: json
- id: review_file
type: worker
label: REVIEW EACH FILE
isolated_context: true
model: haiku
tools: [Read, Grep, Glob]
foreach: scope.files
max_parallel: 6
max_items: 40
- id: merge
type: synthesizer
label: MERGE FINDINGS
model: sonnet
tools: [Read]
- id: gate
type: verifier
label: GATE (Fresh Context)
isolated_context: true
model: opus
tools: [Read, Grep, Glob]
gate: Every blocking finding names a file and line that exist, and no finding is listed twice.
on_fail: retry
max_retries: 1
retry_target: merge
edges:
- from: goal
to: scope
- from: scope
to: review_file
contract: file_list
- from: review_file
to: merge
contract: file_reviews
- from: merge
to: gate
contract: findings
contracts:
file_list:
format: json
description: "{ files: the changed paths to review, focus: one sentence on what the change is for }"
required: [files, focus]
file_reviews:
format: json
description: One entry per file, in file order; each lists its findings with line, severity and evidence.
findings:
format: markdown
description: Findings grouped by severity (blocking, should fix, nit); each names the file and line.
---
# Node Prompts & Edge Contracts
## @node: scope
Find the files this change touches (run git diff --name-only for the range the user gives, or against the main branch). Leave out generated files, lockfiles and binaries.
The change:
{{goal}}
Return JSON: {"files": [the paths], "focus": "one sentence on what the change is for"}.
## @node: review_file
Review this one file as part of a change whose purpose is: {{scope.focus}}
File: {{item}}
Read the file and its diff. Report only real problems in this file: bugs, missed edge cases, security issues, and code that does not do what the change is for. For each give the line, a severity (blocking, should fix, nit) and the evidence. If the file is fine, say so in one line.
## @node: merge
Merge these per-file reviews into one list. Drop duplicates, group by severity (blocking first), and keep the file, line and evidence of each finding.
{{review_file.output}}
## @node: gate
You see only the merged findings, not how they were produced. Open each file and line a blocking finding names and check that it exists and says what the finding claims.
{{merge.output}}
More starter graphs
- PR reviewSecurity, performance, architecture and test coverage reviewers
- Bug triageStack trace, logs, recent commits and a minimal repro
- RFC discoveryFeasibility, prior art, interface design and failure modes
- Ship a changeEdit until tests pass, review the diff in parallel, approve once before the PR
- Parallel auditResearch, compare, check and find gaps, then verify in a fresh context
- Research reportSources, figures, counterpoints and open questions, fact-checked in a fresh context
- Write an articleAngle, outline, facts and reader in parallel, then an editor check before the draft
- Analyze a datasetProfile, clean, analyze and sanity-check a table in parallel, then re-check every figure
- Design an appUsers, features, screens and data model in parallel, then a product review before the spec