Menü
Conduct rigorous code review for git changes and return prioritized, actionable findings in a strict verdict/findings format. Trigger: explicit.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | code-review |
| description | Conduct rigorous code review for git changes and return prioritized, actionable findings in a strict verdict/findings format. Trigger: explicit. |
Examine proposed changes made by another engineer. Identify discrete, actionable issues that the original author would likely fix if they noticed them.
Think hard and be thorough. A sloppy review is worse than no review.
By default, run a comprehensive, balanced PR-style review. Cover the full change and all major risk areas (correctness, security, performance, cleanliness, and maintainability), not just one narrow angle.
If you were given a specific review focus, angle, or additional instructions (for example, "focus on performance" or "look only for security issues"), follow that requested focus instead of the default broad pass.
Infer scope from the user request. Wrapper prompts may include What to review: ..., but do not require that exact line.
Default to uncommitted changes when scope is not explicitly specified.
Use this mapping:
git status --short and git diff HEADgit diff main...HEADgit show HEADIf the request contains conflicting scope signals, ask a clarifying question first.
For every diff/show command, set bash maxOutputTokens to 32768.
Start with the diff, but do not stop there. Read surrounding code, trace call sites, check type definitions, and search for related patterns. Understand what the author was trying to accomplish before judging whether they succeeded.
Examine every changed file, not just the obvious ones. Trace how changes interact across files. Consider edge cases, error paths, and implicit assumptions. When changes in one file imply corresponding changes elsewhere and those are absent, treat that as a red flag. Do not guess when reading more code would give you the answer. If a change looks suspicious, verify before flagging.
Actively hunt for issues across these categories:
console.log, print statements), commented-out code, dead imports.Report a finding only when it is:
Report all qualifying findings, not just the first one. If none qualify, say so.
Prefix each finding title with one priority:
Write so the author understands at a glance. One paragraph max per finding. No filler ("Great job", "Thanks"). Explain why the issue matters and when it breaks. Mention specific scenarios or inputs if relevant.
Use short code blocks for snippets. Keep line ranges tight to pinpoint the problem. When providing replacement code, preserve exact leading whitespace (spaces vs tabs) and do not change outer indentation unless that is the fix.
Use "Correct" when there are no blocking issues (P0/P1). Use "Incorrect" when there are blocking bugs or broken functionality.
Gaps are things that matter for correctness but require information from outside the codebase to verify: external API contracts, deployment configuration, third-party service behavior, upstream schema compatibility. If the answer lives somewhere in the code, it is not a gap. Read the code and resolve it. Only list what genuinely cannot be determined from the repository alone.
Verdict: [Correct|Incorrect]
<one to three sentence summary>
## Findings
### [P#] <imperative title>
**Location**: `<file-path>:<line-range>`
<one to two paragraph description>
<optional suggestion code block(s)>
(...repeat for each finding, or "No findings." if none qualify)
## Gaps
- <gap, or "None.">
Apply Tau-specific canonical-contract, ownership-boundary, protocol-alignment, and regression patterns during deslop cleanup. Use only alongside the deslop skill in the Tau repository. Trigger: explicit.
Clean up, canonicalize, and tighten a specified target (often a branch of PR work from a junior or AI agent, but also a package, the current changes, or any other bounded slice), refactoring freely within the target when that raises overall quality. Trigger: explicit.
Split large diffs or change sets into natural review chunks, then guide the user through focused diff_review sessions. Trigger: explicit.
Create implementation plans in two phases: clarify requirements first, then produce a concrete step-by-step plan without writing code. Trigger: explicit.