/pre-landing-review

name: pre-landing-review
description: 'Gate-oriented safety audit for code changes before landing, using a checklist with two-pass severity triage. Triggers on: "is this safe to land", "pre-landing review", "safety check before merge", "gate check", "/pre-landing-review". NOT for diff review, use pr-review.'
metadata:
  version: 1.0.1
  category: review
  tags: [pre-merge, safety-gate, code-review, checklist]
  difficulty: intermediate
  phase: review

Pre-Landing Review

Gate-oriented safety audit for code changes before landing. Uses a structured checklist with two-pass severity triage and blocking/non-blocking classification.

**Distinct from `pr-review`**: pr-review is a multi-dimension code quality review. This skill is a **gate-oriented safety audit** — it uses an external checklist with two-pass severity triage and a blocking/non-blocking classification.

> **Native alternative:** Claude Code's `/ultrareview` runs a dedicated native review session optimized for bug-finding (Anthropic ships three free per month on Pro/Max plans at Opus 4.7's launch). Use this skill for checklist-driven, gate-oriented blocking classification with a documented triage protocol; use `/ultrareview` for lightweight bug-hunting on a single change.

Workflow

1. Determine Diff

Identify the changes to review:

• If on a feature branch: diff against the default branch (`git symbolic-ref refs/remotes/origin/HEAD`)
• If given a PR number: fetch that PR's diff
• If given specific files: review those files

2. Load Checklist

Read `references/checklist.md`. This is mandatory — if the checklist is unreadable, STOP and report the error.

3. Pass 1 — CRITICAL (blocking)

Review the diff against critical safety categories. These are potential ship-blockers.

SQL & Data Safety

• Raw SQL without parameterization
• Schema changes without migration safety (lock timeout, reversibility)
• Bulk updates/deletes without WHERE clause verification
• Direct column updates bypassing model validations/callbacks

Race Conditions & Concurrency

• Read-then-write without locking
• Unique constraint reliance without database-level enforcement
• Shared mutable state without synchronization
• Queue/background job idempotency

Trust Boundaries

• LLM/AI output used in SQL, shell commands, or rendered HTML without sanitization
• User input reaching privileged operations without validation
• External API responses used without schema validation
• Deserialization of untrusted data

For each CRITICAL finding:

1. Cite exact file and line 2. Explain the specific risk 3. Use `AskUserQuestion` with exactly three options: **Fix now** / **Acknowledge risk** / **False positive** 4. If "Fix now": make the fix, then re-check 5. If "Acknowledge": record acknowledgment, continue 6. If "False positive": record, continue

4. Pass 2 — INFORMATIONAL (non-blocking)

Review against remaining categories:

**Conditional Side Effects** — side effects hidden in conditional branches, callbacks triggered by state changes, error handlers silently swallowing failures.

**Magic Numbers** — unexplained numeric literals, hardcoded thresholds without constants, timeout values without rationale.

**Dead Code** — unreachable branches, unused imports, commented-out code without explanation.

**Test Gaps** — new code paths without test coverage, modified behavior without updated tests, missing edge case and error path tests.

**Crypto & Entropy** — weak random sources for security contexts, hardcoded secrets, missing TLS/encryption for sensitive data in transit.

**Time Window Safety** — timezone-naive comparisons, daylight saving edge cases, cron expressions not accounting for clock skew.

**Type Coercion** — implicit type conversions that could lose data, numeric precision loss across boundaries, implicit string encoding at I/O boundaries.

Present all informational findings in a single summary table (file, line, category, description).

5. Gate Classification

• All Pass 1 issues resolved (fixed or acknowledged) → **CLEAR TO LAND**
• Any unresolved Pass 1 issue → **BLOCKED**
• Pass 2 issues are advisory — they don't block landing

6. Suppressions

Do NOT flag:

• Test files using test fixtures/factories
• Migration files following framework conventions
• Comments explaining why a pattern is intentional
• Configuration files with documented values
• Type stubs or interface definitions

Output

Gate verdict (CLEAR TO LAND / BLOCKED), critical issues summary with resolution status, informational findings table.

**This skill is read-only by default** — only modifies code when user explicitly chooses "Fix now" on a critical issue.