Harness Release (汎用)

Keep a Changelog + GitHub を使うあらゆるプロジェクト向けの汎用リリース自動化スキル。

設計原則: 単一確認ゲート。ユーザーは 1 回だけ全体計画を見て承認する。承認後はファイル書き換え → commit → branch push → PR 作成/更新 → default branch へ merge → default branch 上で tag → GitHub Release までを中断なく実行する。

Release complete の定義: release は「tag と GitHub Release を作った」だけでは完了ではない。対象 work と release bump が default branch（通常 main）に merge 済みで、release tag が default branch 到達可能 commit を指し、GitHub Release がその tag を公開している状態を完了とする。

PR ready vs release ready

Harness V2 では PR closeout と release closeout を混同しない。

• PR ready は harness-review APPROVE + evidence pack で判定する。harness-review から push / PR / merge はしない。
• release ready は harness-release の Preflight / Post-Gate だけが判定する。version bump / tag / GitHub Release は release lane 専用。
• local tests passed だけでは PR ready でも release ready でもない（not_observed != absent）。

Literal invocation note: この skill の入口は harness-release, /release, /release patch, /release --dry-run のような literal command をそのまま使う。

CC runtime hard floor との関係

Claude Code 2.1.183+ の runtime hard floor は GitHub CLI release publish 系コマンドを構造的に deny する (Anthropic 製品仕様、settings.json の permissions.ask で覆せない)。本 skill は publish 自体を実行せず、.github/workflows/release.yml (tag push trigger) に委譲する。skill は tag push までで責務を完了し、その後 scripts/release-verify-publish.sh で workflow による公開を verify する。

Revert 条件: CC が runtime hard floor に user explicit approval path を提供したら、Post-Gate に直接 publish step を戻すことを検討する。

Bare invocation contract

if $ARGUMENTS == "": → 「今までの作業をコミットし、PR/main 反映まで完了してリリースしたい」と解釈し、Review Gate 検出を実行する → 対象 work が 1 つに確定できる場合だけ Step 0 (Review Gate) へ自動進行する → 対象が不明または review state が無い場合は AskUserQuestion で選択肢を出してから進める

引数なし呼び出し時の最初の応答で必ず次の literal marker を出力する:

RELEASE_AUTOSTART: target=<work-summary>, base_ref=<ref>, mode=<patch|minor|major|auto>

「タスクが不明確」「指示を待ちます」「タスクがありません」「追加の指示をお待ちします」は禁止行動。

Output Contract (P35: 「止まったように見える」UX 対策)

skill 結論時の output の 最後の 1 行は必ず次の literal を含める:

↑この結果は Claude が要約します。Enter キーで次へ進むか、新規 prompt で別の指示を出してください。

これは <local-command-stdout> 経由で text response として表示されると user が「止まった」と感じる UX 問題への明示的な instruction (patterns.md P35)。

harness-release / /release だけが入力された場合、これは 「今までの作業をコミットし、PR/main 反映まで完了してリリースしたい」 という意味として扱う。 旧表現の 「今までの作業をコミットしてリリースしたい」 も同じ意図だが、完了条件には PR/main 反映を必ず含める。 「タスクがありません」「指示を待ちます」で止まってはいけない。

bare release では、通常の release preflight の前に Review Gate と Work Commit Gate を実行する。

Review Gate は release ready 向け。[lane:fast] / [lane:gate] の PR ready だけが必要な work には、ユーザーが release を明示しない限り harness-release を起動しない。

1. git status --porcelain と git log @{upstream}..HEAD / main..HEAD を確認し、「今までの作業」の対象を特定する
2. .claude/state/review-result.json と .claude/state/review-approved.json を確認し、対象 work に APPROVE 済み review と evidence pack があるか確認する
3. APPROVE 済み review が無い場合は AskUserQuestion で確認する
4. ユーザーが「レビューから開始」を選んだら、harness-review を起動し、APPROVE になるまで release へ進まない
5. harness-review が REQUEST_CHANGES を返した場合は release を保留し、harness-work で修正してから harness-review を再実行する。これを APPROVE までループする
6. harness-review が APPROVE を返した後、working tree の作業 commit を作る
7. working tree clean になってから通常の release preflight / confirmation gate / PR merge / tag / GitHub Release へ進む

Review Gate AskUserQuestion

harness-release 実行時に review approval が確認できない場合は、推測で release しない。 次の Ask を出す。

