Backend PR Review

---
name: backend-pr-review
description: Reviews a backend pull request for code quality, API design, database patterns, and documentation. Focuses on Node.js, TypeScript, GCP, Pulumi — checking for consistency with existing patterns, proper error handling, and documentation. Use when the user says "review this backend PR", "backend review", "review the API changes", "check this PR", "look at this backend code", "review the API PR", "how does this PR look", or shares a PR with backend file changes (.ts, .js, routes/, api/, services/, models/, pulumi/).
argument-hint: [pr-number-or-url]
---

# Backend PR Review

Review a backend pull request with focus on correctness, consistency, and maintainability.

## Workflow

1. **Fetch PR context**
   - Run `gh pr view $ARGUMENTS --json title,body,additions,deletions,changedFiles,baseRefName,headRefName` to get PR metadata
   - Run `gh pr diff $ARGUMENTS` to get the full diff
   - Run `gh pr diff $ARGUMENTS --name-only` to get changed file list

2. **Identify backend files**
   - Filter to backend-relevant files: `.ts`, `.js` files under `api/`, `routes/`, `services/`, `models/`, `middleware/`, `lib/`, `utils/`, `pulumi/`, `scripts/`, `prisma/`, `migrations/`
   - Also include config files: `tsconfig.json`, `package.json`, `.env.example`, Pulumi YAML
   - If no backend files found, inform the user and stop

3. **Read project standards** (if available in the repo)
   - Check `eslint` config, `tsconfig.json` for active rules
   - Read nearby files in the same directory to understand existing patterns

4. **Review the diff against the checklist**
   - Read [references/review-checklist.md](references/review-checklist.md) for the full checklist
   - Evaluate each changed file against the criteria

5. **Present the review**

   Format as:

   ### Backend Review — {PR title} (#{number})
   **Files changed:** {count} | **+{additions} / -{deletions}**

   #### Summary
   2-3 sentence overview of what the PR does.

   #### Findings
   For each finding, use:
   - **file:line** — Description of the issue or suggestion
   - Categorize as: `[must-fix]`, `[suggestion]`, `[nit]`, or `[praise]`

   #### Verdict
   One of: **Approve**, **Approve with suggestions**, **Request changes**
   Brief rationale.

## Tone

Direct, professional, constructive. Brief praise where deserved. Humor is fine sparingly — never sarcastic about someone's code. Focus on the code, not the author. Frame suggestions as improvements, not criticisms.