code-review

name	code-review
description	Provide actionable feedback on code changes. Focuses on bugs, security issues, and structural problems.

Code Review

Review code changes using THREE (3) to FIVE (5) parallel subagents and correlate results into a summary ranked by severity.

Use the provided user guidance to steer the review and focus on specific code paths, changes, and/or areas of concern.

User Guidance: $ARGUMENTS

Default Behavior

1. Review uncommitted changes by default (git diff and git diff --staged)
2. If no uncommitted changes exist, review the last commit (git show HEAD)
3. If the user provides a pull request number or link, use gh pr diff <number> to fetch changes

Workflow

1. First, determine what to review based on the rules above
2. Check if the changes include AWS infrastructure files:
   • Terraform files (*.tf) containing AWS patterns (provider "aws", aws_ resources, or hashicorp/aws)
   • CDK files (TypeScript files containing aws-cdk, @aws-cdk, cdk.Stack, cdk.App, or Construct patterns)
3. Check if the changes add new dependencies by looking for additions in:
   • package.json (new entries in dependencies or devDependencies)
   • requirements.txt, pyproject.toml, setup.py, setup.cfg
   • Cargo.toml (new entries in [dependencies] or [dev-dependencies])
   • go.mod (new require entries)
   • Gemfile, *.gemspec
   • composer.json
   • Any other language-specific dependency manifest
   • Only trigger on newly added dependencies, not version bumps of existing ones
4. Launch parallel Task agents:
   • THREE agents with subagent_type: general-purpose, each instructed to:
     • Read the full file context (not just diffs) to understand surrounding logic
     • Focus on different aspects: bugs/logic, security/auth, and patterns/structure
     • Follow the detailed review guidelines below
   • If AWS infrastructure detected: ONE additional agent with subagent_type: aws-limits to review AWS service quota violations in the changed infrastructure files
   • If new dependencies detected: ONE additional agent with subagent_type: general-purpose to verify license compliance:
     • Extract the list of newly added dependency names and versions from the diff
     • For each new dependency, determine its license (use the package registry API or repository metadata — e.g. npm view <pkg> license, pip show <pkg>, cargo info <pkg>, or check the project's GitHub repo)
     • Flag any dependency whose license is not in the permissive allowlist: MIT, ISC, BSD-2-Clause, BSD-3-Clause, Apache-2.0, 0BSD, Unlicense, CC0-1.0, BlueOak-1.0.0
     • For flagged dependencies, report: package name, detected license, and why it may be problematic (e.g. copyleft, proprietary, unknown)
     • Severity: Critical for proprietary/unknown licenses, High for copyleft (GPL, AGPL, LGPL, MPL), Medium for weak copyleft or uncommon licenses
5. Collect all findings and produce a consolidated summary
6. Rank issues by severity: Critical > High > Medium > Low
7. Include file paths and line numbers for each finding
8. Suggest fixes where appropriate

Review Guidelines

Diffs alone are not enough. Read the full file(s) being modified to understand context. Code that looks wrong in isolation may be correct given surrounding logic.

What to Look For

Bugs — Primary focus

• Logic errors, off-by-one mistakes, incorrect conditionals
• Missing guards, unreachable code paths, broken error handling
• Edge cases: null/empty inputs, race conditions
• Security: injection, auth bypass, data exposure

Structure — Does the code fit the codebase?

• Follows existing patterns and conventions?
• Uses established abstractions?
• Excessive nesting that could be flattened?

Performance — Only flag if obviously problematic

• O(n²) on unbounded data, N+1 queries, blocking I/O on hot paths

Before You Flag Something

• Be certain. Don't flag something as a bug if you're unsure — investigate first.
• Don't invent hypothetical problems. If an edge case matters, explain the realistic scenario.
• Don't be a zealot about style. Some "violations" are acceptable when they're the simplest option.
• Only review the changes — not pre-existing code that wasn't modified.

Output Guidelines

• Be direct about bugs and why they're bugs
• Communicate severity honestly — don't overstate
• Include file paths and line numbers
• Suggest fixes when appropriate
• Matter-of-fact tone, no flattery

Severity Levels

• Critical: Security vulnerabilities, data loss, crashes in production
• High: Bugs that will cause incorrect behavior, broken functionality
• Medium: Code that works but has issues (poor error handling, edge cases)
• Low: Style issues, minor improvements, suggestions

Output Format

## Code Review Summary

### Critical Issues
- [file:line] Description of critical bug/security issue

### High Priority
- [file:line] Description

### Medium Priority
- [file:line] Description

### Low Priority / Suggestions
- [file:line] Description

### AWS Service Limits (if applicable)
- [file:line] Description of limit concern

### License Compliance (if applicable)
- [package-name] License: <license> — Reason flagged

### Summary
Brief overall assessment of the changes.