code-review

Code Review

Target: $ARGUMENTS (optional PR number, branch, path, or diff scope)

Workflow

Progress checklist:

Code Review:
- [ ] Step 1: Identify review target
- [ ] Step 2: Gather change context
- [ ] Step 3: Evaluate the change
- [ ] Step 4: Separate findings from noise
- [ ] Step 5: Deliver findings-first review

Step 1: Identify Review Target

• If $ARGUMENTS is empty and the request is about a PR, run gh pr list to show open PRs, then ask the user which PR to review.
• If $ARGUMENTS looks like a PR number, run gh pr view <number> to capture the title, status, base branch, head branch, and summary.
• Otherwise treat the target as local changes, a branch, a commit range, or a file path.

Step 2: Gather Change Context

• For PR review, run gh pr diff <number>.
• For local review, inspect git diff, git diff --staged, or the diff for the requested range.
• Read the changed files with surrounding context. Do not review the raw diff in isolation.
• Identify the scope: feature, bug fix, refactor, test, docs, or mixed.
• If gh is unavailable or unauthenticated, say so clearly and fall back to the available local diff.

Step 3: Evaluate the Change

Review for:

• Correctness — edge cases, null or empty inputs, error handling, stale state, off-by-one logic, async races, retries, cancellation, and timeouts.
• Maintainability — naming, duplication, single responsibility, magic values, avoidable complexity, and consistency with nearby code.
• Performance — N+1 queries, repeated expensive work, render-loop costs, unnecessary allocations, and over- or under-used memoization.
• Type safety — missing narrowing, unchecked unions, overly broad types, and unclear public API return types.
• Testing — coverage for happy paths, failure paths, and the most likely regression cases.
• Security — auth gaps, injection risks, secret handling, unsafe parsing, XSS, SSRF, or CSRF when relevant.

Step 4: Separate Findings from Noise