|
| 1 | +______________________________________________________________________ |
| 2 | + |
| 3 | +## allowed-tools: Bash(git diff:*), Bash(git log:*), Bash(git show:*), Bash(git blame:*), Bash(git rev-parse:\*) description: Code review local git diff changes |
| 4 | + |
| 5 | +Provide a code review for local git changes. |
| 6 | + |
| 7 | +**Arguments:** `$ARGUMENTS` (optional commit range, e.g., `HEAD~3..HEAD`, `main..feature`, or empty for unstaged changes) |
| 8 | + |
| 9 | +To do this, follow these steps precisely: |
| 10 | + |
| 11 | +1. Determine the diff to review based on arguments: |
| 12 | + |
| 13 | + - If `$ARGUMENTS` is empty: review unstaged changes (`git diff`) |
| 14 | + - If `$ARGUMENTS` is `--staged`: review staged changes (`git diff --staged`) |
| 15 | + - If `$ARGUMENTS` contains a commit range (e.g., `HEAD~3..HEAD`, `main..feature`): review that range (`git diff <range>`) |
| 16 | + - If `$ARGUMENTS` is a single commit: review changes introduced by that commit (`git show <commit>`) |
| 17 | + |
| 18 | +1. Launch a haiku agent to check if there are any changes to review. If no changes found, stop and inform the user. |
| 19 | + |
| 20 | +1. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including: |
| 21 | + |
| 22 | + - The root CLAUDE.md file, if it exists |
| 23 | + - Any CLAUDE.md files in directories containing files modified in the diff |
| 24 | + |
| 25 | +1. Launch a sonnet agent to view the diff and return a summary of the changes |
| 26 | + |
| 27 | +1. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes: |
| 28 | + |
| 29 | + - File path and line number(s) |
| 30 | + - Description of the issue |
| 31 | + - Reason it was flagged (e.g., "CLAUDE.md adherence", "bug", "security") |
| 32 | + |
| 33 | + The agents should do the following: |
| 34 | + |
| 35 | + Agents 1 + 2: CLAUDE.md compliance sonnet agents |
| 36 | + Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents. |
| 37 | + |
| 38 | + Agent 3: Opus bug agent (parallel subagent with agent 4) |
| 39 | + Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff. |
| 40 | + |
| 41 | + Agent 4: Opus bug agent (parallel subagent with agent 3) |
| 42 | + Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code. |
| 43 | + |
| 44 | + **CRITICAL: We only want HIGH SIGNAL issues.** This means: |
| 45 | + |
| 46 | + - Objective bugs that will cause incorrect behavior at runtime |
| 47 | + - Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken |
| 48 | + |
| 49 | + We do NOT want: |
| 50 | + |
| 51 | + - Subjective concerns or "suggestions" |
| 52 | + - Style preferences not explicitly required by CLAUDE.md |
| 53 | + - Potential issues that "might" be problems |
| 54 | + - Anything requiring interpretation or judgment calls |
| 55 | + |
| 56 | + If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time. |
| 57 | + |
| 58 | +1. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations. |
| 59 | + |
| 60 | +1. Filter out any issues that were not validated in step 6. This step will give us our list of high signal issues for our review. |
| 61 | + |
| 62 | +1. Output the review to the terminal in a clear, actionable format: |
| 63 | + |
| 64 | +______________________________________________________________________ |
| 65 | + |
| 66 | +## Local Code Review |
| 67 | + |
| 68 | +**Diff reviewed:** `[describe what was reviewed - e.g., "unstaged changes", "HEAD~3..HEAD", etc.]` |
| 69 | + |
| 70 | +### Summary |
| 71 | + |
| 72 | +[Brief summary of the changes from step 4] |
| 73 | + |
| 74 | +### Issues Found |
| 75 | + |
| 76 | +[If issues found, list each one:] |
| 77 | + |
| 78 | +**Issue 1:** [Brief title] |
| 79 | + |
| 80 | +- **File:** `path/to/file.ext` (lines X-Y) |
| 81 | +- **Type:** [bug/CLAUDE.md violation/security] |
| 82 | +- **Description:** [Clear description of the issue] |
| 83 | +- **Suggested fix:** [How to fix it] |
| 84 | + |
| 85 | +[Repeat for each issue] |
| 86 | + |
| 87 | +[If NO issues found:] |
| 88 | +No issues found. Checked for bugs and CLAUDE.md compliance. |
| 89 | + |
| 90 | +______________________________________________________________________ |
| 91 | + |
| 92 | +Use this list when evaluating issues in Steps 5 and 6 (these are false positives, do NOT flag): |
| 93 | + |
| 94 | +- Pre-existing issues not in the diff |
| 95 | +- Something that appears to be a bug but is actually correct |
| 96 | +- Pedantic nitpicks that a senior engineer would not flag |
| 97 | +- Issues that a linter will catch (do not run the linter to verify) |
| 98 | +- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md |
| 99 | +- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment) |
| 100 | + |
| 101 | +Notes: |
| 102 | + |
| 103 | +- Create a todo list before starting. |
| 104 | +- If referring to a CLAUDE.md rule, quote it directly. |
| 105 | +- Focus on actionable feedback that helps the developer improve the code before committing. |
0 commit comments