‹ 首页

review-large-pr

@hawkyre · 收录于 昨天 · 上游提交 1 个月前

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 安装 校验哈希
npx oh-my-skill add hawkyre/hawk-skills/review-large-pr
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- hawkyre/hawk-skills/review-large-pr
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify hawkyre/hawk-skills/review-large-pr
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
28GitHub stars
~1.2K上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 6ffb2d6 · 表述以原文为准
它做什么

能自动把大型 PR 拆成小块,并行调用多个专家审查每个块,最后综合生成统一的审查报告。

什么时候触发

当你请求审查一个包含30个以上变更文件的大型拉取请求时触发。

装好后可以这样说
Claude会分块并行审查并给出综合报告。
会调用安全专家审查。
Claude按流程执行并行审查。
技能原文 SKILL.md作者撰写 · MIT · 6ffb2d6

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
  1. 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:
  2. Same domain or entity
  3. Same architectural layer (schemas, core logic, routers, triggers, frontend)
  4. 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.

  1. 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 -n slices 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.

  1. Synthesize across chunks. After all chunk reports return:
  2. Deduplicate — multiple chunks may flag the same cross-cutting issue (e.g. a shared utility used in different chunks).
  3. Resolve conflicts — if reviewers disagree, investigate which is correct.
  4. Verify high-risk recommendations yourself (schema changes, import changes, defensive guards).
  5. Categorize and prioritize — correctness bugs > security > architecture > duplication > dead code > readability.

Produce a consolidated report.

  1. 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.
  1. 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, then rg -n '<pattern>' /tmp/hawk-review-large-pr-<step>.log | head -50 extracts what you need. Read the file only with offset/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.
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。