yolo-feature

name	yolo-feature
description	Use when the user wants to build, add, or implement a feature. Captures intent, drafts a brief, confirms, then composes research → plan → execute → verify → finish. In a YOLO-initialized repo this takes precedence over generic brainstorming for feature intent.

yolo-feature

The conversational entry point. You turn "I want X" into a landed, verified change. You confirm at exactly two gates — the plan gate and the ship gate (.claude/yolo/conventions.md The two gates); everything between them flows.

0. Resume or start fresh (cheap)

Derive the slug first (lowercase kebab-case noun phrase of the goal — drop leading imperative verbs like add/build/implement, so "add CSV export" → csv-export, not add-csv-export), then check for existing work before drafting anything new. Match robustly, not by exact string only: list workspace/features/*, compare case-insensitively, AND scan whether any existing brief's goal describes the same change — slug derivation can drift (csv-export vs export-csv), so don't rely on an exact coincidence.

• If a matching workspace/features/<slug>/ or feature/<slug> already exists, this is a RESUME, not a new feature. Run yolo-status for that slug and pick up at the first incomplete step — do NOT re-draft the brief over existing work. If the slug collides with an unrelated feature, disambiguate (suffix the slug) and tell the user.
• If the brief lists depends_on, surface any dependency not yet done before starting, so the user can reorder.

1. Capture intent (cheap — no confirmation)

• Ask a light 2-question check (skip if the user signals they just want to proceed): what the user can DO after this, and how they'd know it works.
• Derive a slug, goal, and success_criteria. Write workspace/features/<slug>/brief.md from .claude/yolo/templates/brief.md. Commit it (yolo: brief <slug>). The brief now existing = status "planned" (.claude/yolo/conventions.md).

2. Branch, research, plan (billed — authorized by the user's request)

The user's "build X" request authorizes the research + plan that lead up to the plan gate; no separate pre-research stop.

• git switch -c feature/<slug> <base_branch> (branch explicitly from base so the merge-base is correct). Create a worktree (../.<repo-name>-worktrees/<slug>) only if work will run in parallel or you need walk-away isolation; otherwise a plain branch. See .claude/yolo/conventions.md for the worktree naming rule.
• Run each billed atom as a subagent at its workspace/config.yaml agents.<step> tier; invoke the named skill inside that subagent rather than reimplementing it here. Each subagent starts from a clean context and hands off only through its committed artifact (research.md → plan.md → task commits (YOLO-Task) → verification.md) — that artifact is simultaneously the human's review surface and the next phase's clean input. This is deliberate: it keeps the main context off the measured 30–50% context-rot curve.
  • yolo-research (agents.research) — invoke when the change is non-trivial or the codebase is unfamiliar; skip for tiny obvious changes.
  • yolo-plan (agents.plan) — produce plan.md.

3. The plan gate (first confirmation)

Present, in order: the key findings & assumptions from research (the codebase facts the plan rests on — a wrong assumption here is the most expensive thing to catch late), then the task plan, then rough scope/cost. STOP for approval or redirect before any code is written — this is the cheap, high-leverage moment to catch a wrong approach. Approving authorizes the execute → verify run through to the ship gate. Skip only if the user pre-consented ("just go"). See .claude/yolo/conventions.md The two gates.

4. Execute + verify (flows through — no confirmation gate)

• execute (agents.execute) — for each task in plan.md, work test-first with the task's relevant_tests (existing contract to keep green) and test_spec (new tests) loaded into the subagent's context — the measured TDD win is knowing which tests to check, not the ritual; a bare "do TDD" instruction without that context regresses worse than nothing. Commit each task with --trailer "YOLO-Task: <id>". Run tasks in parallel subagents only when their files scopes don't overlap; writes that touch shared files stay serial (concurrent writers on shared code produce mismatched assumptions). The throwaway branch + one commit per task is the cheap rollback that earns this no-gate interior.
• yolo-verify (agents.verify) — check success_criteria; on pass it writes the YOLO-Verified: true trailer. On any unmet criterion, return to execute for the failing task(s), then re-run yolo-verify — do not proceed to finish until YOLO-Verified: true is written. Bound this loop (.claude/yolo/conventions.md The two gates — ~2–3 attempts); if criteria still fail, STOP and escalate to the human — repeated failure means the plan or the criteria need rethinking, not another pass.

5. The ship gate (second confirmation)

• yolo-finish (agents.finish) — land per the finishing policy + risk classifier. The irreversible merge onto base_branch is confirmed here; risk hard-triggers always stop even when pre-consented. See .claude/yolo/conventions.md The two gates.

Rules

• Two confirmations only — the plan gate (§3) and the ship gate (§5), per .claude/yolo/conventions.md The two gates. "Just ship it" / "walk me through each step" are per-feature prose overrides, not config.
• Store no status — every "where are we" is derived from git via yolo-status.
• Precedence: in a YOLO repo, feature intent routes here; generic brainstorming yields.
• The atoms are defined once in their own skills — invoke them, don't reimplement them here.