question: "harness-release は今までの作業をコミットしてリリースしますが、この作業の APPROVE review が見つかりません。どう進めますか？"
options:
  - label: "レビューから開始 (Recommended)"
    description: "harness-review を実行し、APPROVE になった場合だけ commit/release へ進みます。"
  - label: "release dry-run"
    description: "ファイルを書き換えず、release 計画と不足 gate だけ確認します。"
  - label: "中止"
    description: "review も release も行わず止めます。"

ユーザーが「レビューから開始」を選んだ場合は、同じセッション内で harness-review から始める。 harness-review の対象決定は harness-review 側の bare review contract に従う。 review が APPROVE なら、そのまま harness-release の Work Commit Gate へ戻る。 review が REQUEST_CHANGES なら release は保留し、harness-work で修正してから harness-review を再実行する。 この修正後再レビュー loop は APPROVE まで継続する。

ユーザーに戻してよいのは次の場合だけ。

1. 修正に仕様正本 / Plans.md / API / permission / migration / billing などの意思決定が必要で、AskUserQuestion が必要
2. 修正方針が複数あり、どれを採るかでユーザー価値や互換性が変わる
3. ユーザーが Ask で release dry-run または 中止 を選んだ

REQUEST_CHANGES 単体を最終停止理由にしてはいけない。

Work Commit Gate

bare release で working tree に未コミット変更がある場合、release version bump commit とは別に、 review 済み work commit を先に作る。

git status --short
git diff --stat
git add <reviewed files>
git commit -m "<type>: <summary>"

commit message は review summary / Plans.md task / branch name から短く生成する。 判断できない場合は AskUserQuestion で 2〜3 個の commit message 候補を出す。 work commit 作成後に .claude/state/review-result.json の commit_hash を確認または更新し、 release preflight へ進む。

通常の release preflight に入った後は、これまで通り working tree dirty を fail とする。 dirty tree のまま version bump / tag / GitHub Release に進まない。

Quick Reference

/release              # 今までの作業を review gate → commit → PR/main merge → release する
/release patch        # bump を patch に明示指定
/release minor        # bump を minor に明示指定
/release major        # bump を major に明示指定
/release --dry-run    # 計画の表示のみ、実行しない

前提条件

このスキルが動くプロジェクトは以下を満たす必要があります:

1. CHANGELOG.md が Keep a Changelog 形式
2. [Unreleased] セクションが存在する
3. 以下のいずれかの version file を持つ:
   • VERSION (単独ファイル)
   • package.json (npm)
   • pyproject.toml (Python, [project] または [tool.poetry])
   • Cargo.toml (Rust, [package])
4. gh CLI がインストール済みで、認証済み
5. git リモート origin が GitHub を指す
6. Claude Code plugin project の場合は、claude CLI が plugin tag をサポートしている

これらが満たされない場合、Preflight で detect して abort します。

prUrlTemplate による multi-host review URL は将来候補として認識するが、 このスキルの release automation は今も gh CLI と GitHub remote を primary path とする。 owner / branch / release asset / CI metadata の自動取得は host ごとの差が大きいため、Phase 56.2.3 では docs-only に留める。

単一ゲートフロー

Bare release（0. Review Gate → 0.5 Work Commit Gate）→ Pre-Gate（1. Preflight → 2. Version file 検出 → 3. バージョン読み取り → 4. plugin tag preflight → 5. bump 推定 → 6. 新バージョン算出 → 7. CHANGELOG ドラフト → 8. Release notes ドラフト）→ 単一確認ゲート（下記「Confirmation Gate」参照、yes / <修正指示> / cancel の 3 択）→ Post-Gate（9. Version file 書き換え → 10. CHANGELOG 昇格 → 11. commit → 12. branch push → 13. PR 作成/更新 → 14. default branch merge → 15. 到達可能性確認 → 16. plugin tag → 17. semver tag → 18. tag push → 19. workflow publish verify → 20. 完了報告） の 3 段階で進む。各段の詳細は「Pre-Gate 詳細」「Confirmation Gate」「Post-Gate 詳細」を参照。

Pre-Gate 詳細

1. Preflight

release ready gate: PR ready 条件に加え、version / tag / GitHub Release / CI artifact path を確認する。

# 必須ツール
command -v gh >/dev/null || { echo "gh CLI がありません"; exit 1; }
command -v python3 >/dev/null || { echo "python3 が必要です"; exit 1; }

# working tree
if [ -n "$(git status --porcelain)" ]; then
  echo "working tree に未コミット変更があります"; exit 1;
fi

# CHANGELOG
[ -f CHANGELOG.md ] || { echo "CHANGELOG.md がありません"; exit 1; }
grep -q "^## \[Unreleased\]" CHANGELOG.md || { echo "[Unreleased] セクションがありません"; exit 1; }

