Menu
Use to check a feature's work against its success_criteria and record the result. Produces verification.md and, on pass, the YOLO-Verified trailer. Triggers on "verify this", "does it meet the criteria", or as the verify 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
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-verify |
| description | Use to check a feature's work against its success_criteria and record the result. Produces verification.md and, on pass, the YOLO-Verified trailer. Triggers on "verify this", "does it meet the criteria", or as the verify step of yolo-feature. |
Decide, with evidence, whether the work satisfies the brief's success_criteria.
workspace/features/<slug>/brief.md (success_criteria), the diff git diff <base_branch>...feature/<slug> (three-dot — only what the branch introduced; see .claude/yolo/conventions.md), and plan.md lint_commands/test_commands.lint_commands and test_commands. Capture pass/fail and key output.success_criteria, gather concrete evidence (a passing test, an observed behavior, a code reference). Mark it met/unmet.workspace/features/<slug>/verification.md: one section per criterion with its evidence, plus the lint/test results.git add workspace/features/<slug>/verification.md && git commit -m "yolo: verify <slug>" --trailer "YOLO-Verified: true"YOLO-Verified: true (.claude/yolo/conventions.md). The execute→verify loop is bounded (.claude/yolo/conventions.md The two gates); after repeated failure the caller should stop and escalate to the human rather than re-running, since that signals the plan or criteria need rethinking.verification.md. You do not edit code.