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 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. 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. Skill-specific values:

• 0a. Branch and working-tree check — branch-name pattern: lead-project/<descriptive-name>. The descriptive name comes from the operator or is derived from the intent's purpose.

• 0b. Resume existing run or start fresh — state-doc filename: LEAD_PROJECT_STATE.md. "Resume as-is" semantic: agent re-runs a full Observe + Orient before the next Decide.

• 0c. Elicit commander's intent — five fields per the canonical schema in references/autonomy.md § "Commander's-intent schemas per skill / /lead-project". Push-back examples specific to this skill:

  • "Works well" → "What does 'well' look like? What command would I run to verify?"
  • "Fix the bugs" → "Which bugs? Are they tracked? What's the test that proves they're fixed?"
  • "Clean up the codebase" → "Clean up in what dimension — dead code, structure, naming? What signal tells us cleanup is sufficient?"

  For each End-state condition, classify it in the state doc as Mechanical (a shell command or other deterministic check the skill can run, e.g., go test ./... exits 0) or Subjective (requires human judgment, e.g., "README reads clearly to a new user"). Mechanical conditions become hard gates at termination; subjective conditions are presented to the user in the completion report for final sign-off.

• 0d. Optional /review-health — see below (skill-specific step inserted between intent elicitation and state-doc seeding).

• 0e. Seed LEAD_PROJECT_STATE.md — include the pinned intent (all five fields, verbatim), the initial triage plan (first 3–5 actions), an empty cycle log. Gitignore the state doc per the protocol.

0d. Optional /review-health

Decide whether to run /review-health based on:

• Run it when: codebase is unfamiliar, intent is broad, or the user indicates this is a first look.
• Skip it when: intent is narrow and specific (e.g., "implement these three tickets"), or when prior state doc shows recent health assessment.

If run, capture the findings as input to initial triage planning.

1. OODA Loop

Repeat until termination condition met, andon cord pulled, or hard cap (50 cycles) reached.

Each cycle follows four explicit phases. Keep phase transitions visible in the state doc — the cycle log entry should note what happened in each phase.

1a. Observe

Snapshot the current project state. Always check:

• git status and current branch
• Test sui