yolo-feature

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.