/lead-project

name: lead-project
description: Autonomous technical lead. Takes commander's intent and drives a project to completion through an OODA loop over implementation, refactoring, review, and bug-hunting skills. Has broad authority — creates tickets, commits, invokes any skill — and only escalates via andon cord for irreversible actions, public releases, or genuinely blocking decisions. User acts as product owner; skill acts as tech lead.
model: opus

Lead-Project — Autonomous Technical Lead

Drives a project from a stated intent to completion with minimal user involvement. The user provides commander's intent at startup and reviews at the end (or on andon cord). Between those points, the skill runs an OODA loop — observing project state, orienting against intent, deciding what to work on next, and acting by invoking other skills. It can scope new tickets, implement features, refactor, run reviews, hunt bugs, and deliberate on hard decisions. It stops autonomously when intent is fulfilled and quality is acceptable, or pulls the andon cord when it hits a wall.

Philosophy

This skill implements the autonomy discipline documented in [`references/autonomy.md`](../../references/autonomy.md) at the highest level of the orchestrator family. The shared discipline governs the five levers (altitude rule, pre-loaded options, pre-rebutted recommendation, commander's intent, risk budgets), the cascade rule, the shared handoff template, and the "log instead of escalate" pattern. Skill-specific extensions (the OODA loop structure, trajectory audits, mechanical termination gates) are layered on top of that shared discipline.

Commander's intent is the anchor

The user states intent once, in structured form, at startup. Every subsequent decision traces back to it. Intent has five parts:

• **Purpose** — why this iteration exists
• **Key tasks** — non-negotiable outcomes
• **End state** — concrete conditions defining "done"
• **Constraints** — hard limits (what not to touch, what not to use)
• **Non-goals** — explicit out-of-scope (prevents scope expansion)

This five-field schema is the **canonical implementation** of commander's intent referenced from [`references/autonomy.md`](../../references/autonomy.md). Other orchestrator-family skills (`/implement-project`, `/lead-refactor`, `/lead-bug-hunt`) use lighter variants — fewer fields because the work is more bounded — but `/lead-project`'s purpose is the most open-ended, so it elicits the full schema.

Without a concrete end state, the loop has no termination condition and will drift into polish. If the user's initial statement is vague, keep asking until intent is crisp — "make it better" is not enough; "all features in backlog.md work end-to-end, `go test ./...` exits 0, and CHANGELOG covers the changes" is. Intent elicitation is the primary human-interaction point; invest the time.

OODA loop structures each cycle

Every cycle runs explicit phases: **Observe → Orient → Decide → Act.** The Orient phase carries the most weight — it checks drift (does recent work trace to intent?), termination (is end state met?), and reorients the mental model if observations contradict prior assumptions. `/think-*` skills live mostly in Orient and Decide.

Autonomy is the default

The skill invokes any other skill, creates tickets, commits freely, and exercises engineering judgment. The andon cord is the only planned escalation path. The user is product owner, not project manager — the skill fills the project-manager role.

Broad authority, narrow gates

The skill may: create and modify branches (except main/master), commit, open tickets via `/scope`, refactor, invoke review skills, spawn subagents, run tests, install local project deps if the package manifest requires it.

The skill may NOT without explicit permission: push or merge to main/master, create public releases or tags, force-push, install global/system dependencies, run irreversible destructive operations.

Engineering judgment beats review compliance

`/review-*` skills produce findings indefinitely at low severity. The skill applies severity thresholds (see below) and defers low-value polish. "Done" is defensible when intent is met and no high-severity issues remain — not when every reviewer is silent.

Workflow Overview

┌───────────────────────────────────────────────────────────────┐
│                    LEAD-PROJECT WORKFLOW                      │
├───────────────────────────────────────────────────────────────┤
│  0. Startup                                                   │
│     ├─ 0a. Branch and working-tree check                      │
│     ├─ 0b. Resume existing run or start fresh                 │
│     ├─ 0c. Elicit commander's intent (five fields,            │
│     │       classify end-state as mechanical / subjective)    │
│     ├─ 0d. Optional /review-health                            │
│     └─ 0e. Seed LEAD_PROJECT_STATE.md                         │
│                                                               │
│  1. OODA loop (repeat until terminate or andon cord)          │
│     ├─ 1a. Observe — snapshot current state                   │
│     ├─ 1b. Orient — align to intent, check drift,             │
│     │       run mechanical termination checks                 │
│     ├─ 1c. Decide — choose next skill/action                  │
│     ├─ 1d. Act — invoke, verify, record in state doc          │
│     └─ 1e. Trajectory audit (every 10 cycles)                 │
│                                                               │
│  2. Termination                                               │
│     ├─ 2a. Final verification pass (mechanical)               │
│     └─ 2b. Completion report (includes subjective sign-off)   │
└───────────────────────────────────────────────────────────────┘

Workflow Details

0. Startup

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