Review Fix Address Bots

Review, Fix, and Address Bots

Execute these phases in order. The primary agent alone owns judgment, edits, commands that mutate the workspace, validation, Git, PR changes, and bot replies.

Invariants

• Reviewers are advisory and strictly read-only. They may inspect files, diffs, history, tests, and existing output, but must not modify files or Git/PR state; run tests, builds, package scripts, generators, or arbitrary repository commands; or delegate implementation.
• Include this boundary in every reviewer prompt: “Operate in read-only mode. You are advisory only. Never modify the workspace or Git/PR state, and never commit or push. Return findings and critique to the primary agent, who makes the final decision.”
• Preserve unrelated user changes. Never use reset, automatic stashing, broad staging, history rewriting, or checkpoint commits to clear a dirty tree.
• Logging is observational. If it fails, report the failure and continue the safe workflow; never change code, judgment, Git/PR state, or loop limits for telemetry.
• Treat scripts/review-run-log.mjs as an opaque executable. Never read its source during this workflow. Invoke its documented commands and use templates, --help, and the Markdown references; inspect or change its source only when the user explicitly asks to debug or modify the helper.

1. Prepare the integrated target

1. Read repository instructions and applicable implementation skills. Record branch, status, target, remotes, upstream, PR state, and the initial dirty-state ownership boundary. Require a named non-target branch before pushing; never rename it or push the default branch without explicit authorization.
2. Use the user's review prompt. If a requested custom prompt is unavailable, stop for it. Only when none was requested, read references/review-guidelines.md.
3. Resolve this skill's directory and run node <skill-dir>/scripts/review-run-log.mjs templates for canonical payloads, then start with the resolved cohort and limits before review work. Keep its logPath in .context; append material transitions and every reviewer invocation. Read references/run-logging.md only if the helper rejects a record, logging needs extension, or telemetry behavior must be diagnosed.
4. Inspect committed, staged, unstaged, and relevant untracked changes together. Prefer Conductor's workspace diff; otherwise inspect the merge-base-to-HEAD diff, git diff HEAD, git status --short, and relevant untracked files. Exclude unrelated user work from the implementation.
5. Resolve the PR's actual base branch and repository remote; without a PR use repository configuration. Fetch that base explicitly, record its ref and SHA, and do not use git pull. If the fetched SHA is not an ancestor of HEAD, integrate it before formal review with an explicit merge by default. Rebase only when required or requested, and never rewrite published history without authorization.
6. Do not let pre-existing staged changes enter a merge commit. If dirty work makes integration unsafe, stop. Resolve conflicts from both branches' intent, surrounding code, and tests; request input for material product, UX, public API, or architecture choices. The integrated tree, conflict resolutions included, is the review target. If integration happens after review starts, invalidate every report and rerun the cohort.
7. Before the first push, resolve authority to create a PR if none exists and the bot phase requires one. Stop before the remote mutation when authority is absent.

Reviewer sessions

Use the reviewer count, model mix, and reasoning levels explicitly requested by the user. Otherwise use this default cohort for every initial and remediation pass:

For a count from one through five, use that order. For another explicit mix, assign stable IDs from model tier plus one-based ordinal. Ask for a mix when a count above five is otherwise underspecified. Normalize task names from sol-1 to sol_1 for deterministic discovery. Keep the raw review prompt, target fingerprint, role boundary, and service tier identical across the cohort; use each reviewer's assigned reasoning level. Queue over concurrency limits without editing the target.

Packet

Do not send this skill, any reference, helper commands, run-log details, or the primary conversation to a reviewer. Give every reviewer the same self-contained packet containing only the review task: raw user prompt (or default criteria), target SHA and workspace fingerprint, relevant scope/diff or paths, conflict summary if applicable, read-only boundary, and required finding format (file, minimal line range, severity, scenario, rationale). Exclude other reviewers' findings, the primary's conclusions, remediation decisions, and telemetry instructions.

Launch and verify

Launch every initial reviewer with fork_turns: "none", its self-contained packet, and the requested model and reasoning level; do not fork the primary conversation. Require the runtime to expose the exact applied controls and a stable resumable handle. Verify applied settings from runtime evidence, not requested arguments alone.

Launch concurrently where the runtime permits. Never use an ephemeral reviewer. A failed control verification blocks editing and finishes blocked; never treat requested arguments alone as verification. Record reviewer_session_started as soon as a handle is available and reviewer_session_controls_verified only after persisted verification. Record completed-task durationMs only when the runtime exposes it.

Observe, recover, and clear stalled workers

After each bounded wait (30 seconds by default), run the cohort watcher. It is a maximum polling interval, not a runtime floor: handle completions immediately.

node scripts/review-run-log.mjs inspect-reviewers \
  --log "$REVIEW_RUN_LOG" \
  --stale-after-ms 120000 \
  --soft-deadline-ms 600000 \
  --hard-deadline-ms 1200000 \
  --hard-deadline-ms-by-model '{"gpt-5.6-luna":1800000}' \
  --record

The soft deadline is a warning. The default hard deadline is 20 minutes; Luna reviewers get 30 minutes. A hard deadline begins at the current task_started (or session start when absent). Before classifying a reviewer as failed, inspect its exact persisted session. active, stalled, and one in_progress result are not failures. The watcher does not interrupt workers.

For a hard-exceeded reviewer, immediately inspect the exact session once more. If it remains non-terminal, call agents.interrupt_agent with the inspection's nativeHandle, never its persisted sessionId; confirm with agents.list_agents that it stopped; then append reviewer_session_cancelled with reviewer ID, persisted session ID, native handle, phase, reason, and applied deadline. Never use a broad kill, interrupt another reviewer, or probe an initial review with a follow-up. One fresh initial retry may use a distinct task name such as sol_1_retry_1, but retains reviewer ID sol-1.

If that retry also exceeds its hard deadline, mark the reviewer exhausted and exclude it from continuity and remediation. Preserve every completed review and continue the workflow with those reviewers; the run is partial, but a timeout alone must not block editing or discard their findings. Block only when no initial reviewer completes or another safety or integrity condition prevents continuation. A hard-exceeded continuity session follows the full-cohort restart rule after clearing the exact handle.

For a missing or unreadable result, inspect the exact session before retrying: