review-large-pr
Review a large pull request (30+ changed files) using chunked parallel review with synthesis. Each chunk is audited by the audit-* specialists in parallel, then synthesized into one consolidated report. Use when a PR is too large for a single audit pass.
适合你,如果经常需要审查超过30个文件的PR
npx oh-my-skill add hawkyre/hawk-skills/review-large-prcurl -fsSL https://oh-my-skill.com/install.sh | bash -s -- hawkyre/hawk-skills/review-large-prnpx oh-my-skill verify hawkyre/hawk-skills/review-large-pr怎么用
商店整理自技能原文 · 版本 6ffb2d6 · 表述以原文为准能自动把大型 PR 拆成小块,并行调用多个专家审查每个块,最后综合生成统一的审查报告。
当你请求审查一个包含30个以上变更文件的大型拉取请求时触发。
技能原文 SKILL.md
Review a Large PR
The strategy: partition the PR into coherent chunks, run the audit-* specialists against each chunk in parallel, then synthesize across chunks. Specialist briefs and anti-bias contracts live in the agent files (audit-triage, audit-logic, audit-security, audit-simplification, audit-research, audit-architecture) — this skill orchestrates.
Process
- Scope and partition. Get the file list (
git diff --name-only, inline — small). Group files into review chunks of max ~10 files each, organized by logical coherence: - Same domain or entity
- Same architectural layer (schemas, core logic, routers, triggers, frontend)
- Files that import each other belong in the same chunk
For each file in scope, capture a per-file diff:
`` git diff -- <path> > /tmp/hawk-review-large-pr-chunk-<n>-<file-slug>.patch 2>&1 ``
Never capture or read the concatenated multi-file diff — large PRs are exactly the case Big-output discipline exists for.
- Per-chunk triage and fan-out. For each chunk, run the same pattern as
code-audit:
a. Triage (always — this is a large PR; right-sizing the specialist subset per chunk is the whole point of partitioning). Call Agent(subagent_type="audit-triage", prompt=<chunk scope, signals>). Triage decision is internal; record it in the chunk report header but do not surface to the user unless asked. If triage's reply doesn't parse, fall back to tier=standard for that chunk and continue.
b. Fan out specialists in parallel for the triaged subset. Use the concrete agent names — install-time prefix rewriting depends on it:
`` Agent(subagent_type="audit-logic", prompt=<chunk user prompt>) Agent(subagent_type="audit-security", prompt=<chunk user prompt>) Agent(subagent_type="audit-simplification",prompt=<chunk user prompt>) Agent(subagent_type="audit-research", prompt=<chunk user prompt>) Agent(subagent_type="audit-architecture", prompt=<chunk user prompt>) ``
Skip any role not in the triage subset.
Do NOT call Agent(subagent_type="code-audit", …) — that's a skill, not a subagent. The audit-* names above are the only callable specialists.
The chunk user prompt contains:
- Per-file
rg -nslices from the chunk's capture files (not the raw concatenated diff) - Relevant
.agents/standards/content pasted inline - Relevant
.agents/common-mistakes/content pasted inline - One-line context:
Chunk N of M; files: <count>; layer: <layer>.
c. Merge per chunk the same way code-audit merges (dedupe by path:line, attach overlapping reasoning).
Wave semantics. Cap concurrency at 3–4 chunks per wave (one wave = (1 triage + N specialists) × 3–4 chunks running concurrently). Wait for every chunk in the current wave to return before starting the next wave. Streaming-style replacement ("queue the next chunk as soon as one finishes") is not allowed — it makes per-wave error handling and progress reporting unreliable.
- Synthesize across chunks. After all chunk reports return:
- Deduplicate — multiple chunks may flag the same cross-cutting issue (e.g. a shared utility used in different chunks).
- Resolve conflicts — if reviewers disagree, investigate which is correct.
- Verify high-risk recommendations yourself (schema changes, import changes, defensive guards).
- Categorize and prioritize — correctness bugs > security > architecture > duplication > dead code > readability.
Produce a consolidated report.
- Human approval gate. Present the consolidated report. Explain total findings by category, questionable items, and cross-cutting themes. Stop and wait for explicit approval. Never auto-apply review findings.
- Implement in small batches. After receiving approval, group approved items by file proximity (not by original chunk). Implement in batches of max 5–8 files. Run the check command after each batch. Fix any issues before starting the next batch.
Rules
- The synthesis phase is non-negotiable — it catches what individual chunk reviews miss.
- Human approval is non-negotiable — never auto-apply findings.
- Small implementation batches are non-negotiable — monolithic implementation crashes or introduces cascading errors.
- Specialists run as
audit-*subagents with their built-in anti-bias contract. Do NOT paste the goal, PR description, or branch name into specialist user prompts; only the chunk's diff slices, standards, and one-line chunk context. - Feed lessons back into
.agents/common-mistakes/after every review. - Big-output discipline. Heavy command output (project check, full
git diff, repo-wide search, long log, large fetch) goes to/tmp/hawk-review-large-pr-<step>.log, thenrg -n '<pattern>' /tmp/hawk-review-large-pr-<step>.log | head -50extracts what you need.Readthe file only withoffset/limit. 30+ file diffs are the worst offender for context bloat — this skill is the strictest enforcer: never capture or read the concatenated multi-file diff. Specialist user prompts receive narrowed slices only.