/lead-review

name: lead-review
description: Autonomous comprehensive review. Once-through pipeline over /review-health, /review-arch, /review-security, /review-perf, /review-a11y, /review-test, /review-release. Operator-configurable ticket creation at startup — when ON, auto-approves sub-skill ticket proposals per the orchestrator-family contract; when OFF, uniformly declines and surfaces findings in the consolidated report. Auto-detects sub-skills that do not apply (no web content → skip /review-a11y; no tests → skip /review-test).
model: opus

Lead-Review — Autonomous Comprehensive Review

Drives a codebase through every review dimension — orientation, architecture, security, performance, accessibility, tests, release-readiness — without operator involvement between startup and termination. The operator states scope, whether tickets should be cut, and (if so) the severity floor for ticket creation. The skill then runs each enabled sub-skill in sequence, auto-approving or auto-declining ticket proposals uniformly per the startup choice. Termination is structural — once all enabled sub-skills have run, the consolidated report is produced.

This skill is the successor to `/review-deep`. The v10 move into the `/lead-*` namespace makes the autonomy-axis identity explicit; the redesign trades interactive participation for autonomous execution and adds the ticket-creation toggle so the run can serve both "produce a comprehensive backlog" and "produce a comprehensive audit report" use cases.

Philosophy

This skill implements the autonomy discipline documented in [`references/autonomy.md`](../../references/autonomy.md). The shared discipline governs the five levers (altitude rule, pre-loaded options, pre-rebutted recommendation, commander's intent, risk budgets), the cascade rule, the no-unilateral-breaking-changes guardrail, and the shared handoff template.

Two modes from one workflow

The same pipeline serves two operator intents:

• **Backlog generation** (tickets ON) — autonomous review-driven ticket creation. The skill runs every enabled review sub-skill, auto-approves each one's ticket proposals at or above the severity floor, and produces a consolidated, batch-tagged backlog the operator can feed to `/implement-project` or `/lead-refactor`.
• **Audit report** (tickets OFF) — autonomous comprehensive audit. The skill runs every enabled review sub-skill, auto-declines all ticket proposals uniformly, and surfaces all findings in the consolidated completion report. No tracker writes.

The operator chooses at startup. There is no mid-run switching.

Operator intent is sovereign

The orchestrator does not paternalize. If the operator runs with **tickets OFF**, a CRITICAL finding does not trigger automatic ticket creation, override, or andon-cord interruption — it is flagged prominently in the completion report and the operator decides what to do. The autonomy contract is "do what was authorized at startup, nothing more, nothing less." Overriding commander's intent silently would violate that contract.

Auto-approval/decline is delegated to the autonomy discipline

The advisory `/review-*` sub-skills' ticket proposals are answered by the orchestrator per the contract documented in [`references/autonomy.md`](../../references/autonomy.md) § "Auto-approval of sub-skill ticket proposals". This skill's behavior is mode-dependent: tickets ON → auto-approve at/above the severity floor and decline below; tickets OFF → auto-decline uniformly. The mode is fixed at startup and not changed mid-run. The completion report lists every ticket action.

Once-through, not loop

Reviews produce findings; they don't drive toward a converged state. Looping over them is structural ceremony — the second pass would find roughly the same things as the first unless the codebase changed in between. `/lead-review` runs each enabled sub-skill exactly once.

Broad authority, narrow gates

The skill may: invoke `/review-health`, `/review-arch`, `/review-security`, `/review-perf`, `/review-a11y`, `/review-test`, `/review-release`; create or decline tickets via auto-approved or auto-declined proposals; create and modify the working branch (no commits expected, but tracker writes are commits-in-spirit).

The skill may NOT without explicit authorization: push or merge to main/master, force-push, propose breaking changes (see `references/autonomy.md` § "No unilateral breaking changes"), invoke skills outside the bounded review repertoire, install dependencies, run irreversible destructive operations.

Workflow Overview

┌──────────────────────────────────────────────────────────────────┐
│                    LEAD-REVIEW WORKFLOW                          │
├──────────────────────────────────────────────────────────────────┤
│  0. Startup                                                      │
│     ├─ 0a. Branch and working-tree check                         │
│     ├─ 0b. Resume existing run or start fresh                    │
│     ├─ 0c. Elicit commander's intent (4 fields)                  │
│     ├─ 0d. Auto-detect skip-list, confirm with operator          │
│     └─ 0e. Seed LEAD_REVIEW_STATE.md                             │
│                                                                  │
│  1. Phase 1: /review-health (orientation)                        │
│  2. Phase 2: /review-arch (architecture)                         │
│  3. Phase 3: /review-security (security)                         │
│  4. Phase 4: /review-perf (performance)                          │
│  5. Phase 5: /review-a11y (accessibility) — if applicable        │
│  6. Phase 6: /review-test (test suite)                           │
│  7. Phase 7: /review-release (release readiness)                 │
│                                                                  │
│  8. Termination                                                  │
│     └─ Consolidated report                                       │
└────────────────────────────