菜单
Use when a feature is implemented and verified, to land it. Default path is PR + CI check, with the ship gate confirming before the irreversible merge; fast-local is the escape hatch. Includes the risk classifier whose hard triggers always stop for a human. Triggers on "ship it", "land this", "open a PR", or as the finish step of yolo-feature.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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-finish |
| description | Use when a feature is implemented and verified, to land it. Default path is PR + CI check, with the ship gate confirming before the irreversible merge; fast-local is the escape hatch. Includes the risk classifier whose hard triggers always stop for a human. Triggers on "ship it", "land this", "open a PR", or as the finish step of yolo-feature. |
Land verified work. Match the rigor to the risk.
The branch carries YOLO-Verified: true (.claude/yolo/conventions.md). If not, run yolo-verify first.
Run finish reasoning (risk classification, summary synthesis) at the agents.finish tier
from workspace/config.yaml (inherit if unset).
workspace/config.yaml finish.mode)mode: local, or user says throwaway/offline): land with a real merge
commit — always --no-ff so there is a commit to carry the done-trailer (never a
fast-forward). Normal single-checkout case:
git switch <base_branch> && git merge --no-ff feature/<slug> -m "yolo: merge feature/<slug>" -m "YOLO-Feature: <slug>".
If base_branch is checked out in another worktree, run that same merge from that
worktree (git refuses to update a ref checked out elsewhere — don't fight it). The
condensed summary goes in the merge-commit message. No forge.mode: pr, the default): push the branch and open a PR/MR
(gh pr create / glab mr create). The PR description IS the summary — generated from
the brief (what) + plan (how) + diff (the work) + verification (evidence) — with the
YOLO-Feature: <slug> trailer kept as the body's final standalone paragraph (see Land).In BOTH paths the landing MUST produce the durable done-markers (see Land).
finish.ci)"Has CI" means a required check actually reports on the PR (gh pr checks <pr> returns
checks / GitLab has a pipeline for the MR) — NOT merely the presence of a workflow file,
which may produce no required check.
auto: if a check reports, require it green before merge; if none reports, fall back to
the yolo-verify result as the gate.require: always demand green CI. If NO check reports, this is a hard error — surface it
to the human (do not wait forever on a check that will never arrive).off: never wait on CI.
When polling a pending check, bound the wait (cap attempts / total time, e.g. ~20 min); on
timeout, stop and escalate to the human rather than hanging.The hard triggers below are path-independent: they fire on a fast-local merge exactly as
on a PR — "just ship it locally" never skips them. Only the CI handling above is PR-specific.
Compute against the three-dot diff git diff <base_branch>...feature/<slug> (what the
branch introduced since the merge-base — two-dot .. would fold in unrelated changes that
landed on base and falsely inflate size and sensitive-path hits) and workspace/config.yaml risk.*.
Hard triggers (always stop for the human, even when the ship gate was pre-consented, on either path):
risk.sensitive_paths glob.Soft triggers (call them out at the ship gate; escalate when crossed):
risk.max_diff_lines OR changed files > risk.max_diff_files.Landing on <base_branch> (local merge OR PR merge) is the irreversible boundary — the
ship gate (.claude/yolo/conventions.md The two gates). By default it asks a human
before merging. Only two things pre-consent it: a per-feature prose "just ship it / don't
ask" from the user, or finish.auto_merge_on_green: true (headless/unattended runs only).
A hard trigger overrides any pre-consent, on both the local and PR paths.
Decision (the CI clause applies on the PR path; everything else applies to both paths):
Avoid the check-then-merge race: capture the reviewed head SHA at the ship gate and
merge only that SHA — gh pr merge --match-head-commit <SHA> (GitHub refuses if the
head moved; the flag is --match-head-commit, there is no --sha) — or re-confirm
CI-green + unchanged-head immediately before merging.
The landing makes the feature done, and that fact must survive branch deletion and
squash merges (per .claude/yolo/conventions.md). Produce BOTH markers:
yolo/done/<slug> tag — the guaranteed durable signal, independent of how the
merge commit's message is formed: git tag -a "yolo/done/<slug>" -m "yolo: done <slug>"
(push it on the PR path: git push origin "yolo/done/<slug>").YOLO-Feature: <slug> trailer on the landing commit. git merge has no
--trailer flag, so put it in a trailing message paragraph:
git merge --no-ff feature/<slug> -m "yolo: merge feature/<slug>" -m "YOLO-Feature: <slug>".
For a local squash: git commit -m "yolo: merge feature/<slug>" --trailer "YOLO-Feature: <slug>"
(git commit does support --trailer). For a forge merge/squash (gh pr merge,
glab mr merge) the commit message is composed server-side from the PR title/body — so
put YOLO-Feature: <slug> as the final paragraph of the PR body, alone on its own line
with nothing after it. Git parses a line as a trailer only when it sits in the message's
last paragraph and that paragraph is all trailers — a summary section, evidence bullet, or
any prose after the line silently defeats %(trailers:key=YOLO-Feature,valueonly), the
exact probe yolo-status runs. Because forge message composition cannot be guaranteed, on
the PR path the yolo/done/<slug> tag is the mandatory done-marker — create and push it
independently of the merge (above) so status stays correct even if the trailer never parses.Without at least the tag, yolo-status cannot tell a shipped-and-deleted feature from one never started.
After a successful merge, in this order (deleting a branch checked out in a worktree fails):
git worktree remove ../.<repo-name>-worktrees/<slug> if one was created.git branch -D feature/<slug> (and git push origin --delete feature/<slug> on the PR path, if not auto-deleted by the forge).