# Review > Reviews a diff since a fixed point across Standards, Spec, and risk gates. Use when reviewing a branch, PR, WIP, or "review since X". - Skill: `redpanda-data/review-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add redpanda-data/review-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/redpanda-data/review-2/raw - Safety review: pending (external: skill-scanner PASS, skillspector CAUTION) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: redpanda-data (https://skillmd.com/u/redpanda-data) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/redpanda-data/review-2 --- # Review Repo/code changes: run `/deslop` before commit, push, PR, or merge. Diff review from fixed point to `HEAD`. Keep Standards and Spec axes separate. ## Inputs If fixed point missing, ask: "Review against what -- branch, commit, or `main`?" Use: - Diff: `git diff ...HEAD` - Commits: `git log ..HEAD --oneline` ## Gather Spec source, first found wins: issue refs in commits via `docs/agents/issue-tracker.md`; user path; PRD/spec under `docs/`, `specs/`, `.scratch/`; none -> Spec axis reports "no spec available". Standards sources: `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING.md`, `CONTEXT.md`, `CONTEXT-MAP.md`, scoped `CONTEXT.md`, `docs/adr/`, style docs and config (`biome`, `eslint`, `tsconfig`, `prettier`, `.editorconfig`). ## Parallel review hats Spawn all review hats in one message before producing findings, matching `/grill-me` fan-out. Use `general-purpose` subagents. Main agent orchestrates only: gather sources, fan out, merge, dedupe, final report. Prefer `/swarm` under the hood when available: pass fixed point, changed files, sources, full required hat list, subagent prompt contract, and merge contract. If /swarm is unavailable, spawn hat subagents directly. Swarm must not reduce hats, evidence, lane ownership, or final output. Required hats: `ponytail-review-hat`, `thermo-nuclear-review-hat`, `resilience-review-hat`, `regular-review-hat`, `adversarial-review-hat`, `visual-review-hat`, `test-perf-review-hat`, `security-privacy-triage-hat`. - **`ponytail-review-hat`**: run `/ponytail-review` on every diff before other hats merge findings; output delete/stdlib/native/yagni/shrink opportunities or `Lean already. Ship.`. - **`thermo-nuclear-review-hat`**: run `/thermo-nuclear-code-quality-review` for release candidates, large PRs, risky refactors, security/privacy/perf/test concerns, or explicit nuclear/cold-audit asks; otherwise `SKIPPED` with reason. - **`resilience-review-hat`**: run `/resilience-review` for forms, validation, async/data, mutations, cache, state machines, config, destructive actions, or loading/error/empty states; otherwise `SKIPPED` with reason. - **`regular-review-hat`**: Standards and Spec pass. Never invoke /review recursively. If no spec, return `Spec: no spec available`. - **`adversarial-review-hat`**: ask "What could still be wrong if tests pass and implementation matches spec?" Max 3 findings. If no credible risk, return `APPROVED`. - **`visual-review-hat`**: run `/visual-review` for UI, copy, forms, routes, reports, CLI/TUI output, or visual behavior; otherwise `SKIPPED` with reason. - **`test-perf-review-hat`**: check TDD evidence, coverage gaps, flaky/missing tests, slow paths, render/network/bundle risk, and warning-free commands. - **`security-privacy-triage-hat`**: check auth, authorization, tenant boundaries, secrets, unsafe HTML, injection, SSRF, redirects, dependency execution, logging, analytics, PII, export/import; exploitable/privacy findings escalate to Thermo nuclear. Review priority hierarchy: 1. Ponytail review 2. Thermo nuclear review 3. Resilience review 4. Regular review 5. Adversarial review 6. Visual review 7. Test/perf review. Security/privacy triage feeds this hierarchy. No silent skips: all hats run at least triage; `SKIPPED` needs `skip_reason`, checked files/surfaces, and absent triggers. Never skip due to time, token budget, small diff, prior confidence, or another hat passing. Thermo nuclear is fail-open. Thermo nuclear and Resilience skip only when diff evidence proves no matching risk surface. If unsure, run the review. PR value gate: always quantify the Major improvement before verdict. Code is liability: if added surface area is not product value, defensive correctness, or test confidence, treat it as low-value until justified. Value score: HIGH|MEDIUM|LOW|NONE. Maintenance/security/resilience/test-only can score HIGH. If no Major improvement reaches MEDIUM, run `/steelman` internally against "this PR adds meaningful value". If `/steelman` confirms low-value, gate blocks pending explicit override, split, or stronger value justification. Subagent prompt contract: include fixed point, changed files, diff command, commits command, exact review type, and sources; require lane ownership, evidence, severity, priority label, required change, and PR-comment-ready text; cap at 400 words; findings must be diff-introduced, user-impacting, actionable. Each hat emits: `{ "reviewer": "", "hat": "", "status": "APPROVED|FINDINGS|BLOCKED|SKIPPED", "findings": [], "must_answer": [], "skip_reason": "" }`. Merge contract: wait for all hats; dedupe by file/range + reference; Dedupe across hats by root cause, not wording; preserve Standards and Spec separately; keep highest severity on disagreement; if subagents unavailable, stop unless user accepts degraded solo review. ## PR comments After all hats finish, merge, dedupe, and verify priority before posting or printing review comments. Do not comment during individual hats. If the target is a GitHub PR and PR comment tooling is available, post inline PR comments automatically to the open or targeted PR; the user does not need to ask. Resolve target in order: explicit PR URL/number, PR targeted by the skill invocation, then the open PR for the current branch. If PR comment tooling is unavailable, no PR exists, or multiple PRs are ambiguous, emit comment-ready output instead. Do not dump the whole review into the PR. Comment only distinct, high-confidence, actionable findings with tight file/line evidence. Prefer P0/P1 comments; include P2 only when the fix is clear and useful; keep P3 Patch or P3 Future items in the summary unless explicitly worth an inline note. In legacy terms: keep P3 and Future items in the summary. Priority mapping: P0 for Blocker, P1 for Major, P2 for Minor, P3 for Patch or Future. Legacy aliases normalize to this scale: P0 bug/blocker, P1 major, P2 minor, P3 patch, Future follow-up. Every posted/comment-ready item must include exactly one priority label. P0/P1 block merge; P2 fix or track; P3 optional polish or later cleanup. Every confirmed bug is P0 or P1. If a bug is diagnosed and reproduced, it must be posted inline with the matching P0/P1 priority; do not demote bugs to P2/P3 because the fix is small. P0 = merge-blocking crash, data loss, security/privacy exposure, corrupt state, outage, impossible core flow, or entirely missing required behavior. P1 = normal-user defect, regression, broken contract/spec, fake success, major accessibility failure, or high-risk edge. Place each PR comment on the tightest changed file/range that introduces the issue. Prefer the exact changed line; if the exact line is not in the diff, use the nearest changed line with context. If no accurate inline location exists, use a top-level PR comment-ready item and explain why inline placement is unsafe. Comment template: What, Why, Suggested fix, One-shot prompt. Prefix every comment with Priority. Keep each comment short. One-shot prompt must be one sentence when simple and name repo/branch, file/range, exact requested change, and verify command when safe; otherwise say why no safe one-shot exists. ### Standards Read standards + diff. Report documented violations only. Cite file + rule. Separate hard violations from judgment calls. Skip what tooling enforces. Max 400 words. ### Spec Read spec + diff. Report missing/partial requirements, scope creep, wrong behavior. Quote spec line for each finding. Max 400 words. Skip if no spec. ## Local review routing Each hat checks its gate: UI/copy/forms/routes/reports/CLI/TUI/visual -> `/visual-review`; forms/validation/async/data/mutations/cache/state/config/destructive/error/loading/empty -> `/resilience-review`; auth/permissions/tenant/secrets/HTML/parsing/network/file/deps/logging/privacy -> security/privacy triage; assumptions/abuse/bypass/rollback/surprise/spec holes -> adversarial; behavior/tests/perf/bundle/runtime/render/network -> test/perf; release candidate/large PR/risky refactor/security/privacy/perf/test concern -> `/thermo-nuclear-code-quality-review`. Do not recursively invoke /review from a local gate already running inside `/review`. Do not duplicate local gate reports. Link or summarize verdicts. ## Output See [REFERENCE.md](REFERENCE.md) for detailed report schema and examples. ```md ## Review Fixed point: Diff: `git diff ...HEAD` Subagents: ponytail-review-hat: | thermo-nuclear-review-hat: | resilience-review-hat: | regular-review-hat: | adversarial-review-hat: | visual-review-hat: | test-perf-review-hat: | security-privacy-triage-hat: ## Standards: ## Spec: ## Local review gates: Ponytail review: pass|findings; ## PR value gate: Major improvement: Value score: HIGH|MEDIUM|LOW|NONE Steelman: not needed | ran: Gate: pass | low-value | blocked pending override ## Summary: What's working: <1-3 bullets>; Needs attention: ; Follow-ups: ## PR comments: Posted: | Comment-ready fallback: | Skipped as summary-only: - [P0 Blocker|P1 Major|P2 Minor|P3 Patch|P3 Future] -- <posted|comment-ready|summary-only> ``` Rules: keep Standards and Spec separate. Findings need evidence. No vague praise.