lead-review

What this skill does

# 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                                       │
└──────────────────────────────────────────────────────────────────┘
```

Each enabled sub-skill runs once. Skipped sub-skills are recorded in the cycle log and surfaced in the report.

## Workflow Details

### 0. Startup

Follow the shared startup protocol in [`references/lead-startup.md`](../../references/lead-startup.md). Skill-specific values:

- **0a. Branch and working-tree check** — branch-name pattern: `lead-review/<date>` (e.g., `lead-review/2026-05-12`). Note: `/lead-review` does not itself commit code. The branch is the integration point for any commits sub-skills make (rare — most review sub-skills are advisory) and the boundary for any tickets cut.
- **0b. Resume existing run or start fresh** — state-doc filename: `LEAD_REVIEW_STATE.md`. "Resume as-is" semantic: re-check skip-list, continue from the next enabled phase.
- **0c. Elicit commander's intent** — four fields per the schema in [`references/autonomy.md`](../../references/autonomy.md) § "Commander's-intent schemas per skill / `/lead-review`". Push-back examples specific to this skill: "Just check everything" is not a scope — ask about exclusions; "Whatever severity" is not a floor — push for Critical+High as the productive default.
- **0d. Auto-detect skip-list and confirm** — see below (skill-specific step inserted between intent elicitation and state-doc seeding).
- **0e. Seed `LEAD_REVIEW_STATE.md`** — include the four pinned intent fields, the enabled-list and skip-list (with reasons for skips), `Current phase: phase-1`, an empty cycle log, and an empty findings ledger. Gitignore the state doc per the protocol.

#### 0d. Auto-detect skip-list and confirm

Inspect the codebase to determine which review sub-skills do not apply:

- **No web content** (no HTML, JSX/TSX, Vue, Svelte, CSS, templates) → skip `/review-a11y`
- **No test suite detected** → skip `/review-test` (or warn; operator may want to run it anyway to flag the absence)
- **No deployable target** (no Dockerfile, no release tags, no build pipeline config) → consider whether `/review-release` adds value; default is to run it anyway since it scans for debug artifacts and version mismatches even without a deployment

Present the proposed skip-list and the enabled-list to the operator. Confirm before proceeding.

### 1–7. Phases — Sub-Skill Invocations

Each enabled sub-skill runs exactly once. The phases are sequenced so earlier phases inform later ones (orientation → architecture → security → performance → accessibility → tests → release-readiness).

For each phase:

1. **Invoke** the sub-skill wit