Menu
Use when you have a goal or brief and need to break it into executable, testable tasks. Produces a committed plan.md. Triggers on "make a plan", "break this into tasks", or as the planning step of yolo-feature.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | yolo-plan |
| description | Use when you have a goal or brief and need to break it into executable, testable tasks. Produces a committed plan.md. Triggers on "make a plan", "break this into tasks", or as the planning step of yolo-feature. |
Turn a goal into an ordered set of small, testable tasks. One task = one commit.
workspace/features/<slug>/brief.md) and, if present, …/research.md.id, title, description, the files it touches, a test_spec (the tests to write/update — required for non-scaffolding tasks), relevant_tests (paths to existing tests that already cover the touched code — the contract to keep green; the executor loads these into context, since the measured TDD win is knowing which tests to check, not the ritual), a one-line verification, and depends_on (task ids).lint_commands and test_commands from its config (package.json scripts, Makefile, pyproject, etc.) and record them — yolo-verify reuses them.Write workspace/features/<slug>/plan.md as YAML:
tasks:
- id: add-csv-export
title: "Add CSV export endpoint"
description: "..."
files: ["src/export.ts"]
test_spec: "src/export.test.ts: happy-path export + empty-dataset"
relevant_tests: ["src/reports.test.ts"] # existing tests covering this area — keep green
verification: "GET /export returns text/csv"
depends_on: []
lint_commands: ["eslint ."]
test_commands: ["npm test"]
Commit the plan (yolo: plan <slug>).
relevant_tests (existing contract) and test_spec (new tests) are loaded into the executor's context — and committed with the trailer YOLO-Task: <id> (<id> matches the task's id field; see .claude/yolo/conventions.md)..claude/yolo/conventions.md The two gates). Lead with the key findings/assumptions from research the plan rests on (a wrong assumption is the costliest thing to catch late — research-review is higher-leverage than diff-review), then the tasks. Skip only if the user pre-consented ("just go").plan.md.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.
Use when facing a design or architecture decision that benefits from multiple perspectives before committing. Produces a decision record under workspace/decisions/. Triggers on "help me decide X vs Y", "which approach", "should we use A or B".
Use when setting up YOLO in a project for the first time, or repairing the setup. Scaffolds workspace/config.yaml and the features/, decisions/, and debug/ dirs (plus docs/ for the docs engine), and installs the CLAUDE.md routing block. Triggers on "set up YOLO here", "init yolo", "yolo init".
Use when a feature should draw on the project's reference material for context. yolo-intake does NOT fetch, import, or copy anything — it points YOLO at a selected folder (default `docs/`) and READS from it to enrich a feature's context. Getting material INTO that folder (a Figma, a spec, a URL, a schema) is the docs engine's or another connector's job, done separately. Triggers on "use the docs as context", "reference the spec/schema in docs", "the feature should read our docs".
Use before planning a YOLO change, to understand the codebase and any cited intake before a plan is written. Read-only exploration that produces context for yolo-plan. Triggers on "understand how X works", "explore the code before we change it", or as the research step of yolo-feature.
Use when a reported problem, failure, or bug needs a systematic root-cause investigation — reproduce → isolate → fix → verify — recorded as one durable artifact. Triggers on "fix the 500 on login", "X is broken", "why is Y failing?", "debug this", "track down this bug".