/harness-release

name: harness-release
description: "Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup."
description-en: "Generic release automation for projects using Keep a Changelog + GitHub. Single confirmation gate then end-to-end automation: bump detection, CHANGELOG promotion, PR/main merge, tag, GitHub Release. Trigger: release, version bump, publish. Do NOT load for: implementation, review, planning, setup."
description-ja: "汎用リリース自動化スキル。Keep a Changelog と GitHub を使うあらゆるプロジェクトで動作。単一確認ゲートで bump 判定・CHANGELOG 昇格・PR/main 反映・タグ・GitHub Release まで全自動実行する。リリース、バージョンバンプ、タグ作成、公開で起動。実装・コードレビュー・プランニング・セットアップには使わない。"
kind: workflow
purpose: "Release projects through changelog, version, PR/main merge, tag, and GitHub Release gates"
trigger: "release, version bump, publish"
shape: workflow
role: orchestrator
pair: harness-review
owner: harness-core
since: "2026-05-05"
allowed-tools: ["Read", "Write", "Edit", "Bash", "AskUserQuestion", "Skill"]
argument-hint: "[patch|minor|major|--dry-run]"
context: fork
effort: high
user-invocable: true

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 を混同しない。

| Gate | 意味 | 必須条件 | 停止 lane | |------|------|----------|-----------| | **PR ready** | ブランチが review 可能で merge 判断できる | `harness-review` `APPROVE`、focused tests PASS、evidence pack 完備（accepted/rejected findings、tests、release-preflight warnings 処理、residual risk） | `[lane:fast]` / `[lane:gate]` はここで停止可 | | **release ready** | 公開配布 path が preflight を通過 | PR ready 条件 + version surface sync + tag + GitHub Release + CI/public artifact 検証 | `[lane:release]` のみ |

• 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>`

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

<!-- 上記ブロックは AUTO-START CONTRACT。skill-editing.md「最冒頭 3 行以内」ルール準拠。patterns.md P27 解法 3 点セット (機械可読条件 + 禁止行動 literal + AUTOSTART marker) -->

自主停止の禁止 (140.3、2026-08-22 の release run で 2 回発生した停止パターンの再発防止)

以下は禁止行動。literal に列挙する (AUTOSTART pattern と同じ方式):

• background 待ちで turn を終えて停止しない (turn を終えると background 子プロセスは残らない)
• 「検証を待ちます」「確認します」「完了を待機します」で turn を終えない
• 待つなら同期実行 (foreground / Monitor) で待ち切る。待てないものは保留として報告し、次のタスクへ進む

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

`<local-command-stdout>` で host へ結果を中継する場合だけ、output の **最後の 1 行**に次の literal を含める:

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

これは `<local-command-stdout>` 経由で text response として表示されると user が「止まった」と感じる UX 問題への明示的な instruction (patterns.md P35)。 host の最終回答は実行済み操作、公開の検証結果、残る gate を返す。要約や検証の予告だけで終了しない。

`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: "中止"
    descri