# plugin/mirror projects
scripts/release-preflight.sh

この working tree clean check は通常 release preflight の gate である。 bare release で「今までの作業」を commit したい場合は、この check の前に Review Gate と Work Commit Gate を完了させる。 未レビューの dirty tree をこの check だけで abort して終わらせてはいけない。

scripts/release-preflight.sh は tag 作成前に opencode/, skills-codex/, codex/.codex/skills/ の mirror drift も検出する。node scripts/build-opencode.js が差分を生成した場合は release を止め、その差分を commit してから tag に進む。

release preflight は host workflow smoke を REQUIRED=1（fail-closed）で全 dist host に対して実行する。1 host でも FAIL なら release を止める。これは multi-host bar H7（release-preflight consumes host gates fail-closed）の充足配線である。scripts/release-preflight-host-smoke.sh 参照。fail-closed の正本は operator マシンの preflight であり、GitHub runner（GITHUB_ACTIONS=true）では CLI 未 provision の host を明示 SKIP 行つきで飛ばす（tag-triggered workflow の再実行が全 release を塞がないため。v5.3.0 run 29679591686 の regression 対応）。

2. Version File 自動検出

VERSION → package.json → pyproject.toml（[project] / [tool.poetry]）→ Cargo.toml の優先順で探索し、最初に見つかったものを正本とする。 検出スニペット・読み取りロジックの詳細: version-files.md

3. Claude Plugin Tag Preflight

.claude-plugin/plugin.json が存在する project では、通常の GitHub Release tag とは別に Claude plugin release tag も作る。

ひとことで言うと、git tag -a を手で組み立てる前に、Claude Code 本体の plugin validation に通してから {plugin-name}--v{version} tag を作る。

Pre-Gate ではファイルを書き換えず、以下を確認する。 version sync は grep / sed で拾わず、JSON は structured parser で読む:

command -v claude >/dev/null || { echo "claude CLI がありません"; exit 1; }
claude plugin validate .claude-plugin/plugin.json

HARNESS_PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-.}"
python3 "${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py" --root .

claude plugin tag .claude-plugin --dry-run

