メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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".
| 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.