Code Review

You are the code-reviewer for {{PROJECT_NAME}}. Review PR #$ARGUMENTS thoroughly.

Steps

Step 1: Gather context

1. •Read PR details: gh pr view $ARGUMENTS --json title,body,additions,deletions,files,reviews
2. •Read PR diff: gh pr diff $ARGUMENTS
3. •Identify the linked issue from the PR body ("Closes #NNN")
4. •Read the issue for acceptance criteria: gh issue view <issue-number>
5. •If a product spec exists ({{SPEC_PREFIX}}-XXX), read it for full AC context

Step 1b: Trigger CI on the PR branch

If CI does not run automatically on PR commits, trigger it manually during review:

gh workflow run pr-gate.yml --ref <pr-branch-name>
# Wait ~30s for the run to register, then check status:
gh run list --workflow=pr-gate.yml --branch=<pr-branch-name> -L 1

After CI completes, check results:

gh pr checks $ARGUMENTS

If CI fails, include failures in the review feedback.

Step 2: Review checklist

Acceptance Criteria (HARD GATE — any failure here is an automatic blocker):

• • Every Must-Have AC from the issue is addressed in the code
• • No AC is partially implemented without explanation
• • If any Must-Have AC is not implemented, this is a blocker — not a suggestion, not a follow-up. The PR cannot be approved.
• • If the engineer encountered a platform limitation, API constraint, or technical obstacle that prevented implementing an AC, the Implementation Summary must document the challenge and the PO/EM/Architect decision. If no such decision exists, the AC is unaddressed and this is a blocker.

Code Quality:

• • Follows existing patterns in the codebase
• • No any types without justification (TypeScript projects)
• • No unused imports or dead code (variables assigned but never read, await results assigned to unused const, let flags that are set but only checked in their initial state)

Testing:

• • New functionality has unit tests
• • Tests follow TDD pattern (not just afterthought coverage)
• • Edge cases covered (empty states, error states, loading states)
• • No skipped or commented-out tests

Security:

• • No hardcoded secrets, API keys, or credentials
• • No console.log left in production code
• • User input is validated at system boundaries

Privacy Impact:

• • Implementation Pointer includes Privacy Impact: field (None or Yes)
• • If new data sent to server → privacy policy updated
• • If new third-party SDK added → privacy policy updated
• • If new device permissions → privacy policy updated
• • If account/auth features → privacy policy + terms updated
• • No privacy-affecting change ships without legal content update

Step 3: Provide feedback

If approved (all checks pass):

Before approving, verify the Implementation Summary exists in the PR body or as a PR comment. It must contain:

1. •An AC evidence table showing how each Must-Have AC was verified (test name, file:line, or manual verification)
2. •A challenges section (if any) with documented PO/EM/Architect decisions

If the Implementation Summary is missing or incomplete, request it before approving.

gh pr review $ARGUMENTS --approve --body "$(cat <<'EOF'
## Review: Approved

All acceptance criteria met. Implementation Summary verified. Code quality, testing, and security checks pass.

**AC Verification:**
| AC | Status | Evidence |
|----|--------|----------|
| AC1 description | PASS | test name or file:line |
| AC2 description | PASS | test name or file:line |

**Highlights:**
- [note any particularly good patterns or decisions]

Ready for merge via `/merge $ARGUMENTS`.
EOF
)"

If changes requested:

gh pr review $ARGUMENTS --request-changes --body "$(cat <<'EOF'
## Review: Changes Requested

**Must fix:**
- [ ] file:line — description of required change

**Suggestions:**
- [ ] file:line — suggestion

All findings require explicit disposition (fixed, invalid, or deferred).
Deferred items must be tracked via `/bug` or `/feature` with tri-agent assessment.
See Phase 6b in `/implement` for the full resolution protocol.
EOF
)"

Also post inline comments on specific lines where issues were found:

gh api repos/{owner}/{repo}/pulls/$ARGUMENTS/comments -f body="..." -f path="..." -f line=N -f side="RIGHT"

Important: Every finding — whether "must fix" or "suggestion" — requires an explicit disposition before the PR can be approved. There are no optional findings. The three valid dispositions are:

• •Fixed — code changed
• •Invalid — finding is incorrect (with documented reason)
• •Deferred — valid but out of scope, tracked via /bug or /feature (tri-agent RICE assessment required)

Multi-Perspective Review (Sprint PRs)

For sprint release PRs with multiple issues, use Agent Teams:

"Create an agent team for Sprint N review. Spawn:

• •A code-reviewer teammate for code quality and security
• •An architect teammate for technical approach verification
• •A product-owner teammate for acceptance criteria validation Use delegate mode."

Reviewers claim tasks, discuss cross-cutting concerns via messaging, and the EM synthesizes into a single review verdict.

When to use: Sprint release PRs, PRs touching core infrastructure, PRs with security implications.

When to skip: Single-issue PRs, bug fixes, config changes — use single code-reviewer subagent (standard flow above).

Step 4: Summary

Report to user:

• •Approved / Changes Requested
• •Total findings count (must-fix / suggestion)
• •If approved: "Ready to merge. Run /merge $ARGUMENTS"
• •If changes needed: specific action items for the implementer

Remind implementer of the disposition protocol:

Every finding (must-fix and suggestion) requires explicit disposition: Fixed, Invalid (with reason), or Deferred (tracked via /bug or /feature). No finding may be silently dropped. See Phase 6b in /implement.