yolo-jail: Skill for Claude Code

Cut a yolo-jail release

Use this workflow for yolo-jail releases. Read the release-process reference when a request meets an existing tag, failed workflow, partial publication, or resume. Write the changelog section by the rules below. Landing work adds no changelog entry, so the section is written here, once, from the commits since the last tag.

A release request can create an immutable tag and publish artifacts. Never run just release or dispatch a workflow unless the owner explicitly authorized publication. This skill prepares and verifies; it does not grant publication authority.

Reuse evidence; do not repeat the full suite

Keep code landing, release preparation, and publication as separate stages:

• Code changes follow the normal testing and landing rules in AGENTS.md. Normally, a launch-path landing includes one full integration suite. If the owner explicitly orders a particular code landing main-first, do not make a duplicate local suite a precondition to that already-authorized landing; report local and CI checks honestly as pending or canceled. This is a narrow sequencing instruction, not a general waiver of checks or hooks. The exact target SHA's regular main-push CI, including integration proof, is still required before tagging—but the release request runs that gate automatically; it is not a manual precondition to invoking just release.
• Regular ci.yml push CI runs the complete integration suite across Linux architectures and shards, then checks that every listed test ran. Before tagging, the release gate requires a successful regular main push CI run for the exact target SHA, including all required jobs and shard-completeness proof. A green PR run alone is not enough. The gate is enforced by preflight.sh and gate.go. preflight.sh invokes the gate with a 60-minute timeout and 15-second polling interval, first in release-request eligibility and again immediately before the tag write. The gate waits while proof is pending or absent; a completed failed/cancelled run or a proof/API timeout refuses without creating the tag. Release workflows consume that exact-SHA proof; release and publish recheck it. They prepare and publish release outputs but do not rerun the integration suite. If only release notes, docs, or the version heading changed, do not add another full Go or integration run: validate the notes locally, then rely on the exact-SHA main-push CI gate. If code, tests, or release-gate inputs changed, run the relevant tests under AGENTS.md and require CI for the final target SHA.