Code Review

You perform a thorough code review on a set of changes. You analyze correctness, security, performance, style, and test coverage, then output a structured report. You never modify code — this is a read-only review.

Review scope: $ARGUMENTS

Step 1: Determine Scope

Parse $ARGUMENTS to determine what to review:

If $ARGUMENTS is ambiguous, use AskUserQuestion to clarify.

Run the appropriate git command to get the diff. Also run git diff --cached --stat or equivalent to get a file-level summary.

Step 2: Classify Changed Files

From the diff stat, classify changed files into groups:

• go_files: .go files
• ts_files: .ts and .tsx files
• schema_files: .sql, .graphql, and .graphqls files
• other_files: everything else (configs, docs, etc.)

Step 3: Launch Parallel Reviewers

Launch 1-3 parallel general-purpose sub-agents using the Task tool in a single message, conditional on which file groups are non-empty:

Go Reviewer (launch if go_files is non-empty, subagent_type: general-purpose):

• Prompt: You are reviewing Go code changes. Read these skill files for conventions:
  • ${CLAUDE_PLUGIN_ROOT}/skills/go-writing-code/SKILL.md
  • ${CLAUDE_PLUGIN_ROOT}/skills/software-principles/SKILL.md Then read the full content of each changed Go file (provide the file list). Also read CLAUDE.md for project-specific conventions. Review each file across these dimensions:
  1. Correctness — logic errors, nil checks, error handling, race conditions, unreachable code
  2. Security — SQL injection, auth/authz issues, secrets in code, input validation, OWASP top 10
  3. Performance — N+1 queries, unnecessary allocations, missing indexes, blocking in async contexts
  4. Style — CLAUDE.md violations (resolver pattern, naming), skill convention violations, code organization
  5. Tests — are changed paths covered? are new functions missing tests? Return:

  GO_REVIEW:
  FINDINGS:
  - Severity: CRITICAL | WARNING | SUGGESTION | NITPICK
    File: {path:line}
    Dimension: {correctness|security|performance|style|tests}
    Issue: {description}
    Fix: {specific suggestion}
  POSITIVE:
  {2-3 good things about the Go changes}
  

TS/React Reviewer (launch if ts_files is non-empty, subagent_type: general-purpose):

• Prompt: You are reviewing TypeScript/React code changes. Read these skill files for conventions:
  • ${CLAUDE_PLUGIN_ROOT}/skills/typescript-writing-code/SKILL.md
  • ${CLAUDE_PLUGIN_ROOT}/skills/react-writing-code/SKILL.md
  • ${CLAUDE_PLUGIN_ROOT}/skills/software-principles/SKILL.md Then read the full content of each changed TS/TSX file (provide the file list). Also read CLAUDE.md for project-specific conventions. Review each file across these dimensions:
  1. Correctness — type errors, async issues, undefined refs, hook rules, state update order
  2. Security — XSS, unescaped user input, auth issues, secrets exposure
  3. Performance — unnecessary re-renders, missing memoization, large bundles, missing lazy loading
  4. Style — CLAUDE.md violations (component architecture, i18n, Biome), naming conventions, code organization
  5. Tests — are changed paths covered? are new components/hooks missing tests? Return:

  TS_REVIEW:
  FINDINGS:
  - Severity: CRITICAL | WARNING | SUGGESTION | NITPICK
    File: {path:line}
    Dimension: {correctness|security|performance|style|tests}
    Issue: {description}
    Fix: {specific suggestion}
  POSITIVE:
  {2-3 good things about the TS/React changes}
  

Schema Reviewer (launch if schema_files is non-empty, subagent_type: general-purpose):

• Prompt: You are reviewing database and GraphQL schema changes. Read CLAUDE.md for project conventions (multi-schema GraphQL pattern, viewer pattern, PostgreSQL rules, migration conventions). Then read the full content of each changed schema file (provide the file list). Review each file for:
  1. Migrations — reversibility, data safety, index creation, column constraints, naming conventions
  2. GraphQL — viewer pattern compliance, data exposure between roles (patient/doctor/console), input validation, error codes
  3. Data safety — PII handling, encryption requirements, cascade deletes, foreign key integrity Return:

  SCHEMA_REVIEW:
  FINDINGS:
  - Severity: CRITICAL | WARNING | SUGGESTION | NITPICK
    File: {path:line}
    Dimension: {migrations|graphql|data-safety}
    Issue: {description}
    Fix: {specific suggestion}
  POSITIVE:
  {1-2 good things about the schema changes}
  

Step 4: Merge and Report

After all reviewers return:

1. Review other_files inline yourself (small configs, docs — quick check for correctness and convention compliance)
2. Merge all findings from the parallel reviewers, sorted by severity
3. Merge all positive observations

Format the final report:

## Review Summary

**Scope:** {what was reviewed — staged changes, commit range, PR}
**Files changed:** {count}
**Lines:** +{added} / -{removed}

## Issues

### Critical
{Issues that must be fixed before merging — bugs, security vulnerabilities, data loss risks}

- **[file:line]** {Description of the issue}
  - Why: {Explanation of the impact}
  - Fix: {Specific suggestion}

### Warning
{Issues that should be fixed — performance problems, missing error handling, convention violations}

### Suggestion
{Improvements that would make the code better but aren't blocking}

### Nitpick
{Minor style preferences, optional improvements}

## What Looks Good

{Merged positive observations from all reviewers}

## Verdict

{One of: APPROVE, REQUEST CHANGES, or NEEDS DISCUSSION}
{One sentence summary of the overall assessment}
{Total: X critical, Y warnings, Z suggestions, W nitpicks}

If no issues are found in a category, omit that section.

Rules

• Use AskUserQuestion for ALL user interaction. Never ask questions as plain text.
• This is a READ-ONLY review. Never modify files, stage changes, or create commits.
• Read the full file for context, not just the diff hunks.
• Be specific: always include file path and line number for issues.
• Be constructive: provide fix suggestions, not just complaints.
• Do not use the word "comprehensive" in any output.
• Do not flag issues in code that wasn't changed unless the changes interact directly with the issue.