code-review git:20260803.f15259cA

Immutable. This exact content never changes and is served at /api/v1/blob/7043ee92a6def775.

---
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, invoke a subagent to perform the rest of this skill.
   - 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, automatically invoke a subagent to perform the review.
2. Retrieve the current changes (using `git diff`).
3. Read `.gemini/styleguide.md` if present.
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.