Pre-Landing Code Review

Semantic code review that reads the diff and reasons about correctness, security, and edge cases. Complements /quality-gate (mechanical checks) — run both before opening the pull request.

Process

VALIDATE BRANCH → LOAD CHECKLIST → GET DIFF → TWO-PASS ANALYSIS → REPORT

Step 1: Branch Validation

Confirm you're not on main and have changes to review.

git rev-parse --abbrev-ref HEAD   # must not be main/master
git diff origin/main --stat       # must have changes

If on main or no changes: stop and tell user.

Step 2: Load Checklist

Check for repo-local override first, fall back to shared default:

1. Detect repo root: git rev-parse --show-toplevel
2. Check: {repo}/.claude/review-checklist.md — if exists, use it
3. Fallback: .claude/skills/review/checklist.md (this skill's default)

If no checklist found: stop — review requires a checklist to operate.

Step 3: Retrieve Diff

git fetch origin main 2>/dev/null
git diff origin/main

Read the FULL diff before flagging anything. Issues already addressed within the diff are not issues.

Step 4: Two-Pass Analysis

Run the checklist categories against the diff:

• Pass 1 (CRITICAL) — blocking issues. These must be resolved before PR creation.
• Pass 2 (INFORMATIONAL) — non-blocking issues. Included in PR body for reviewer awareness.

For each finding:

• Cite file:line precisely
• One line describing the problem
• One line with the fix
• No preamble, no "looks good overall," no filler

Step 5: Report & Interact

Output format:

Pre-Landing Review: N issues (X critical, Y informational)

CRITICAL (blocking):
- [file:line] Problem description
  Fix: suggested fix

INFORMATIONAL (non-blocking):
- [file:line] Problem description
  Fix: suggested fix

If no issues: Pre-Landing Review: No issues found.

For each CRITICAL finding: present one at a time via AskUserQuestion with three options:

• A) Fix now — apply the suggested fix
• B) Acknowledge — proceed despite the issue (user accepts risk)
• C) False positive — suppress in future reviews

One issue per question. Never batch. Recommend which option and why.

After all critical issues resolved: list informational findings in a single block. Suggest including them in the PR description.

Rules

• Read-only default. No file modifications unless user explicitly approves a fix.
• Exhaustive reporting. Surface all findings — do not quietly skip issues.
• No premature action. Never commit, push, or create PRs.
• Context-aware. Read the FULL diff before commenting. Don't flag issues already fixed within the diff.
• Terse. One-line problems, one-line fixes. No summaries, no preamble.
• Checklist-driven. Only flag categories defined in the loaded checklist.

Integration

After review completes with no unresolved critical issues:

• Suggest running /quality-gate for mechanical checks (types, lint, tests)
• Suggest opening the pull request (gh pr create -R {owner}/{repo} ...), then /land to take that one PR through CI and merge, or /ship to run the full review → land → deploy → smoke → monitor pipeline