メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Plan a multi-PR feature, migration, or architectural change before writing code. Writes a `.plans/<slug>/` directory of HTML documents (with inline UI mockups and a review-tracking layer) — a 1-page `overview.html` for human review, a mandatory `data-model.html` that locks the schema before anything else, a terse `plan.html` of dependency-ordered increments, an ADR-style `decisions.html`, and a `verification.html` acceptance script. Use whenever the user says "plan this feature", "scope out the migration", "/plan-large", "architect this rollout", "I need a plan covering schema and API", "design this across multiple PRs", or "break this work up". Also use whenever the work touches a database migration, even if it's only two PRs — schema-first is the gate. Runs a blind self-review subagent before presenting. Do NOT use for single-PR changes — bail to `plan-small` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.
Plan a single-PR change end-to-end before writing code. Writes a terse `.plans/<slug>/plan.html` (HTML, with inline UI mockups where a screen changes, rendered through the shared design system) covering files to touch, data-model changes, edge cases, verification, and decisions/assumptions sourced to code or user. Use whenever the user says "plan this", "scope this out", "write up a plan for X", "/plan-small", "let's plan the new flag", or "plan before we start". Also use whenever the user describes a small feature without explicitly asking to plan — propose a plan before coding. Asks only what code can't answer (in-repo PRDs count), surfaces planned assumptions alongside questions, then runs a blind self-review subagent before presenting. Do NOT use for multi-PR work, schema migrations beyond adding a nullable column, or sequenced increments — bail to `plan-large` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.
Aggressive cleanup audit scoped to the user's specified changes plus tangibly-relevant surrounding code. Same blind audit-* specialists as code-audit, with a maximum-improvement posture — any code in the expanded review scope that can be cleaner WILL be made cleaner. Small fixes applied inline; big fixes (>5 files, schema, public API, redesigns) routed through `/plan-small` or `/plan-large`. Plan-overrides — when the audit reveals the original plan was wrong — route through `/plan-large` by default. Always improve over preserve.
Execute a plan increment-by-increment with the audit-* specialists running independently at strategic checkpoints. Use whenever the user says "implement the plan with audits", "audited implementation", "run with audits", "implement with cleanup checkpoints", "audit as you go", or invokes /implement-plan-audited. Inherits the full per-increment verification loop from `implement-plan` (done-criteria evidence, layered retry ladder, file-divergence check, outcome records) and adds checkpoint annotation, blind parallel audits, audit-fix verification (each FIX closes its own loop), plan-override propagation, and BEHAVIOR_CHANGE.md artifacts. Two modes — `manual` stops between increments for user review; `auto` applies audit fixes and proceeds without interruption, designed for hours of unattended execution. Specialists are blind to the plan and the goal. Do NOT use for unaudited plan execution — use `implement-plan`. Do NOT use for one-shot audits of existing code — use `code-audit`. Do NOT use for planning or repl
Execute an approved plan increment-by-increment with deterministic verification at each step. Use whenever the user says "implement the plan", "run the plan", "execute the plan", "work through the increments", "do the plan", or invokes /implement-plan. Done-criteria are checked against evidence on disk, not asserted from memory; failures escalate through a layered ladder rather than repeated identical attempts; existing code gets behavior-preservation tests before modification; file divergence (touched vs declared) is reconciled before each commit; structured outcome records land in the plan file. Designed for fresh sessions with no prior context. Do NOT use for planning itself — use `plan-small` or `plan-large`. Do NOT use for unplanned coding without a plan file — use `coding-process`. Do NOT use when the user wants audits in the loop — use `implement-plan-audited`.
Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.
SOC 職業分類に基づく
| name | review-large-pr |
| description | 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. |
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.
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:
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:
rg -n slices from the chunk's capture files (not
the raw concatenated diff).agents/standards/ content pasted inline.agents/common-mistakes/ content pasted inlineChunk 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:
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.
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..agents/common-mistakes/ after every
review.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.