菜单
Cut tagged releases safely with SemVer, changelog roll, and validation gates. Use when releasing, bumping version, tagging, shipping, or deciding what version to use. Trigger: release, tag, version bump, ship, publish, cut a release, what version.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Dispatch Codex to review all unreviewed repository work, then verify its correlated findings ticket or clean result. Use when requesting an independent Codex review, auditing all changes, checking work since the last review, or waiting for Codex findings. Trigger: dispatch codex review, independent review, review all changes, check codex findings, run review agent.
Always-on: when a project has tickets, work the frontier (first unblocked open ticket), mark done, update plan status.
Incremental and full-history repository review with resumable adoption batches. Use when reviewing new work, initializing review tracking, reviewing all work to date, resuming historical review, inspecting unreviewed commits, or reviewing changed tickets. Trigger: review new work, adopt repository, review all history, resume review, review marker, unreviewed commits.
End-of-session handoff that captures current state for the next session. Use when ending a work session, switching context, or before a long break.
Consolidate project artifacts — promote scratch to memory, deduplicate memory, process decisions, organize scripts, update steering/skills accuracy. Use periodically or when the project feels cluttered.
Run and interpret crew-research evals — run.sh flags, scores.jsonl fields, activation TPR/FPR verdicts, resuming interrupted runs. Use when running evals, reading eval results, diagnosing a failing definition, or resuming a dead run. Trigger: run the evals, eval results, scores.jsonl, activation test, TPR, delta threshold, resume the run, skip-completed, known gap.
| name | release-protocol |
| description | Cut tagged releases safely with SemVer, changelog roll, and validation gates. Use when releasing, bumping version, tagging, shipping, or deciding what version to use. Trigger: release, tag, version bump, ship, publish, cut a release, what version. |
| metadata | {"type":"protocol","invocation":"both","practice":null} |
Release when [Unreleased] in CHANGELOG.md has meaningful user-facing changes AND project validation passes. Don't release for internal-only changes (CI config, test infra, doc typos, scratch files).
| Change type | Bump |
|---|---|
| Remove/rename public API, command, or deployment path | Major |
| New feature, capability, or supported platform | Minor |
| Bug fix, doc improvement, performance improvement | Patch |
Edge cases: Breaking a documented behavior = Major even if "nobody uses it." Adding a feature with a required config change = Minor (note migration in changelog).
[Unreleased] → [X.Y.Z] - YYYY-MM-DD, commit, tag[Unreleased] must have at least one entryIf any gate fails, abort with no changes made.
# 1. Edit CHANGELOG.md: [Unreleased] → [X.Y.Z] - YYYY-MM-DD, add new empty [Unreleased]
# 2. Commit
git add CHANGELOG.md
git commit -m "release: vX.Y.Z"
# 3. Tag
git tag -a vX.Y.Z -m "Release vX.Y.Z"
# 4. Push
git push origin main --tags
# 5. Create release (if using GitHub)
gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <(sed -n '/## \[X.Y.Z\]/,/## \[/p' CHANGELOG.md | head -n -1)
Fix forward with a patch release. Never delete a pushed tag. If a fix takes time, add a "Known Issues" note to the release.
Defer to changelog-discipline skill for entry writing rules. Key test: would the entry still be true if you replaced the underlying technology?