yolo-finish

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.

yolo-finish

Land verified work. Match the rigor to the risk.

Precondition

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).

Choose the path (read workspace/config.yaml finish.mode)

• fast-local (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.
• PR (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).

CI check (PR path; 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.

Risk classifier (runs on EVERY landing — local merge and PR alike)

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):

• yolo-verify did not cleanly pass, or success_criteria were vague.
• Diff touches any risk.sensitive_paths glob.
• Deletes/renames a public API or widely-imported symbol.

Soft triggers (call them out at the ship gate; escalate when crossed):

• Changed lines > risk.max_diff_lines OR changed files > risk.max_diff_files.
• A new external dependency added (package-manifest change).
• New logic shipped with no accompanying tests.

The ship gate (decides confirm vs merge)

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):

• PR path with CI red/pending → never merge (red stops; pending polls, bounded as above).
• A hard trigger fired → stop, surface the specific trigger(s), wait for the human — even if pre-consented, even on the local path.
• Not pre-consented (the default) → confirm with the human before merging, even on a clean green run.
• Pre-consented AND no hard trigger AND (PR: CI green / local: yolo-verify passed) → merge; set the PR body / merge-commit summary.

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.

Land (durable done-markers)

The landing makes the feature done, and that fact must survive branch deletion and squash merges (per .claude/yolo/conventions.md). Produce BOTH markers:

• The 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>").
• The 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.

Cleanup

After a successful merge, in this order (deleting a branch checked out in a worktree fails):

1. git worktree remove ../.<repo-name>-worktrees/<slug> if one was created.
2. git branch -D feature/<slug> (and git push origin --delete feature/<slug> on the PR path, if not auto-deleted by the forge).