git:20260905.9dc1cd3 to git:20260912.4981e8a

10 added, 12 removed. Audit A to A.

---

name: total-review

- description: 'Run both fable-review and gpt-review on the current work, then merge their findings, dedupe them, and triage which issues are real vs overthinking. Outputs one clear, concise list of actual issues for the user to approve before fixing. Use when the user says "/total-review", "total review", "review with both", or wants both Fable and GPT reviewers at once. Differentiator: runs BOTH reviewers and triages the merged findings — for a single reviewer use fable-review or gpt-review.'

+ description: 'Run Fable and GPT reviews, then combine their findings for the user''s approval. Use only when the user explicitly invokes /total-review.'

+ disable-model-invocation: true

---

# Total Review

- Run both code reviews, merge the findings, and give the user one shortlist of real issues to approve.

## Workflow

1. **Launch both reviewers in parallel** as two bb threads (default). Follow `/nagent`, `/bb-cli`, and each reviewer skill:

- One `fable-review` worker (Fable 5 Max 1M).

- One `gpt-review` worker (GPT 5.6 Sol Max).

- - Follow each skill's own instructions exactly: neutral, unbiased prompt; tell it what to review broadly; ask for a detailed report on critical/serious issues; concise plain-English final report.

- - Reuse this thread's environment so both see the same files. Spawn both, then let them work.

+ - Follow each reviewer skill exactly: neutral prompt, broad review scope, detailed findings on critical/serious issues, concise plain-English final report.

+ - Reuse this thread's environment so both see the same files.

- If the user names another harness (Cursor Task, cmux, Codex CLI, etc.), use that for both instead.

2. **Wait for both to finish** (`bb thread wait` on each, unless another harness was requested). Do not start triage until both reports are back.

3. **Merge and triage.** Read both reports in full. Then:

- - Combine all findings into one list.

- - Dedupe: the same issue reported by both counts once — and is almost certainly real.

- - For each finding, think deeply: is this a real bug / real risk, or is the reviewer overthinking (style preference, theoretical edge case, non-issue)?

- - Be ruthless. Most review findings are overthinking. Only keep issues that genuinely matter.

+ - Combine and deduplicate findings; an issue reported by both counts once.

+ - Assess each finding: is it a real bug or risk, or a style preference, theoretical edge case, or non-issue? Agreement alone does not prove an issue is real.

+ - Keep only issues that matter.

4. **Output to the user** — clear and very concise:

- - A numbered list of the **actual, real issues** only, each in one line: what it is + where.

+ - A numbered list of real issues, one line each: what it is + where.

- Mark which reviewer(s) found each: `[both]`, `[fable]`, or `[gpt]`. Issues found by both go first.

- One short line at the end: how many findings were dropped as overthinking.

- Then ask the user: approve fixing these, or adjust the list.

- 5. **On approval, fix and ship.** Fix only the approved issues. Then stage, commit with a clear message, and push to GitHub (per the standard ship workflow). Do not fix anything the user did not approve.

+ 5. **On approval, fix and ship.** Fix only approved issues. Then stage, commit with a clear message, and push to GitHub using the standard ship workflow.

## Rules

- Keep every step's output short and in plain English.

- - Do not show the user the raw reviewer reports by default — only the merged shortlist. (The user can ask for the full reports if they want them.)

+ - Show the merged shortlist by default; provide full reviewer reports only if the user asks.

- Never fix an issue before the user approves the shortlist.