メニュー
Use when the user asks where things stand, what's in progress, or "where was I". Computes a derived view of every feature's status from git and the briefs — nothing is read from a stored status field.
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-status |
| description | Use when the user asks where things stand, what's in progress, or "where was I". Computes a derived view of every feature's status from git and the briefs — nothing is read from a stored status field. |
Report the state of all features by DERIVING it from git (.claude/yolo/conventions.md). There is no stored status field — do not look for one.
base_branch (workspace/config.yaml project.base_branch, else the detection
rule in .claude/yolo/conventions.md). Guard every ref with git rev-parse --verify -q
before using it; if base_branch does not resolve, report a config error and stop. If
workspace/config.yaml is absent, use the config-absent fallback from conventions.git for-each-ref --format='%(refname:short)' refs/heads/feature/ — so a feature/<slug> with no brief is surfaced as an untracked-branch row, not silently dropped.workspace/features/*/brief.md, take <slug> from the folder. A brief with front-matter cancelled: true is reported as cancelled and otherwise skipped. Else derive status exactly per .claude/yolo/conventions.md Deriving status, in order:
yolo/done/<slug> exists, OR base history carries a YOLO-Feature: <slug> trailer (both durable — survive branch deletion/squash), OR (branch still present) its tip carries YOLO-Verified: true with a committed verification.md. This is what makes a shipped-and-deleted branch read as done, not planned. (git branch --merged is intentionally not used — it false-positives an empty freshly-cut branch.)feature/<slug> exists and is not done. Completed tasks (advisory, deduped):
git log <base>..feature/<slug> --format='%(trailers:key=YOLO-Task,valueonly)' | sed '/^$/d' | sort -u (count vs the task total in plan.md — progress only, never the done test).feature/<slug> does not exist.milestone: value when set. For planned/in-progress rows whose brief lists depends_on, flag any dependency not yet done as blocked-by: <slug>.