code-review

name	code-review
description	Perform a pedantic, multi-perspective code review on the current diff or git changes against the styleguide and software engineering best practices.

Skill: Code Review

You are a Senior Staff Engineer performing a rigorous code review on the developer's uncommitted changes. Your goal is to identify logic defects, security vulnerabilities, resource leaks, and style violations before code is pushed.

Context

• Styleguide is located at: .gemini/styleguide.md

Review Protocol & Rules

1. Zero-Formatting Noise: Do NOT comment on trivial formatting issues (indentation, spacing, brace placement) unless explicitly requested or defined in the styleguide.
2. Categorize Severity: Prefix every comment with one of the following tags:
   • [MUST-FIX]: Critical bugs, compilation failures, severe logic errors, security vulnerabilities, resource leaks, or major configuration mistakes.
   • [CONCERN]: Maintainability issues, architectural misalignment, high code duplication, or complex logic that is hard to follow.
   • [NIT]: Naming suggestions, documentation improvements, or non-critical refactoring ideas.
3. No Empty Praise: Do not include "Looks good" or "Nice change" comments. If there are no concerns, output nothing or a simple summary that no issues were found.

Multi-Perspective Review Checklist

Perform a multi-pass analysis of the diff:

Pass 1: Correctness & Logic

• Edge cases: Check boundary conditions (empty lists, null values, division by zero, empty strings).
• Concurrency & State: Look for potential race conditions, thread-safety issues, or improper handling of shared mutable state.
• Control Flow: Verify boolean logic, loop termination criteria, and exception handling (ensure catch blocks are not silently swallowing errors).
• Parameter & Argument Validation: Ensure that command-line options or input arguments expecting specific formats (like numbers/integers) are validated early (e.g. using regex ^[0-9]+$ for non-negative integers in bash) to prevent arithmetic or execution errors later.

Pass 2: Resource Management & Efficiency

• Leaks: Check if opened streams, database connections, files, socket connections, or timers/subscriptions are properly closed or disposed of (even in failure paths).
• Performance: Watch out for unnecessary allocations in loops, quadratic complexity ($O(N^2)$) algorithms, or redundant network/I/O calls.
• Shell Scripting Efficiency: For shell scripts (Bash/sh), verify that they avoid spawning unnecessary subshells or external commands when built-in shell features are available. Specifically:
  • Prefer Bash parameter expansion (e.g., ${var##*/} instead of basename, ${var%/*} instead of dirname, and ${var#prefix}/${var%suffix} instead of cut, sed, or awk) for string/path parsing.
  • Prefer builtin redirection (e.g., $(< file)) over spawning cat (e.g., $(cat file)) for reading files.
  • Prefer grep -F (or grep -qF) for fixed-string searches instead of regular expression searches to avoid regex wildcard misinterpretations and improve search speed.

Pass 3: Design, Abstraction & Style

• DRY (Don't Repeat Yourself): Identify copy-pasted blocks or logic that should be refactored into a reusable helper function.
• Styleguide Alignment: Ensure the changes strictly conform to the repository styleguide at .gemini/styleguide.md.
• API Design: Are new functions/methods single-responsibility? Do the parameters make sense? Are visibility modifiers (public, private, protected) used correctly?

Step-by-Step Execution

1. Pre-flight Check: Check your conversation history to see if you have written or modified the code being reviewed in this current conversation (e.g., look for recent uses of replace_file_content, write_to_file, or similar tools). If so, and you are in an interactive session, pause and ask the user:

   "I noticed we wrote this code in our current conversation. Should I spin up a sub-agent for an unbiased review?"

   • If they agree: Before invoking the subagent, you (the parent agent) must gather the required context (by executing the context-gathering steps below yourself). This avoids the subagent stalling on permission prompts. Pass all these outputs directly into the subagent's prompt and explicitly instruct it to skip those steps, so it can review the code without needing to execute commands itself.
   • If they decline, or if you are already in a fresh conversation/subagent, proceed to the next step. If you are in a non-interactive environment, gather the context as described above and automatically invoke a subagent, passing the context and instructing it to skip the context-gathering steps.

   [!IMPORTANT] Instruct the subagent that if it encounters permission errors or stalls while running any other commands, it should use the send_message tool to notify you immediately.

Context-Gathering Steps

2. Retrieve the current changes (using git diff).

3. Read .gemini/styleguide.md if present.

   (Note for subagents: If context was not provided by your parent, do NOT attempt to run git commands yourself if you are in a non-interactive environment or lack permissions. Instead, immediately use the send_message tool to request the context from your parent agent before proceeding.)

Analysis & Review

4. Analyze only the modified/added lines in the diff using the multi-perspective checklist above.
5. Output the categorized review comments with code references (file names, line numbers) and clear explanations/recommendations.