harness-release

# 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 を公開している状態を完了とする。

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

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

### 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** を実行する。

1. `git status --porcelain` と `git log @{upstream}..HEAD` / `main..HEAD` を確認し、「今までの作業」の対象を特定する
2. `.claude/state/review-result.json` と `.claude/state/review-approved.json` を確認し、対象 work に `APPROVE` 済み review があるか確認する
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 を出す。

```text
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 を先に作る。

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

```bash
/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](https://keepachangelog.com/) 形式
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 only: 作業 review/commit 前段]
  ↓
  0. Review Gate (未レビューなら AskUserQuestion → harness-review)
  0.5 Work Commit Gate (review APPROVE 済み work を release bump と分けて commit)
  ↓
[Pre-Gate: 情報収集のみ、ファイル未変更]
  ↓
  1. Preflight (working tree clean / CHANGELOG / gh 等の確認)
  2. Version file 自動検出
  3. 現在バージョンの読み取り
  4. Claude plugin tag preflight (plugin project の場合のみ)
  5. [Unreleased] 内容の解析 → bump level 推定
  6. 新バージョン算出
  7. CHANGELOG 差分ドラフト作成 (メモリ上)
  8. GitHub Release notes ドラフト作成 (メモリ上)

★━━━━━━ 単一確認ゲート ━━━━━━★
  ユーザーに全計画を 1 回だけ提示:
    - 検出された version file
    - 現バージョン → 新バージョン
    - bump 判定理由 ("[Unreleased] に ### Added があるため minor" 等)
    - CHANGELOG 変更プレビュー
    - GitHub Release notes ドラフト
    - コミット対象ファイル一覧
    - 最終アクション (branch push + PR merge + tag + release publish)

  ユーザー応答:
    "yes"        → Post-Gate へ進む
    "<修正指示>"  → 指示に応じて draft を再生成、再確認
    "cancel/no"  → 何もせず終了
★━━━━━━━━━━━━━━━━━━━━━