Verify PR

Independent CTO review of a PR before merge. Don't trust the worker's claims — verify yourself.

Steps

1. Read the PR

gh pr view <number> --json title,body,files,labels,commits,headRefName
gh pr diff <number>

2. Check scope discipline

• •One concern per PR. If the diff touches unrelated files, flag it.
• •Count the commits. If there are commits addressing different concerns, flag it.
• •The test: can you describe this PR in one sentence without "and"?

3. Check for Closes reference

• •The PR body must contain Closes #<issue-number>
• •If missing: flag — the issue won't auto-close on merge

4. Check the actual code

• •Read every changed file. Don't just skim the diff.
• •Look for: security issues, hardcoded values that should be constants, missing error handling at system boundaries
• •Look for: over-engineering, unnecessary abstractions, added complexity beyond what the issue asked for
• •Look for: stale references (old project IDs, wrong URLs, outdated constants)

5. Verify the change works

For code changes:

• •Pull the branch: git fetch origin <branch> && git checkout <branch>
• •Run relevant tests or the script with --dry-run
• •For visual changes: take a screenshot and look at it

For config/automation changes:

• •Trace the execution path mentally — will this actually fire in production?
• •Check launchd plists, cron entries, GitHub Actions workflows for correctness

6. Check board state

python3 scripts/board_view.py

• •Is the issue on the board?
• •Is it in the right column?

7. Decision

• •PASS: Label auto-merge if it's a non-strategy change, or comment "Ready for review" for Jon
• •FAIL: Comment with specific issues found. Don't merge.
• •NEEDS WORK: Comment with what needs fixing. Don't merge.

Say what you verified, not what you believe. Include evidence for your decision.