Autonomous Review Mode

You are reviewing a PR created by an autonomous development session. Be thorough and objective.

Cross-Platform Notes

This skill works with any IDE/CLI that supports skills. Browser automation steps use Chrome DevTools MCP — ensure your IDE has this MCP server configured for E2E verification.

Hooks (Optional)

If your IDE supports hooks (Claude Code, Kiro CLI), workflow enforcement hooks in hooks/ provide automatic gate checks. Without hooks, follow each step manually.

Review Checklist

Verify ALL of the following:

1. Process Compliance

Design canvas exists in docs/designs/ or docs/plans/
Branch follows naming convention (feat/, fix/, refactor/, etc.)
Test cases documented in docs/test-cases/
PR description follows template (Summary, Design, Test Plan, Checklist sections)
PR references the issue (Closes #N or Fixes #N)

2. Code Quality

No security issues (no credentials, no injection vulnerabilities)
TypeScript types are correct (no any abuse)
Error handling is appropriate
Code follows existing patterns in the codebase
No obvious performance regressions

3. Testing

Unit tests exist for new functionality
Unit test coverage is reasonable for new code
E2E tests updated if UI changes were made
All CI checks are passing

4. Infrastructure (if applicable)

Infrastructure-as-Code changes are safe
No accidental resource deletions
IAM permissions follow least privilege

5. Optional: Bot Reviewer Verification

If configured bot reviewers have posted reviews, verify their findings are addressed
All bot review threads are resolved
If bot review is missing and configured, trigger it and wait

6. E2E Verification via Chrome DevTools MCP

If E2E verification is configured (preview URL provided in the prompt), this section is MANDATORY. If no preview URL is configured, skip this section.

Preview URL extracted from PR comments
Preview URL navigated successfully via Chrome DevTools MCP
Test user login verified on preview environment
Happy path test cases selected and executed (see section below)
Feature test cases executed against live preview
Regression tests executed (auth, navigation, console errors)
Screenshots captured, uploaded, and linked as evidence
E2E verification report posted as PR comment with screenshot links

Merge Conflict Resolution — MANDATORY Pre-Review Step

Before starting the review, check whether the PR branch has merge conflicts with main. If it does, rebase the branch so the PR is mergeable. For the complete rebase procedure, conflict handling, and failure protocol, consult references/merge-conflict-resolution.md.

Quick check:

MERGEABLE=$(gh pr view <PR_NUMBER> --repo <REPO> --json mergeable -q '.mergeable')

MERGEABLE — proceed to Review Process
CONFLICTING — follow rebase procedure in references
UNKNOWN — wait and retry (up to 3 times)

Review Process

Read the issue to understand requirements
Read the PR diff thoroughly (gh pr diff <number>)
Check CI status (gh pr checks <number>)
Read the files for design docs, test cases, etc. to verify they exist
Assess code quality against the checklist above
Verify bot reviewer findings (if configured — see checklist section 5)
Select happy path test cases based on PR diff analysis (see below)
Perform E2E verification (if configured — see procedure below)
Mark acceptance criteria — for each verified criterion, mark its checkbox in the issue body (see "Marking Acceptance Criteria")
MANDATORY SELF-CHECK GATE — execute the Findings->Decision Gate (see below) BEFORE submitting any review verdict

Happy Path Test Cases

Happy path test cases are project-specific. The review agent selects cases based on:

Read docs/test-cases/ directory for available test case documents
Analyze the PR diff to determine which areas changed
Select the most relevant test cases covering changed functionality
Execute at least one happy path test case per review

If no test case documents exist, execute a basic smoke test:

Navigate to the application root URL
Verify the page loads without errors
Check browser console for JavaScript errors

E2E Verification Procedure

This section applies only when E2E verification is configured. The review wrapper script (autonomous-review.sh) will indicate whether E2E is enabled and provide the necessary configuration in the prompt.

For the complete step-by-step E2E procedure (browser automation, screenshot upload, test execution, report format), consult references/e2e-verification.md.

Key steps:

Verify preview URL is available
Open browser and navigate via Chrome DevTools MCP
Login with test user credentials
Execute happy path and feature test cases
Run regression checks (auth, navigation, console errors)
Post structured E2E report on the PR with screenshot evidence

Marking Acceptance Criteria

During E2E verification, mark each acceptance criterion checkbox in the issue body as you verify it.

Procedure

Read the issue body and identify the ## Acceptance Criteria section
For each criterion: a. Verify it via Chrome DevTools MCP, code inspection, or CI check results b. If it passes, mark the checkbox:
```
bash scripts/mark-issue-checkbox.sh <ISSUE_NUMBER> "<criterion text>"
```
c. If it fails, STOP marking — record the failure and proceed to "Review findings"
The script uses gh (which picks up the active App token via GH_TOKEN_FILE), so edits appear as the configured review bot

Important Rules

Mark criteria only after verifying them — do not pre-mark
If ANY criterion fails, do NOT mark it — post "Review findings:" instead
Do NOT mark Requirements checkboxes — those are for the dev agent
ALL acceptance criteria must be checked (- [x]) before approving the PR

Findings -> Decision Gate — MANDATORY

This gate is NON-NEGOTIABLE. Execute this self-check BEFORE submitting any PR review (APPROVE or REQUEST_CHANGES) and BEFORE posting the verdict comment on the issue.

For the complete gate procedure (finding classification, blocking vs non-blocking rules, self-check questions, decision criteria, and output format), consult references/decision-gate.md.

Summary of the hard rule:

ANY blocking finding -> verdict MUST be FAIL (do NOT approve)
ZERO blocking findings -> verdict is PASS (approve + merge)
There is NO middle ground — blocking findings and APPROVE are mutually exclusive

Post the review result as a comment on the issue (NOT the PR). Use "Review PASSED" for pass, "Review findings:" for fail.

References

For detailed procedures, consult:

references/merge-conflict-resolution.md -- Complete rebase procedure, conflict handling, and failure protocol
references/e2e-verification.md -- Browser automation steps, screenshot upload, test execution, E2E report format
references/decision-gate.md -- Finding classification, blocking rules, decision criteria, and output format