PR Review Skill

[!CAUTION] READ-ONLY WORKSPACE, BLIND-FIRST ISOLATION, ZERO-APPROVAL COMMANDS & USER APPROVAL ENFORCEMENT

• Do NOT modify repository code in the primary workspace.
• Perform all checkout and diff operations in an ephemeral temporary directory (/tmp/pr-review-XXXXXX).
• Zero-Approval Command Execution: Do not run mkdir -p or rm in shell commands (review_engine.py, diff_parser.py, launch_dashboard.py, and write_to_file create <conversation-scratch-dir> and parent directories automatically), and pass <conversation-scratch-dir>/workspace_dir.txt directly to --repo-dir and --cleanup instead of using "$(cat ...)" command substitution. The one exception is code-review's Step 6 cleanup loop in Step 3.3, which removes only the directories code-review itself created.
• Scratch directory: <conversation-scratch-dir> is a pr-review/ subdirectory inside the session's scratch directory. Every intermediate file this skill names (pr_coords.json, pr.diff, workspace_dir.txt, blind_description.md, code_review_prep.json, review_results.json, review_findings.json, and so on) lives there.
• Stage 1 Blindness: Before <conversation-scratch-dir>/blind_description.md is written solely from the code diff, do NOT inspect the PR title, body, commit messages, branch names (headRefName), comments, reviews, or threads. Only gh pr view --json number,url (Step 1) and review_engine.py --prepare-workspace (Step 2) are permitted in Stage 1. The stack object in pr_coords.json (PR numbers, states, and rebase flags only) may be read in Stage 1; pr_stack.json (which carries branch names) and gh stack view output may not.
• Launch the review dashboard and wait for the user to submit or abort before posting any reviews or comments to GitHub.
• Never promise future work or unverified assumptions in review comments.

