Pre Landing Review

Pre-Landing PR Review

You are running the specialized pre-landing workflow. Analyze the current branch's diff against the base branch for structural issues that tests don't catch. Do not present this skill as the product /review command.

OpenBitFun Dispatch

When this skill is invoked by OpenBitFun, this skill supplies the pre-landing review lens. Use existing Task sub-agents for independent diff review tracks, then consolidate findings in the main session.

• Do not assume a Staff Engineer sub-agent exists. Choose only from the Task tool's available agents.
• Use at most one built-in CodeReview sub-agent for an independent pass, and put the exact correctness, performance, security, or architecture question in its prompt. Broader dynamic lens selection belongs to the unified /review path.
• Prefer a matching custom review sub-agent when the user configured one. Use Explore only for broad read-only investigation when no review sub-agent fits.
• Keep Task work read-only. Ask for tight findings with file paths, line references if possible, severity, confidence, and why tests might miss it.
• The main session owns final severity ordering, AUTO-FIX vs ASK classification, and any code changes.

Step 1: Check branch

1. Run git branch --show-current to get the current branch.
2. If on the base branch, output: "Nothing to review — you're on the base branch or have no changes against it." and stop.
3. Run git fetch origin <base> --quiet && git diff origin/<base> --stat to check if there's a diff. If no diff, output the same message and stop.

Step 1.5: Scope Drift Detection

Before reviewing code quality, check: did they build what was requested — nothing more, nothing less?

1. Read TODOS.md (if it exists). Read PR description (gh pr view --json body --jq .body 2>/dev/null || true). Read commit messages (git log origin/<base>..HEAD --oneline). If no PR exists: rely on commit messages and TODOS.md for stated intent — this is the common case since /review runs before /ship creates the PR.

2. Identify the stated intent — what was this branch supposed to accomplish?

3. Run git diff origin/<base>...HEAD --stat and compare the files changed against the stated intent.

4. Evaluate with skepticism (incorporating plan completion results if available from an earlier step or adjacent section):

   SCOPE CREEP detection:

   • Files changed that are unrelated to the stated intent
   • New features or refactors not mentioned in the plan
   • "While I was in there..." changes that expand blast radius

   MISSING REQUIREMENTS detection:

   • Requirements from TODOS.md/PR description not addressed in the diff
   • Test coverage gaps for stated requirements
   • Partial implementations (started but not finished)

5. Output (before the main review begins): ``` Scope Check: [CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING] Intent: <1-line summary of what was requested> Delivered: <1-line summary of what the diff actually does> [If drift: list each out-of-scope change] [If missing: list each unaddressed requirement] ```

6. This is INFORMATIONAL — does not block the review. Proceed to the next step.

Plan File Discovery

1. Conversation context (primary): Check if there is an active plan file in this conversation. The host agent's system messages include plan file paths when in plan mode. If found, use it directly — this is the most reliable signal.

2. Content-based search (fallback): If no plan file is referenced in conversation context, search by content:

setopt +o nomatch 2>/dev/null || true  # zsh compat
BRANCH=$(git branch --show-current 2>/dev/null | tr '/' '-')
REPO=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)")
# Compute project slug for $HOME/.openbitfun/team/projects/ lookup
_PLAN_SLUG=$(git remote get-url origin 2>/dev/null | sed 's|.*[:/]\([^/]*/[^/]*\)\.git$|\1|;s|.*[:/]\([^/]*/[^/]*\)$|\1|' | tr '/' '-' | tr -cd 'a-zA-Z0-9._-') || true
_PLAN_SLUG="${_PLAN_SLUG:-$(basename "$PWD" | tr -cd 'a-zA-Z0-9._-')}"
# Search common plan file locations (project designs first, then personal/local)
for PLAN_DIR in "$HOME/.openbitfun/team/projects/$_PLAN_SLUG" "$HOME/.openbitfun/team/plans" "$HOME/.codex/plans" ".openbitfun/team/plans"; do
  [ -d "$PLAN_DIR" ] || continue
  PLAN=$(ls -t "$PLAN_DIR"/*.md 2>/dev/null | xargs grep -l "$BRANCH" 2>/dev/null | head -1)
  [ -z "$PLAN" ] && PLAN=$(ls -t "$PLAN_DIR"/*.md 2>/dev/null | xargs grep -l "$REPO" 2>/dev/null | head -1)
  [ -z "$PLAN" ] && PLAN=$(find "$PLAN_DIR" -name '*.md' -mmin -1440 -maxdepth 1 2>/dev/null | xargs ls -t 2>/dev/null | head -1)
  [ -n "$PLAN" ] && break
done
[ -n "$PLAN" ] && echo "PLAN_FILE: $PLAN" || echo "NO_PLAN_FILE"

3. Validation: If a plan file was found via content-based search (not conversation context), read the first 20 lines and verify it is relevant to the current branch's work. If it appears to be from a different project or feature, treat as "no plan file found."

Error handling:

• No plan file found → skip with "No plan file detected — skipping."
• Plan file found but unreadable (permissions, encoding) → skip with "Plan file found but unreadable — skipping."

Actionable Item Extraction

Read the plan file. Extract every actionable item — anything that describes work to be done. Look for:

• Checkbox items: - [ ] ... or - [x] ...
• Numbered steps under implementation headings: "1. Create ...", "2. Add ...", "3. Modify ..."
• Imperative statements: "Add X to Y", "Create a Z service", "Modify the W controller"
• File-level specifications: "New file: path/to/file.ts", "Modify path/to/existing.rb"
• Test requirements: "Test that X", "Add test for Y", "Verify Z"
• Data model changes: "Add column X to table Y", "Create migration for Z"

Ignore:

• Context/Background sections (## Context, ## Background, ## Problem)
• Questions and open items (marked with ?, "TBD", "TODO: decide")
• Review report sections (## GSTACK REVIEW REPORT)
• Explicitly deferred items ("Future:", "Out of scope:", "NOT in scope:", "P2:", "P3:", "P4:")
• CEO Review Decisions sections (these record choices, not work items)

Cap: Extract at most 50 items. If the plan has more, note: "Showing top 50 of N plan items — full list in plan file."

No items found: If the plan contains no extractable actionable items, skip with: "Plan file contains no actionable items — skipping completion audit."

For each item, note:

• The item text (verbatim or concise summary)
• Its category: CODE | TEST | MIGRATION | CONFIG | DOCS

Cross-Reference Against Diff

Run git diff origin/<base>...HEAD and git log origin/<base>..HEAD --oneline to understand what was implemented.

For each extracted plan item, check the diff and classify:

• DONE — Clear evidence in the diff that this item was implemented. Cite the specific file(s) changed.
• PARTIAL — Some work toward this item exists in the diff but it's incomplete (e.g., model created but controller missing, function exists but edge cases not handled).
• NOT DONE — No evidence in the diff that this item was addressed.
• CHANGED — The item was implemented using a different approach than the plan described, but the same goal is achieved. Note the difference.

Be conservative with DONE — require clear evidence in the diff. A file being touched is not enough; the specific functionality described must be present. Be generous with CHANGED — if the goal is met by different means, that counts as addressed.

Output Format

PLAN COMPLETION AUDIT
═══════════════════════════════
Plan: {plan file path}

## Implementation Items
  [DONE]      Create UserService — src/services/user_service.rb (+142 lines)
  [PARTIAL]   Add validation — model validates but missing controller checks
  [NOT DONE]  Add caching layer — no cache-related changes in diff
  [CHANGED]   "Redis queue" → implemented with Sidekiq instead

## Test Items
  [DONE]      Unit tests for UserService — test/services/user_service_test.rb
  [NOT DONE]  E2E test for signup flow

## Migration Items
  [DONE]      Create users table — db/migrate/20240315_create_users.rb

─────────────────────────────────
COMPLETION: 4/7 DONE, 1 PARTIAL, 1 NOT DONE, 1 CHANGED
─────────────────────────────────

Fallback Intent Sources (when no plan file found)

When no plan file is detected, use these secondary intent sources:

1. Commit messages: Run git log origin/<base>..HEAD --oneline. Use judgment to extract real intent:
   • Commits with actionable verbs ("add", "implement", "fix", "create", "remove", "update") are intent signals
   • Skip noise: "WIP", "tmp", "squash", "merge", "chore", "typo", "fixup"
   • Extract the intent behind the commit, not the literal message
2. TODOS.md: If it exists, check for items related to this branch or recent dates
3. PR description: Run gh pr view --json body -q .body 2>/dev/null for intent context

With fallback sources: Apply the same Cross-Reference classification (DONE/PARTIAL/NOT DONE/CHANGED) using best-effort matching. Note that fallback-sourced items are lower confidence than plan-file items.

Investigation Depth

For each PARTIAL or NOT DONE item, investigate WHY:

1. Check git log origin/<base>..HEAD --oneline for commits that suggest the work was started, attempted, or reverted
2. Read the relevant code to understand what was built instead
3. Determine the likely reason from this list:
   • Scope cut — evidence of intentional removal (revert commit, removed TODO)
   • Context exhaustion — work started but stopped mid-way (partial implementation, no follow-up commits)
   • Misunderstood requirement — something was built but it doesn't match what the plan described
   • Blocked by dependency — plan item depends on something that isn't available
   • Genuinely forgotten — no evidence of any attempt

Output for each discrepancy:

DISCREPANCY: {PARTIAL|NOT_DONE} | {plan item} | {what was actually delivered}
INVESTIGATION: {likely reason with evidence from git log / code}
IMPACT: {HIGH|MEDIUM|LOW} — {what breaks or degrades if this stays undelivered}

Learnings Logging (plan-file discrepancies only)

Only for discrepancies sourced from plan files (not commit messages or TODOS.md), log a learning so future sessions know this pattern occurred:

true # OpenBitFun has no external telemetry helper
  "type": "pitfall",
  "key": "plan-delivery-gap-KEBAB_SUMMARY",
  "insight": "Planned X but delivered Y because Z",
  "confidence": 8,
  "source": "observed",
  "files": ["PLAN_FILE_PATH"]
}'

Replace KEBAB_SUMMARY with a kebab-case summary of the gap, and fill in the actual values.

Do NOT log learnings from commit-message-derived or TODOS.md-derived discrepancies. These are informational in the review output but too noisy for durable memory.

Integration with Scope Drift Detection

The plan completion results augment the existing Scope Drift Detection. If a plan file is found:

• NOT DONE items become additional evidence for MISSING REQUIREMENTS in the scope drift report.
• Items in the diff that don't match any plan item become evidence for SCOPE CREEP detection.
• HIGH-impact discrepancies trigger AskUserQuestion:
  • Show the investigation findings
  • Options: A) Stop and implement missing items, B) Ship anyway + create P1 TODOs, C) Intentionally dropped

This is INFORMATIONAL unless HIGH-impact discrepancies are found (then it gates via AskUserQuestion).

Update the scope drift output to include plan file context:

Scope Check: [CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING]
Intent: <from plan file — 1-line summary>
Plan: <plan file path>
Delivered: <1-line summary of what the diff actually does>
Plan items: N DONE, M PARTIAL, K NOT DONE
[If NOT DONE: list each missing item with investigation]
[If scope creep: list each out-of-scope change not in the plan]

No plan file found: Use commit messages and TODOS.md as fallback sources (see above). If no intent sources at all, skip with: "No intent sources detected — skipping completion audit."

Step 2: Read the checklist

Read the built-in review checklist.

If the file cannot be read, STOP and report the error. Do not proceed without the checklist.

Step 2.5: Check for Greptile review comments

Read the built-in review-triage checklist and follow the fetch, filter, classify, and escalation detection steps.

If no PR exists, gh fails, API returns an error, or there are zero Greptile comments: Skip this step silently. Greptile integration is additive — the review works without it.

If Greptile comments are found: Store the classifications (VALID & ACTIONABLE, VALID BUT ALREADY FIXED, FALSE POSITIVE, SUPPRESSED) — you will need them in Step 5.

Step 3: Get the diff

Fetch the latest base branch to avoid false positives from stale local state:

git fetch origin <base> --quiet

Run git diff origin/<base> to get the full diff. This includes both committed and uncommitted changes against the latest base branch.

Prior Learnings

Use only OpenBitFun in-session memory, project docs, .openbitfun/team/ artifacts, git history, TODO files, and prior design/review artifacts. Do not run external learning or config helpers, and do not ask the user to enable cross-project learning. If a relevant prior artifact is found, cite it as: Prior OpenBitFun context applied: <source>.

Step 4: Critical pass (core review)

Apply the CRITICAL categories from the checklist against the diff: SQL & Data Safety, Race Conditions & Concurrency, LLM Output Trust Boundary, Shell Injection, Enum & Value Completeness.

Also apply the remaining INFORMATIONAL categories that are still in the checklist (Async/Sync Mixing, Column/Field Name Safety, LLM Prompt Issues, Type Coercion, View/Frontend, Time Window Safety, Completeness Gaps, Distribution & CI/CD).

Enum & Value Completeness requires reading code OUTSIDE the diff. When the diff introduces a new enum value, status, tier, or type constant, use Grep to find all files that reference sibling values, then Read those files to check if the new value is handled. This is the one category where within-diff review is insufficient.

Search-before-recommending: When recommending a fix pattern (especially for concurrency, caching, auth, or framework-specific behavior):

• Verify the pattern is current best practice for the framework version in use
• Check if a built-in solution exists in newer versions before recommending a workaround
• Verify API signatures against current docs (APIs change between versions)

Takes seconds, prevents recommending outdated patterns. If WebSearch is unavailable, note it and proceed with in-distribution knowledge.

Follow the output format specified in the checklist. Respect the suppressions — do NOT flag items listed in the "DO NOT flag" section.

Confidence Calibration

Every finding MUST include a confidence score (1-10):

Finding format:

`[SEVERITY] (confidence: N/10) file:line — description`

Example: `[P1] (confidence: 9/10) app/models/user.rb:42 — SQL injection via string interpolation in where clause` `[P2] (confidence: 5/10) app/controllers/api/v1/users_controller.rb:18 — Possible N+1 query, verify with production logs`

Calibration learning: If you report a finding with confidence < 7 and the user confirms it IS a real issue, that is a calibration event. Your initial confidence was too low. Log the corrected pattern as a learning so future reviews catch it with higher confidence.

Step 4.5: Review Army — Specialist Dispatch

Detect stack and scope

source <(true # OpenBitFun infers diff scope with git/rg <base> 2>/dev/null) || true
# Detect stack for specialist context
STACK=""
[ -f Gemfile ] && STACK="${STACK}ruby "
[ -f package.json ] && STACK="${STACK}node "
[ -f requirements.txt ] || [ -f pyproject.toml ] && STACK="${STACK}python "
[ -f go.mod ] && STACK="${STACK}go "
[ -f Cargo.toml ] && STACK="${STACK}rust "
echo "STACK: ${STACK:-unknown}"
DIFF_INS=$(git diff origin/<base> --stat | tail -1 | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+' || echo "0")
DIFF_DEL=$(git diff origin/<base> --stat | tail -1 | grep -oE '[0-9]+ deletion' | grep -oE '[0-9]+' || echo "0")
DIFF_LINES=$((DIFF_INS + DIFF_DEL))
echo "DIFF_LINES: $DIFF_LINES"
# Detect test framework for specialist test stub generation
TEST_FW=""
{ [ -f jest.config.ts ] || [ -f jest.config.js ]; } && TEST_FW="jest"
[ -f vitest.config.ts ] && TEST_FW="vitest"
{ [ -f spec/spec_helper.rb ] || [ -f .rspec ]; } && TEST_FW="rspec"
{ [ -f pytest.ini ] || [ -f conftest.py ]; } && TEST_FW="pytest"
[ -f go.mod ] && TEST_FW="go-test"
echo "TEST_FW: ${TEST_FW:-unknown}"

Read specialist hit rates (adaptive gating)

true # OpenBitFun has no external specialist-stats helper 2>/dev/null || true

Select specialists

Based on the scope signals above, select which specialists to dispatch.

Always-on (dispatch on every review with 50+ changed lines):

1. Testing — read the built-in testing review checklist
2. Maintainability — read the built-in maintainability review checklist

If DIFF_LINES < 50: Skip all specialists. Print: "Small diff ($DIFF_LINES lines) — specialists skipped." Continue to Step 5.

Conditional (dispatch if the matching scope signal is true): 3. Security — if SCOPE_AUTH=true, OR if SCOPE_BACKEND=true AND DIFF_LINES > 100. Read the built-in security review checklist 4. Performance — if SCOPE_BACKEND=true OR SCOPE_FRONTEND=true. Read the built-in performance review checklist 5. Data Migration — if SCOPE_MIGRATIONS=true. Read the built-in data-migration review checklist 6. API Contract — if SCOPE_API=true. Read the built-in API-contract review checklist 7. Design — if SCOPE_FRONTEND=true. Use the existing design review checklist at the built-in design review checklist

Adaptive gating

After scope-based selection, apply adaptive gating based on specialist hit rates:

For each conditional specialist that passed scope gating, check the built-in specialist summary output above:

• If tagged [GATE_CANDIDATE] (0 findings in 10+ dispatches): skip it. Print: "[specialist] auto-gated (0 findings in N reviews)."
• If tagged [NEVER_GATE]: always dispatch regardless of hit rate. Security and data-migration are insurance policy specialists — they should run even when silent.

Force flags: If the user's prompt includes --security, --performance, --testing, --maintainability, --data-migration, --api-contract, --design, or --all-specialists, force-include that specialist regardless of gating.

Note which specialists were selected, gated, and skipped. Print the selection: "Dispatching N specialists: [names]. Skipped: [names] (scope not detected). Gated: [names] (0 findings in N+ reviews)."

Dispatch specialists in parallel

For each selected specialist, launch an independent subagent via OpenBitFun's Task tool. Launch ALL selected specialists in a single message (multiple Task tool calls) so they run in parallel. Each subagent has fresh context — no prior review bias.

Each specialist subagent prompt:

Construct the prompt for each specialist. The prompt includes:

1. The specialist's checklist content (you already read the file above)
2. Stack context: "This is a {STACK} project."
3. Past learnings for this domain (if any exist):

true # OpenBitFun has no external learnings helper

If learnings are found, include them: "Past learnings for this domain: {learnings}"

4. Instructions:

"You are a specialist code reviewer. Read the checklist below, then run git diff origin/<base> to get the full diff. Apply the checklist against the diff.

For each finding, output a JSON object on its own line: {"severity":"CRITICAL|INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"category","summary":"description","fix":"recommended fix","fingerprint":"path:line:category","specialist":"name"}

Required fields: severity, confidence, path, category, summary, specialist. Optional: line, fix, fingerprint, evidence, test_stub.

If you can write a test that would catch this issue, include it in the test_stub field. Use the detected test framework ({TEST_FW}). Write a minimal skeleton — describe/it/test blocks with clear intent. Skip test_stub for architectural or design-only findings.

If no findings: output NO FINDINGS and nothing else. Do not output anything else — no preamble, no summary, no commentary.

Stack context: {STACK} Past learnings: {learnings or 'none'}

CHECKLIST: {checklist content}"

Subagent configuration:

• Use subagent_type: "general-purpose"
• Do NOT use run_in_background — all specialists must complete before merge
• If any specialist subagent fails or times out, log the failure and continue with results from successful specialists. Specialists are additive — partial results are better than no results.

Step 4.6: Collect and merge findings

After all specialist subagents complete, collect their outputs.

Parse findings: For each specialist's output:

1. If output is "NO FINDINGS" — skip, this specialist found nothing
2. Otherwise, parse each line as a JSON object. Skip lines that are not valid JSON.
3. Collect all parsed findings into a single list, tagged with their specialist name.

Fingerprint and deduplicate: For each finding, compute its fingerprint:

• If fingerprint field is present, use it
• Otherwise: {path}:{line}:{category} (if line is present) or {path}:{category}

Group findings by fingerprint. For findings sharing the same fingerprint:

• Keep the finding with the highest confidence score
• Tag it: "MULTI-SPECIALIST CONFIRMED ({specialist1} + {specialist2})"
• Boost confidence by +1 (cap at 10)
• Note the confirming specialists in the output

Apply confidence gates:

• Confidence 7+: show normally in the findings output
• Confidence 5-6: show with caveat "Medium confidence — verify this is actually an issue"
• Confidence 3-4: move to appendix (suppress from main findings)
• Confidence 1-2: suppress entirely

Compute PR Quality Score: After merging, compute the quality score: quality_score = max(0, 10 - (critical_count * 2 + informational_count * 0.5)) Cap at 10. Log this in the review result at the end.

Output merged findings: Present the merged findings in the same format as the current review:

SPECIALIST REVIEW: N findings (X critical, Y informational) from Z specialists

[For each finding, in order: CRITICAL first, then INFORMATIONAL, sorted by confidence descending]
[SEVERITY] (confidence: N/10, specialist: name) path:line — summary
  Fix: recommended fix
  [If MULTI-SPECIALIST CONFIRMED: show confirmation note]

PR Quality Score: X/10

These findings flow into Step 5 Fix-First alongside the CRITICAL pass findings from Step 4. The Fix-First heuristic applies identically — specialist findings follow the same AUTO-FIX vs ASK classification.

Compile per-specialist stats: After merging findings, compile a specialists object for the review-log entry in Step 5.8. For each specialist (testing, maintainability, security, performance, data-migration, api-contract, design, red-team):

• If dispatched: {"dispatched": true, "findings": N, "critical": N, "informational": N}
• If skipped by scope: {"dispatched": false, "reason": "scope"}
• If skipped by gating: {"dispatched": false, "reason": "gated"}
• If not applicable (e.g., red-team not activated): omit from the object

Include the Design specialist even though it uses design-checklist.md instead of the specialist schema files. Remember these stats — you will need them for the review-log entry in Step 5.8.

Red Team dispatch (conditional)

Activation: Only if DIFF_LINES > 200 OR any specialist produced a CRITICAL finding.

If activated, dispatch one more subagent via the Task tool (foreground, not background).

The Red Team subagent receives:

1. The red-team checklist from the built-in red-team review checklist
2. The merged specialist findings from Step 4.6 (so it knows what was already caught)
3. The git diff command

Prompt: "You are a red team reviewer. The code has already been reviewed by N specialists who found the following issues: {merged findings summary}. Your job is to find what they MISSED. Read the checklist, run git diff origin/<base>, and look for gaps. Output findings as JSON objects (same schema as the specialists). Focus on cross-cutting concerns, integration boundary issues, and failure modes that specialist checklists don't cover."

If the Red Team finds additional issues, merge them into the findings list before Step 5 Fix-First. Red Team findings are tagged with "specialist":"red-team".

If the Red Team returns NO FINDINGS, note: "Red Team review: no additional issues found." If the Red Team subagent fails or times out, skip silently and continue.

Step 5: Fix-First Review

Every finding gets action — not just critical ones.

Step 5.0: Cross-review finding dedup

Before classifying findings, check if any were previously skipped by the user in a prior review on this branch.

true # OpenBitFun reads review context from the current session

Parse the output: only lines BEFORE ---CONFIG--- are JSONL entries (the output also contains ---CONFIG--- and ---HEAD--- footer sections that are not JSONL — ignore those).

For each JSONL entry that has a findings array:

1. Collect all fingerprints where action: "skipped"
2. Note the commit field from that entry

If skipped fingerprints exist, get the list of files changed since that review:

git diff --name-only <prior-review-commit> HEAD

For each current finding (from both Step 4 critical pass and Step 4.5-4.6 specialists), check:

• Does its fingerprint match a previously skipped finding?
• Is the finding's file path NOT in the changed-files set?

If both conditions are true: suppress the finding. It was intentionally skipped and the relevant code hasn't changed.

Print: "Suppressed N findings from prior reviews (previously skipped by user)"

Only suppress skipped findings — never fixed or auto-fixed (those might regress and should be re-checked).

If no prior reviews exist or none have a findings array, skip this step silently.

Output a summary header: Pre-Landing Review: N issues (X critical, Y informational)

Step 5a: Classify each finding

For each finding, classify as AUTO-FIX or ASK per the Fix-First Heuristic in checklist.md. Critical findings lean toward ASK; informational findings lean toward AUTO-FIX.

Test stub override: Any finding that has a test_stub field (generated by a specialist) is reclassified as ASK regardless of its original classification. When presenting the ASK item, show the proposed test file path and the test code. The user approves or skips the test creation. If approved, write the fix + test file. Derive the test file path from the finding's path using project conventions (spec/ for RSpec, __tests__/ for Jest/Vitest, test_ prefix for pytest, _test.go suffix for Go). If the test file already exists, append the new test. Output: [FIXED + TEST] [file:line] Problem -> fix + test at [test_path]

Step 5b: Auto-fix all AUTO-FIX items

Apply each fix directly. For each one, output a one-line summary: [AUTO-FIXED] [file:line] Problem → what you did

Step 5c: Batch-ask about ASK items

If there are ASK items remaining, present them in ONE AskUserQuestion:

• List each item with a number, the severity label, the problem, and a recommended fix
• For each item, provide options: A) Fix as recommended, B) Skip
• Include an overall RECOMMENDATION

Example format:

I auto-fixed 5 issues. 2 need your input:

1. [CRITICAL] app/models/post.rb:42 — Race condition in status transition
   Fix: Add `WHERE status = 'draft'` to the UPDATE
   → A) Fix  B) Skip

2. [INFORMATIONAL] app/services/generator.rb:88 — LLM output not type-checked before DB write
   Fix: Add JSON schema validation
   → A) Fix  B) Skip

RECOMMENDATION: Fix both — #1 is a real race condition, #2 prevents silent data corruption.

If 3 or fewer ASK items, you may use individual AskUserQuestion calls instead of batching.

Step 5d: Apply user-approved fixes

Apply fixes for items where the user chose "Fix." Output what was fixed.

If no ASK items exist (everything was AUTO-FIX), skip the question entirely.

Verification of claims

Before producing the final review output:

• If you claim "this pattern is safe" → cite the specific line proving safety
• If you claim "this is handled elsewhere" → read and cite the handling code
• If you claim "tests cover this" → name the test file and method
• Never say "likely handled" or "probably tested" — verify or flag as unknown

Rationalization prevention: "This looks fine" is not a finding. Either cite evidence it IS fine, or flag it as unverified.

Greptile comment resolution

After outputting your own findings, if Greptile comments were classified in Step 2.5:

Include a Greptile summary in your output header: + N Greptile comments (X valid, Y fixed, Z FP)

Before replying to any comment, run the Escalation Detection algorithm from greptile-triage.md to determine whether to use Tier 1 (friendly) or Tier 2 (firm) reply templates.

1. VALID & ACTIONABLE comments: These are included in your findings — they follow the Fix-First flow (auto-fixed if mechanical, batched into ASK if not) (A: Fix it now, B: Acknowledge, C: False positive). If the user chooses A (fix), reply using the Fix reply template from greptile-triage.md (include inline diff + explanation). If the user chooses C (false positive), reply using the False Positive reply template (include evidence + suggested re-rank), save to both per-project and global greptile-history.

2. FALSE POSITIVE comments: Present each one via AskUserQuestion:

   • Show the Greptile comment: file:line (or [top-level]) + body summary + permalink URL
   • Explain concisely why it's a false positive
   • Options:
     • A) Reply to Greptile explaining why this is incorrect (recommended if clearly wrong)
     • B) Fix it anyway (if low-effort and harmless)
     • C) Ignore — don't reply, don't fix

   If the user chooses A, reply using the False Positive reply template from greptile-triage.md (include evidence + suggested re-rank), save to both per-project and global greptile-history.

3. VALID BUT ALREADY FIXED comments: Reply using the Already Fixed reply template from greptile-triage.md — no AskUserQuestion needed:

   • Include what was done and the fixing commit SHA
   • Save to both per-project and global greptile-history

4. SUPPRESSED comments: Skip silently — these are known false positives from previous triage.

Step 5.5: TODOS cross-reference

Read TODOS.md in the repository root (if it exists). Cross-reference the PR against open TODOs:

• Does this PR close any open TODOs? If yes, note which items in your output: "This PR addresses TODO: "
• Does this PR create work that should become a TODO? If yes, flag it as an informational finding.
• Are there related TODOs that provide context for this review? If yes, reference them when discussing related findings.

If TODOS.md doesn't exist, skip this step silently.

Step 5.6: Documentation staleness check

Cross-reference the diff against documentation files. For each .md file in the repo root (README.md, ARCHITECTURE.md, CONTRIBUTING.md, AGENTS.md, etc.):

1. Check if code changes in the diff affect features, components, or workflows described in that doc file.
2. If the doc file was NOT updated in this branch but the code it describes WAS changed, flag it as an INFORMATIONAL finding: "Documentation may be stale: [file] describes [feature/component] but code changed in this branch. Consider running /document-release."

This is informational only — never critical. The fix action is /document-release.

If no documentation files exist, skip this step silently.

Step 5.7: Adversarial review (always-on)

Every diff gets adversarial review from both OpenBitFun and outside-voice sub-agent. LOC is not a proxy for risk — a 5-line auth change can be critical.

Detect diff size and tool availability:

DIFF_INS=$(git diff origin/<base> --stat | tail -1 | grep -oE '[0-9]+ insertion' | grep -oE '[0-9]+' || echo "0")
DIFF_DEL=$(git diff origin/<base> --stat | tail -1 | grep -oE '[0-9]+ deletion' | grep -oE '[0-9]+' || echo "0")
DIFF_TOTAL=$((DIFF_INS + DIFF_DEL))
which codex 2>/dev/null && echo "CODEX_AVAILABLE" || echo "CODEX_NOT_AVAILABLE"
# Legacy opt-out — only gates outside-voice sub-agent passes, OpenBitFun always runs
OLD_CFG="" # OpenBitFun has no external codex_reviews config
echo "DIFF_SIZE: $DIFF_TOTAL"
echo "OLD_CFG: ${OLD_CFG:-not_set}"

If OLD_CFG is disabled: skip outside-voice sub-agent passes only. OpenBitFun adversarial subagent still runs (it's free and fast). Jump to the "OpenBitFun adversarial subagent" section.

User override: If the user explicitly requested "full review", "structured review", or "P1 gate", also run the outside-voice sub-agent structured review regardless of diff size.

OpenBitFun adversarial subagent (always runs)

Dispatch via the Task tool. The subagent has fresh context — no checklist bias from the structured review. This genuine independence catches things the primary reviewer is blind to.

Subagent prompt: "Read the diff for this branch with git diff origin/<base>. Think like an attacker and a chaos engineer. Your job is to find ways this code will fail in production. Look for: edge cases, race conditions, security holes, resource leaks, failure modes, silent data corruption, logic errors that produce wrong results silently, error handling that swallows failures, and trust boundary violations. Be adversarial. Be thorough. No compliments — just the problems. For each finding, classify as FIXABLE (you know how to fix it) or INVESTIGATE (needs human judgment)."

Present findings under an ADVERSARIAL REVIEW (independent subagent): header. FIXABLE findings flow into the same Fix-First pipeline as the structured review. INVESTIGATE findings are presented as informational.

If the subagent fails or times out: "OpenBitFun adversarial subagent unavailable. Continuing."

outside-voice sub-agent adversarial challenge (always runs when available)

If a suitable OpenBitFun outside-voice or review sub-agent is available AND OLD_CFG is NOT disabled:

TMPERR_ADV=$(mktemp /tmp/codex-adv-XXXXXXXX)
_REPO_ROOT=$(git rev-parse --show-toplevel) || { echo "ERROR: not in a git repo" >&2; exit 1; }
Use the OpenBitFun Task tool to dispatch this prompt to a suitable independent read-only outside-voice sub-agent.

Set ExecCommand's yield_time_ms parameter to 300000 (5 minutes). Do NOT use the timeout shell command — it doesn't exist on macOS. After the command completes, read stderr:

cat "$TMPERR_ADV"

Present the full output verbatim. This is informational — it never blocks shipping.

Error handling: All errors are non-blocking — adversarial review is a quality enhancement, not a prerequisite.

• Outside-voice unavailable: If the selected OpenBitFun sub-agent cannot run, skip this informational pass and continue with the main-session review.
• Timeout: "outside-voice sub-agent timed out after 5 minutes."
• Empty response: "outside-voice sub-agent returned no response. Stderr: ."

Cleanup: Run rm -f "$TMPERR_ADV" after processing.

If outside-voice sub-agent is not available in the current OpenBitFun runtime, run the OpenBitFun adversarial path only and note that cross-model coverage was skipped.

outside-voice sub-agent structured review (large diffs only, 200+ lines)

If DIFF_TOTAL >= 200 AND outside-voice sub-agent is available AND OLD_CFG is NOT disabled:

TMPERR=$(mktemp /tmp/outside-voice-review-XXXXXXXX)
_REPO_ROOT=$(git rev-parse --show-toplevel) || { echo "ERROR: not in a git repo" >&2; exit 1; }
cd "$_REPO_ROOT"
Use the OpenBitFun Task tool to dispatch a suitable independent read-only structured review sub-agent over the diff.

Set ExecCommand's yield_time_ms parameter to 300000 (5 minutes). Do NOT use the timeout shell command — it doesn't exist on macOS. Present output under CODEX SAYS (code review): header. Check for [P1] markers: found → GATE: FAIL, not found → GATE: PASS.

If GATE is FAIL, use AskUserQuestion:

outside-voice sub-agent found N critical issues in the diff.

A) Investigate and fix now (recommended)
B) Continue — review will still complete

If A: address the findings. Re-run OpenBitFun Task outside-voice review to verify.

Read stderr for errors (same error handling as outside-voice sub-agent adversarial above).

After stderr: rm -f "$TMPERR"

If DIFF_TOTAL < 200: skip this section silently. The OpenBitFun + outside-voice sub-agent adversarial passes provide sufficient coverage for smaller diffs.

Persist the review result

After all passes complete, persist:

true # OpenBitFun has no external review-log helper

Substitute: STATUS = "clean" if no findings across ALL passes, "issues_found" if any pass found issues. SOURCE = "both" if outside-voice sub-agent ran, "task" if only independent subagent ran. GATE = the outside-voice sub-agent structured review gate result ("pass"/"fail"), "skipped" if diff < 200, or "informational" if outside-voice sub-agent was unavailable. If all passes failed, do NOT persist.

Cross-model synthesis

After all passes complete, synthesize findings across all sources:

ADVERSARIAL REVIEW SYNTHESIS (always-on, N lines):
════════════════════════════════════════════════════════════
  High confidence (found by multiple sources): [findings agreed on by >1 pass]
  Unique to OpenBitFun structured review: [from earlier step]
  Unique to OpenBitFun adversarial: [from subagent]
  Unique to outside-voice sub-agent: [from codex adversarial or code review, if ran]
  Models used: OpenBitFun structured ✓  OpenBitFun adversarial ✓/✗  outside-voice sub-agent ✓/✗
════════════════════════════════════════════════════════════

High-confidence findings (agreed on by multiple sources) should be prioritized for fixes.

Step 5.8: Persist Eng Review result

After all review passes complete, persist the final /review outcome so /ship can recognize that Eng Review was run on this branch.

Run:

true # OpenBitFun has no external review-log helper

Substitute:

• TIMESTAMP = ISO 8601 datetime
• STATUS = "clean" if there are no remaining unresolved findings after Fix-First handling and adversarial review, otherwise "issues_found"
• issues_found = total remaining unresolved findings
• critical = remaining unresolved critical findings
• informational = remaining unresolved informational findings
• quality_score = the PR Quality Score computed in Step 4.6 (e.g., 7.5). If specialists were skipped (small

…(truncated)