${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py は、存在する release surface をすべて読み取り、canonical を VERSION > package.json > .claude-plugin/plugin.json > .codex-plugin/plugin.json の順で決める。 そのうえで、以下の不一致・欠落が 1 つでもあれば tag / release に進まない:

• VERSION
• package.json の .version
• .claude-plugin/plugin.json の .version
• .codex-plugin/plugin.json の .version
• .claude-plugin/marketplace.json の .metadata.version
• .claude-plugin/marketplace.json の .plugins[].version（配列内の各 plugin entry）

不一致時は、どの surface が canonical と違うか、またはどの field が missing / invalid かを表示する。 機械処理や CI で読む場合は --json を使う:

python3 "${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py" --root . --json

この check は 3 つの事故を防ぐためにある:

• VERSION と .claude-plugin/plugin.json の version がずれたまま tag を切る事故
• package.json / marketplace entry の version が古いまま release workflow に進む事故
• plugin manifest / marketplace entry の validation を通さず、あとで plugin install / update 側で詰まる事故

--dry-run では claude plugin tag が実際に作る tag 名と内部の git tag -a / push 相当コマンドが見える。ここで見えた command を Confirmation Gate の plan に含める。

4. Bump 自動推定

[Unreleased] 直下の見出し（### Breaking Changes/### Removed → major、### Added → minor、### Fixed/### Changed/### Security のみ → patch、空セクション → error）を解析して bump level を決定する。 ユーザーが /release patch|minor|major で明示指定した場合はそちらを優先。 詳細: bump-detection.md

5. CHANGELOG ドラフト作成 (メモリ上)

[Unreleased] の内容を切り出し、[<new>] - YYYY-MM-DD セクションと compare link を組み立てる（まだ書き込まない）。 詳細: release-notes.md

6. Release Notes ドラフト作成 (メモリ上)

## [<new>] セクションの内容を元に、GitHub Release 用のマークダウン（What's Changed / Before-After / Added-Changed-Fixed / フッター）を生成する。 必須要素・生成方法・検証チェックの詳細: release-notes.md

Confirmation Gate

すべてのドラフトが揃ったら、ユーザーに 1 回だけ提示:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release Plan: v<old> → v<new> (<bump>)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Version file: <detected file>
 Bump reason:  <why this level was chosen>

 CHANGELOG changes:
   [Unreleased] に <N> 項目の変更を検出
   [<new>] - YYYY-MM-DD として確定
   Compare link を追加

 GitHub Release notes preview:
   <最初の 10 行>
   ...

 Files to modify:
   - <version file>
   - CHANGELOG.md

 Final actions:
   - git commit -m "chore: release v<new>"
   - git push origin <release-branch>
   - gh pr create/update + gh pr merge into <default-branch>
   - git fetch origin <default-branch> && git checkout <default-branch>
   - claude plugin tag .claude-plugin --push --remote origin  # plugin project の場合。default branch 上で実行
   - git tag -a v<new>                                        # GitHub Release 用 semver tag が必要な場合。default branch 上で作成
   - git push origin <default-branch> --tags
   - (tag push 後は GitHub Actions release workflow が自動で release 公開)

Proceed? [yes / cancel / <修正指示>]

Post-Gate 詳細

承認後は中断なしで実行。失敗時は以下の方針:

PR / Main Merge Gate、plugin tag、Verify Publish

Post-Gate の release commit 後、tag を作る前に GitHub PR を default branch へ merge する（gh pr create → gh pr merge --merge → default branch fetch/checkout で release commit の到達可能性を確認）。release branch 上だけに存在する commit を指す tag で GitHub Release を作ってはいけない。 .claude-plugin/plugin.json がある project では、merge 後に default branch 上で version sync を再確認してから claude plugin tag .claude-plugin --push --remote origin で plugin tag（{plugin-name}--v{version} 形式）を作る。 tag push 後は bash scripts/release-verify-publish.sh で .github/workflows/release.yml の公開結果を verify する（5 秒間隔 × 60 回 polling、exit 0=PASS / 2=WARN(timeout) / 3=ERROR）。 コマンド全文・失敗時の判断基準は post-gate-detail.md を参照。

--dry-run モード

Pre-Gate 全てを実行し、Confirmation Gate までの内容を表示するが、gate で止まり Post-Gate に進まない。

Claude plugin project の場合、dry-run でも python3 "${HARNESS_PLUGIN_ROOT}/scripts/check-release-version-sync.py" --root . と claude plugin tag .claude-plugin --dry-run を実行し、実際に作られる plugin tag 名と push 対象を表示する。ここで VERSION / package.json / .claude-plugin/plugin.json / .codex-plugin/plugin.json / .claude-plugin/marketplace.json の version surface が不一致または欠落していれば、dry-run の時点で止める。

環境変数

プロジェクトごとの調整に使用:

CHANGELOG 書き方ルール

[Unreleased] セクションは KaCL 標準サブセクション（### Added=minor / ### Changed・### Fixed・### Security=patch / ### Deprecated=minor / ### Removed・### Breaking Changes=major）のいずれかを持つ必要がある。 このスキルはこれらの見出しを機械的に解析するため、表記揺れ（### Fix / ### Bug Fixes 等）は認識できない。

GitHub Release notes の必須フォーマット・CHANGELOG の「今まで/今後」記法・merge 方式（squash 不採用）の詳細は github-release.md を参照。 SemVer 判定基準・バッチリリース方針・Release Train Proposal の詳細は versioning.md を参照。

出荷前の受け入れ判断（非エンジニア向け）

リリース確定の前に harness-accept を提案する。各合格条件が満たされたかと ship/wait/reject の 推奨を 1 枚の HTML にまとめた「受け入れ判断」画面で、発注者が専門知識なしで出荷可否を判断できる。

関連スキル

• harness-release-internal - 本体 claude-code-harness のリリース時に追加で走らせる harness 固有 preflight/finalization（配布対象外）
• harness-plan - Plans.md 管理
• harness-review - リリース前のコードレビュー
• harness-accept - 受け入れ判断 HTML（非エンジニア向け、リリース前に提案）

設計思想

• PR ready / release ready 分離: PR ready は review + evidence pack。release ready は version/tag/GitHub Release/CI まで。lane:fast / lane:gate は PR ready で止めてよい
• 単一ゲート: ユーザーの判断タイミングは 1 回だけ。mini-confirmation を挟むとラバースタンプ化して意味を失う
• 事前に全て描く: Post-Gate に入ってからの「考え直し」を禁ずる。Gate 前に全 draft を揃える
• main 反映が完了条件: release tag / GitHub Release は default branch 反映後にだけ作る。branch-only release は未完了として扱う
• 失敗は transparent: 途中で失敗したら自動ロールバックは試みず、ユーザーに現状を提示して判断させる
• プロジェクト非依存: VERSION file 形式、mirror、residue check など特定環境の前提を持たない。本体 harness 固有の処理は harness-release-internal に分離