This skill automates reviewing external GitHub Pull Requests (reviewing someone else's code). It derives an unbiased summary of the code changes from the diff alone before reconciling that summary against the author's stated purpose and review comments, then opens a local web dashboard so the human reviewer can inspect, edit, and approve every comment before posting to GitHub.

Flags

pr-review accepts the same composable analysis flags as code-review, passing them through to Step 3:

Legacy --mode <depth> syntax maps to these flags for backward compatibility:

• --mode fast or --mode standard maps to --fast.
• --mode deep maps to passing no flags (delegating to code-review Ring evaluation).
• --mode max maps to --max.

Workflow

Follow these steps in order when reviewing a pull request:

Step 1: Ingestion & Analysis Depth Handling

1. Identify the PR:
   • Determine the target PR from the user prompt (URL, PR number, or head branch).
   • If no PR is specified, run gh pr view --json number,url (do NOT request title, body, headRefName, comments, or reviews) in the active workspace.
2. Analysis Depth Handling:
   • If the user specified explicit analysis flags (such as --fast, --max, --panel, --verify, --claude) or legacy --mode, record them to pass through to code-review. Explicit flags skip ring evaluation and enforce that depth directly.
   • If no depth flag was specified, do not prompt the user. pr-review delegates analysis depth determination directly to code-review, which evaluates the PR's blast-radius ring (Ring 0 to 4) during its Step 1b and scales the review level automatically.

Step 2: Ephemeral Workspace & Blind Diff Description (Stage 1)

1. Prepare Isolated Workspace, Detect Stack Membership, Extract Diff & Run Static Security Pre-Scan (No Narrative Metadata): Run review_engine.py --prepare-workspace (do not run mkdir -p beforehand; the script creates <conversation-scratch-dir> automatically) to resolve non-narrative git coordinates, clone the PR into /tmp/pr-review-XXXXXX, extract the unified diff without fetching the PR title, body, branch name, or comments, and scan the diff for local execution risks:

   python3 scripts/review_engine.py \
     --pr <pr-number-or-url> \
     --prepare-workspace \
     --reference <path-to-local-repo-if-available> \
     --output-coords <conversation-scratch-dir>/pr_coords.json \
     --output-diff <conversation-scratch-dir>/pr.diff \
     --output-workspace <conversation-scratch-dir>/workspace_dir.txt \
     --output-stack <conversation-scratch-dir>/pr_stack.json

   review_engine.py hardens every git and gh subprocess (core.hooksPath=/dev/null, core.fsmonitor=false, diff.external=, --no-ext-diff, --no-textconv) so cloning and diffing an untrusted PR cannot execute repository hooks or diff drivers, and writes a deterministic security_prescan summary into pr_coords.json. Do not run any build step, toolchain dry-run, repo script, dependency install, or test inside workspace_dir.txt during Stage 1. The script also asks GitHub whether the PR belongs to a stack (pullRequest.stack via GraphQL). If it does, it runs gh stack checkout <pr> and gh stack view --json in the temporary checkout (restoring the detached HEAD afterwards), writes the member list with rebase status to pr_stack.json, and records a numbers-only summary in pr_coords.json under stack (number, size, position with 1 = bottom of the stack, needs_rebase, and per-entry number/state/is_draft/needs_rebase). Without the gh stack extension, rebase status comes from git ancestry in the checkout instead. stack is null for an unstacked PR, and pr_stack.json is not written.
2. Draft the Blind Diff Description & Pre-Execution Security Gate:
   • Read only <conversation-scratch-dir>/pr.diff and pr_coords.json (including security_prescan). Open a file in the temporary checkout (workspace_dir.txt) only when security_prescan.signals names it; do not search or read other repository files in Stage 1, because the code-review workers read surrounding code in Step 3.
   • Do not read the PR title, description, commit messages, branch names, or GitHub comments during this step. Do not read pr_stack.json or run gh stack view yet.
   • Audit every file and line flagged in pr_coords.json.security_prescan.signals, plus any modified build manifests, git/shell hooks, linter plugin configs, or test files, and determine the Pre-Execution Security Gate verdict per verification.md: SAFE_FOR_LOCAL_EXECUTION, REQUIRES_USER_CONFIRMATION, or BLOCKED_UNSAFE.
   • Write <conversation-scratch-dir>/blind_description.md following the budgeted Blind-First PR Description Template in review_guidelines.md (## Summary, ## Quality Assessment, ## Security & Execution Gate, ## Changes, and ## Reviewer Focus & Risks).
   • Check the description section budgets before leaving Stage 1:

     python3 scripts/review_engine.py \
       --check-description-budgets <conversation-scratch-dir>/blind_description.md \
       --input-coords <conversation-scratch-dir>/pr_coords.json

     The command always exits 0 and prints Budget: <section>: <n> <unit> (max <m>) for any section over budget. If any Budget: lines appear, trim <conversation-scratch-dir>/blind_description.md now, before Step 3 hashes the file.
   • Re-Reviews (review_round > 1 in pr_coords.json): When re-running --prepare-workspace in the same conversation, review_engine.py automatically moves the previous round's blind_description.md to prev_blind_description.md (and rejects verbatim copies in --fetch-context). Read the updated <conversation-scratch-dir>/pr.diff in full and draft a fresh blind_description.md describing the PR's current state and current architectural or correctness risks. Do not populate ## Reviewer Focus & Risks with "verify prior review findings": Stage 1 must evaluate the full current diff on its own merits.
   • If pr_coords.json has a non-null stack, the diff is only this PR's slice (base_ref is the predecessor branch). Review the slice on its own terms: do not report code that the diff builds on but does not touch as missing, and add a bullet under ## Reviewer Focus & Risks for anything that only makes sense once the rest of the stack is known.

Step 3: PR Context Reconciliation & Code Review Analysis (Stage 2)

1. Fetch PR Narrative Context and Code-Review Prep: Once <conversation-scratch-dir>/blind_description.md is written and non-empty, run review_engine.py --fetch-context --prepare-code-review. The script verifies that blind_description.md exists before querying GitHub for the PR title, body, reviews, and review threads, prints any Budget: overrun lines to stderr as information only, records the file's SHA-256 as blind_sha256, and writes the code-review pre-flight work (reuse ring and substantive line count from classify_artifacts.py --combined, staged diff chunks, entity churn and signature drift when duckdb is installed, and packrat history) to <conversation-scratch-dir>/code_review_prep.json (written next to --output-context by default or at --output-prep, while keeping pr_context.json["code_review_prep"] for backward compatibility):

   python3 scripts/review_engine.py \
     --fetch-context --prepare-code-review \
     --input-coords <conversation-scratch-dir>/pr_coords.json \
     --input-stack <conversation-scratch-dir>/pr_stack.json \
     --require-blind-description <conversation-scratch-dir>/blind_description.md \
     --output-meta <conversation-scratch-dir>/pr_meta.json \
     --output-context <conversation-scratch-dir>/pr_context.json \
     --output-prep <conversation-scratch-dir>/code_review_prep.json

   --input-stack is ignored when the file does not exist. For a stacked PR, pr_context.json gains a stack object (members bottom-first with number, title, state, is_draft, head_ref, base_ref, needs_rebase, and is_target) and pr_meta.json gains stack: {number, size, position}. Optional prep steps that fail are listed in code_review_prep.warnings and do not stop the review. Any Budget: lines printed by --fetch-context are information only; do not edit blind_description.md after --fetch-context runs, because blind_sha256 is already recorded.
   • Unanchored Isolation Before Step 3.3: Do NOT read pr_context.json, prev_review_results.json, prev_review_decisions.json, or pr_incremental.diff in Step 3.1 or Step 3.2. Read only code_review_prep.json, pr_coords.json, and blind_description.md until Step 3.2's unanchored code-review pass finishes.
2. Delegate Code Review Analysis to code-review: Execute the code-review skill workflow against the temporary checkout directory (<conversation-scratch-dir>/workspace_dir.txt) on the PR commit range origin/<base_ref>...<head_sha> (base_ref and head_sha from pr_coords.json), reading only <conversation-scratch-dir>/code_review_prep.json, pr_coords.json, and blind_description.md and forwarding any explicit flags passed by the user (--fast, --panel, --verify, --claude, --challenge, --max, --focus, --no-focus):
   • Delegated Depth Determination: If no depth flag was passed by the user, pass no depth flags to code-review. Hand code-review the standalone <conversation-scratch-dir>/code_review_prep.json file (instead of reading pr_context.json["code_review_prep"]) so its Step 1b skips restaging, sets diff_dir to code_review_prep.diff_dir (when non-null), and reuses the ring classification (including the substantive-line volume gates in lanes.md), churn, drift, and packrat results instead of recomputing them.
   • Re-Review Invariants (review_round > 1 or user asks to "re-review"):
     • Full Diff Required: Always run code-review on the full PR commit range origin/<base_ref>...<head_sha> (pr.diff), never on <prev_head_sha>..<head_sha> (pr_incremental.diff) alone. Never bypass code-review or skip reviewer subagents in favor of an in-session delta check unless --fast was explicitly requested or Ring 0 applies.
     • Fresh Unanchored Reviewer Worker: Spawn a new swarm reviewer (rev-a-2, rev-b-2, rev-f-2 via swarm{action: "add"}) rather than waking Round 1's rev-a worker (whose conversation history is anchored on Round 1's findings). Do not pass prior review findings, prev_review_results.json, or Ruled out last pass into the fresh reviewer's brief.
     • In-Session & Single-Worker Unanchored Pass: When code-review runs in-session (--fast, Tier 3 single-agent CLI, or inside a multi-PR swarm worker whose brief forbids spawning child helpers), it must complete code-review Steps 1 through 4 (reading every diff_chunk_*.diff file in code_review_prep.diff_dir and opening modified source files in workspace_dir.txt) before the agent reads pr_context.json, prev_review_results.json, prev_review_decisions.json, or pr_incremental.diff in Step 3.3. Reading Stage 1's zero-context (-U0) pr.diff never substitutes for reading the staged diff chunks and checkout files in Step 3.2.
   • Preserve Blindness Invariant: Do not pass the PR number or URL directly to code-review. Run code-review strictly on the local checkout commit range origin/<base_ref>...<head_sha> in the temporary checkout directory.
   • Checkout Ownership: The workspace_dir.txt checkout belongs to pr-review. It is not code-review's $pr_review_dir_a, even though both live under /tmp/pr-review-*. code-review reads it in place and never removes it; Step 3.4 reads it and Step 5.2 removes it. Any --verify checkout that code-review creates in its Step 2c ($pr_review_dir_a for lane A, $pr_review_dir_b for lane B per verification.md) is code-review's own and is removed in its Step 6 (at the end of Step 3.3).
   • Seed Hypotheses: Pass the risks and security signals identified in Stage 1's blind_description.md (## Security & Execution Gate and ## Reviewer Focus & Risks) into code-review as seed hypotheses.
   • Focus Candidates: Also pass the Stage 1 ## Reviewer Focus & Risks bullets as focus theme candidates for code-review Step 2d (focus triage), along with any --focus or --no-focus flag the user gave. Triage still makes its own call from the diff. Do not pass the PR title or body: the blindness invariant holds for triage too.
   • Execution Modes, Pre-Execution Security Gate & Trust Gate:
     • Pass the Stage 1 ## Security & Execution Gate verdict (SAFE_FOR_LOCAL_EXECUTION, REQUIRES_USER_CONFIRMATION, or BLOCKED_UNSAFE) and pr_coords.json.security_prescan into code-review Step 2a:
       • Tier 1a checks (remote GitHub CI status/logs, isolated python3 -I -c "import ast...", and static analyzers/linters such as ruff, dart format, dart analyze, tsc --noEmit, and eslint whose executable config/plugin files are untouched by the PR) are always allowed.
       • Tier 1b checks (swift build, make -n, bazel query, gradle tasks, repo-hosted validator scripts, and any analyzer/linter whose config or plugin file was modified in the PR) and Tier 2 checks (throwaway --verify checkouts, dependency installs, tests, and mutations) require SAFE_FOR_LOCAL_EXECUTION.
       • If the gate verdict is REQUIRES_USER_CONFIRMATION, prompt the user via confirm_gate (genui) or ask_question before running any Tier 1b or Tier 2 command. If the user declines or the gate is BLOCKED_UNSAFE, restrict code-review to Tier 1a regardless of author_association.
     • Under --fast (or Tier 3 single-agent CLI / inside a multi-PR swarm worker whose brief forbids spawning child helpers): code-review performs a single-pass in-session review on the staged diff chunks (code_review_prep.diff_dir) and checkout files (workspace_dir.txt) through Step 4 without spawning subagents, and without reading pr_context.json, prev_review_results.json, prev_review_decisions.json, or pr_incremental.diff first. Reading Stage 1's -U0 pr.diff never substitutes for reading the staged diff chunks and checkout files.
     • Under default (or --claude, --panel, --verify, --challenge, --max): code-review manages subagent reviewer lanes, verification tiers, citation audits, and challenge rounds as configured. Under --verify, look up collaborator trust with gh api repos/<owner>/<repo>/pulls/<pull_number> --jq .author_association, filling in owner, repo, and pull_number from pr_coords.json (do not use gh's {owner}/{repo} placeholders, which resolve from the current directory, not from the PR under review). See verification.md. State both the collaborator trust result and the Stage 1 Security Gate verdict in the code-review prompt: Tier 2 requires both a trusted collaborator (OWNER, MEMBER, or COLLABORATOR) and a cleared Security Gate (SAFE_FOR_LOCAL_EXECUTION or user-approved REQUIRES_USER_CONFIRMATION).
   • Orchestration Continuity: In Step 3.2, run code-review Steps 1 through 4 (or collect the unanchored reviewer reports and challenge rounds from Tier 1/Tier 2 workers), then proceed to Step 3.3 for intent reconciliation, prior-thread audit, 3-way synthesis (code-review Step 5) into <conversation-scratch-dir>/review_results.md, and code-review Step 6 cleanup. Skip code-review's own Step 5 lint_review.py run, --json export, and Step 7 hand-off question, because Step 3.4 runs the linter and exporter.
   • Suggestion Syntax: Formulate code suggestions following suggestion_syntax.md so they serialize into GitHub suggestion blocks. The exporter posts each finding's Suggestion as a committable ```suggestion block (except ```diff/```patch fences) and a Repro test as a plain code block; lint_review.py rejects a Suggestion with more than one fenced block.
3. Reconcile Stated Intent, Audit Prior Review Threads & Synthesize 3-Way Merge:
   • Now that the unanchored code-review pass from Step 3.2 has produced its initial findings (either in-session after Step 4 self-critique or from the fresh reviewer subagent/worker reports), read pr_context.json (title, body, comments, reviews, threads, stack), prev_review_results.json, prev_review_decisions.json, and pr_incremental.diff (when present). Compare blind_description.md against the author's title, body, comments, reviews, and threads in pr_context.json (if threads_complete is false, or if pr_meta.json contains latest_head_sha differing from head_sha, note this in a NOTE callout).
   • Do not copy or rewrite blind_description.md. Write only <conversation-scratch-dir>/intent_reconciliation.json (schema in review_guidelines.md): alignment (MATCHES, PARTIAL, DIVERGES, or UNSTATED), callouts[] (section, kind of NOTE/IMPORTANT/WARNING, text), and optional stack_markdown and prior_resolution_markdown. Then splice it:

     python3 scripts/review_engine.py --reconcile-description \
       --blind-description <conversation-scratch-dir>/blind_description.md \
       --reconciliation <conversation-scratch-dir>/intent_reconciliation.json \
       --context <conversation-scratch-dir>/pr_context.json \
       --output-description <conversation-scratch-dir>/pr_description.md

     It exits 1 if blind_description.md changed after --fetch-context or the JSON is invalid; fix the JSON (never the blind file) and rerun.
   • If pr_context.json has a non-null stack, put a ## Stack Context table in stack_markdown following the template in review_guidelines.md; the splice places it right after ## Intent Alignment. You may run gh stack view --short in the checkout (workspace_dir.txt) for the same information in gh's own format. Treat the stack as review context, not as a finding: a predecessor that needs_rebase or is still a draft is a NOTE callout, a claim in the body that a later PR in the stack covers something is checked against that PR's diff (gh pr diff <n>) before it is accepted, and anything the diff builds on from a predecessor is reviewed in that predecessor's PR, not here.
   • Prior Review Resolution (review_round > 1 or non-empty pr_context.json.threads): When re-reviewing after author updates (or when prior review threads exist in pr_context.json.threads or prev_review_results.json), audit each prior comment against pr_incremental.diff (when present) and the current checkout (HEAD), and put the ## Prior Review Resolution table from review_guidelines.md in prior_resolution_markdown. Classify each item as Addressed, Partially Addressed, or Unaddressed.
   • Prior-Thread Synthesis & 3-Way Merge (code-review Step 5): Complete code-review Step 5 (Synthesis), reconciling the unanchored Step 3.2 findings with the ## Prior Review Resolution audit so unaddressed issues are neither duplicated nor dropped before writing <conversation-scratch-dir>/review_results.md:
     1. Both Fresh Review and Prior Audit flag the same defect (same file, overlapping or shifted line range, same underlying issue): Merge into one finding in review_results.md at the higher severity, keeping the fresh review's HEAD line anchor and Evidence tier. Prefix the finding heading with [Unaddressed] or [Partially Addressed] (or [Unaddressed (open thread)] when the prior GitHub thread is still open and untouched), and write Body and Suggestion to reflect what changed (if anything) and what remains broken at HEAD.
     2. Only Prior Audit flags it (missed by the fresh reviewer): Verify the defect still exists at HEAD with Read evidence and carry it forward into review_results.md as a single finding ([Unaddressed] or [Partially Addressed]) so inter-pass reviewer variance never drops an unfixed bug or produces a false APPROVE.
     3. Cleanly Addressed Prior Comments: Record in pr_description.md's ## Prior Review Resolution table and in review_results.md's ## Checked and Found Clean, never as findings.
   • Write review_results.md and Run code-review Step 6 Cleanup: Write the synthesized report to <conversation-scratch-dir>/review_results.md (skipping code-review's own lint_review.py run and --json export because Step 3.4 runs both), then run code-review's Step 6 cleanup loop as written. It is the one exception to the Zero-Approval rule above, and it removes only the directories code-review created ($diff_dir, including code_review_prep.diff_dir, and any --verify checkouts), never the workspace_dir.txt checkout. After Step 6 completes, continue to Step 3.4 in the same turn, including when a swarm worker or reviewer subagent wakes you. Do not emit code-review Step 7's hand-off question.
4. Finalize: Lint, Export, and Tag Hunk Boundaries:
   • Run one post-flight command. It lints review_results.md, exports review_results.json, merges pr_meta.json, and tags each finding's diff hunk:

     python3 scripts/review_engine.py --finalize-review \
       --report-md <conversation-scratch-dir>/review_results.md \
       --diff <conversation-scratch-dir>/pr.diff \
       --meta-file <conversation-scratch-dir>/pr_meta.json \
       --repo-dir <conversation-scratch-dir>/workspace_dir.txt \
       --output-results <conversation-scratch-dir>/review_results.json \
       --output-findings <conversation-scratch-dir>/review_findings.json

   • On exit 1, each lint violation is printed with a Fix: line. Apply the fixes to review_results.md and rerun; do not read lint_review.py's source.
   • Each finding gets is_diff_hunk: true (comments on lines modified within diff hunks) or is_diff_hunk: false (outside-diff or broader context observations), while preserving enriched metadata:
     • Evidence tiers (evidence_tier, evidence_detail), consequences (why), and resolution criteria (to_settle).
     • Clarification questions (merged into findings[] with severity: "question").
     • Hypotheses checked clean (checked_clean[]) and structural assessment (structural_assessment).
   • For manual or legacy findings in <conversation-scratch-dir>/raw_findings.json, run python3 scripts/diff_parser.py --diff <conversation-scratch-dir>/pr.diff --findings <conversation-scratch-dir>/raw_findings.json --repo-dir <conversation-scratch-dir>/workspace_dir.txt --output <conversation-scratch-dir>/review_findings.json instead.

Step 4: Launch Dashboard & Emit Terse Summary in Chat

1. Open the Dashboard:
   • Pane Mode (Preferred when review-dashboards MCP tools are available): Call open_pr_review_dashboard (native tool or via call_mcp_tool on the review-dashboards server) with:
     • findings_file: <conversation-scratch-dir>/review_findings.json
     • meta_file: <conversation-scratch-dir>/pr_meta.json
     • description_file: <conversation-scratch-dir>/pr_description.md
     • output_file: <conversation-scratch-dir>/review_decisions.json If the returned warnings array lists missing pr_metadata fields, fix pr_meta.json or the findings file and call open_pr_review_dashboard again. If hosted is false, fall back to Browser Mode below.
   • Browser Mode (Fallback when MCP tools are unavailable or hosted: false): Launch launch_dashboard.py with --description-file:

     python3 scripts/launch_dashboard.py \
       --findings-file <conversation-scratch-dir>/review_findings.json \
       --meta-file <conversation-scratch-dir>/pr_meta.json \
       --description-file <conversation-scratch-dir>/pr_description.md \
       --output-file <conversation-scratch-dir>/review_decisions.json

     Set WaitMsBeforeAsync to 1000 so the server runs in the background. If the output shows Warning: pr_metadata.<field> is missing, stop the task, fix pr_meta.json or the findings file, and relaunch. The dashboard disables Submit until owner, repo, pull_number, and head_sha are present.
   • The annotated PR description appears in a formatted Markdown card at the top of the dashboard for reviewer context only (apply_review.py never posts it; its text is included only if the user clicks + Insert into Review Summary).
   • Both the Review Summary field and every per-finding comment field provide GitHub-style Write and Preview tabs (defaulting to Write) so the reviewer can switch between editing raw Markdown and previewing rendered Markdown (including GFM pipe tables, LaTeX math, Mermaid diagrams, and ```suggestion blocks).
   • Every finding starts checked (approved). The user unchecks any to omit, or uses Clear all / Approve all shown.
2. Emit a Terse Summary in Chat & Wait for Completion: Write a brief summary (about a paragraph) in chat stating what the PR changes, its intent alignment, the overall verdict and finding counts, and that the dashboard is ready, then stop calling tools and go idle. Do not paste the full contents of pr_description.md, review_results.md, or the individual review comments into the chat window, because they are already written to the dashboard files and shown in the dashboard UI.
   • In Pane Mode, tell the user the PR Review dashboard is open in the side pane (or can be opened from the open_pr_review_dashboard tool step's Open in side pane button or the AuxPane + menu) and wait for a message starting with Review dashboard submitted or Review dashboard aborted.
   • In Browser Mode, the launcher opens the review UI in the user's browser and waits until they click "Submit Review to GitHub" or "Abort Review".
3. Verify Status:
   • In Pane Mode, call dashboard_status with the session ID: if status is "saved", proceed to Step 5; if status is "aborted", clean up the temporary workspace and stop without contacting GitHub; if status is "superseded", a newer review replaced this session, so stop without contacting GitHub and continue with the newer session.
   • In Browser Mode, check the background task exit code: if 0 (saved), proceed to Step 5; if 1 (aborted by user), clean up the temporary workspace and stop without contacting GitHub; if 2 (startup or file validation error), inspect stderr, fix the missing or malformed file, and relaunch the dashboard.

Step 5: Batch Review Submission & Workspace Cleanup

1. Submit Batched Review: Run apply_review.py to submit all approved decisions atomically via the GitHub API:

   python3 scripts/apply_review.py \
     --decisions-file <conversation-scratch-dir>/review_decisions.json

   • Inline comments (is_diff_hunk: true) are posted directly on their respective lines.
   • Broader context comments (is_diff_hunk: false) are appended under ### Broader Context & Non-Diff Observations in the top-level review body.
   • apply_review.py automatically appends <sub><!-- agent-generated --><kbd>🤖 Agent-generated</kbd></sub> to each inline comment and non-empty review summary body; do not manually add this badge to draft_comment or overview.
2. Clean Up Workspace: Remove the temporary checkout directory by passing <conversation-scratch-dir>/workspace_dir.txt directly (do not use "$(cat ...)" or rm -rf):

   python3 scripts/review_engine.py --cleanup <conversation-scratch-dir>/workspace_dir.txt

   Any --verify checkouts and the staged diff directory that code-review created were already removed by its Step 6 in Step 3.3.
3. Report to User: Provide the user with a summary containing the review verdict, approved comments count, and the URL to the submitted GitHub review.

Bundled Resources

• review_guidelines.md: Rules for blind-first PR descriptions, intent reconciliation annotations, and actionable code review feedback.
• suggestion_syntax.md: GitHub markdown suggestion fence syntax and line range rules.
• findings_schema.md: Fields of review_findings.json, review_decisions.json, pr_coords.json, pr_context.json, and code_review_prep.json.
• scripts/diff_parser.py: Unified diff parser and diff hunk line validator.
• scripts/review_engine.py: Two-stage workspace preparer (--prepare-workspace, with hardened git config, static execution-risk pre-scanning into pr_coords.json.security_prescan or --security-scan, and GitHub stack detection via gh stack view --json into --output-stack), Stage 1 description budget checker (--check-description-budgets), context fetcher (--fetch-context with --require-blind-description, --input-stack, and --prepare-code-review / --output-prep), and cleanup utility.
• scripts/launch_dashboard.py: Local HTTP server and --dump-json data normalizer for the interactive review dashboard. Normalizes findings and merges --meta-file and --description-file.
• assets/review_dashboard.html: Interactive dark-themed single-page review dashboard with a top-level Blind Diff Description & Intent Alignment card and GitHub-style Write / Preview tabbed Markdown editors (rendering GFM pipe tables, LaTeX MathML, and Mermaid SVG diagrams) for the Review Summary and per-finding comment fields.
• scripts/apply_review.py: Submits batched review payloads to the GitHub Reviews API with hybrid comment routing.