フェーズ 7: リリース

目的

検証済みのコードを安全にリリースする。コミットメッセージの品質、PR の記述、マージ戦略、デプロイ手順を体系化し、リリースに伴うリスクを最小化する。

開始条件

• docs/workflow/review-report.md に承認があり、最新の検証証拠が成功している
• デプロイ権限、監視方法、ロールバック手順を確認できる

入力成果物

• 承認済みの差分
• docs/workflow/test-evidence.md
• docs/workflow/review-report.md
• リリース、監視、ロールバックの手順

実行手順

1. リリース対象と承認済みの変更版が一致することを確認する
2. 変更概要、検証、既知の問題、ロールバックを記録する
3. プロジェクト手順に従ってマージまたはデプロイする
4. 健全性を確認し、結果とロールバック状態を記録する

期待成果物

• マージ済みまたはデプロイ済みの成果物
• docs/workflow/release-record.md

終了条件

• 承認済み成果物をリリースし、健全性を確認している
• 変更内容・検証結果・ロールバック状態を振り返りへ渡せる

失敗時の戻り先

• 健全性確認の失敗はロールバックへ戻り、結果を記録する
• コード修正は実装へ戻し、検証とレビューを再度通過する
• 承認と対象差分が一致しない場合はレビューへ戻る

Before / After

Before: 従来のやり方

• 適当なコミットメッセージで push
• PR の説明が空か「修正」だけ
• マージ前にテストが通っているか確認不足
• デプロイ手順が属人化

After: ツール活用後

• 構造化されたコミットメッセージとトレーラー
• 包括的な PR 説明（変更概要、テスト計画、チェックリスト）
• マージ前に全品質ゲートが通過していることを確認
• CI/CD パイプラインとの連携

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

検証: docs/workflow/test-evidence.md
承認: docs/workflow/review-report.md
方法: draft PR を作成して CI を確認する。

コマンド / プロンプト

claude

検証と承認が現在の差分を対象にしているか確認してください。
変更概要、検証、既知の問題、ロールバックを
docs/workflow/release-record.md にまとめてください。まだリリースは実行しないでください。

git diff --check
gh pr create --draft --title "docs: workflow gatesを整備" --body-file docs/workflow/release-record.md
gh pr checks --watch

生成物例

# リリース記録
## 変更
工程ゲートと表示順を統一。
## 検証
docs/workflow/test-evidence.md を参照。
## ロールバック
対象 PR を revert して再確認する。

検証

gh pr view --json isDraft,title,body
gh pr checks

出口判定

• PR と CI が対象差分を指し、必須チェックが成功した
• 健全性とロールバック状態を記録して振り返りへ渡せる

Claude Code の基本コマンドでリリース作業。

# コミット
Claude Code > 変更をコミットして
# 自動的に適切なコミットメッセージを生成

# ブランチ操作
Claude Code > feature/auth ブランチを作成して

# PR 作成
Claude Code > PR を作成して。変更内容をまとめて
# gh pr create を使用

# GitHub Actions の確認
Claude Code > CI の状況を確認して

手順:

1. 変更内容を確認（git diff）
2. 適切なファイルをステージング（git add）
3. 構造化されたコミットメッセージでコミット
4. gh pr create で PR を作成
5. CI の結果を確認

Intermediate

Superpowers の finishing-a-development-branch と OMC の git-master エージェントを活用。

# Superpowers: finishing-a-development-branch
# 実装完了後の構造化された選択肢提示:
# Option 1: ローカルでマージ
# Option 2: Push & PR 作成
# Option 3: そのまま保持
# Option 4: 破棄（"discard" のタイプ確認付き）
# テスト通過を確認してから選択肢を提示

# OMC: git-master エージェント
> コミット戦略を提案して
# コミット履歴の整理性を管理

# OMC: release スキル
/oh-my-claudecode:release
# バージョン bump と CHANGELOG の自動生成

# Claude Code: GitHub Actions 連携
# anthropics/claude-code-action@v1
# PR コメントで @claude とメンションしてレビュー依頼

手順:

1. Superpowers finishing-a-development-branch でテスト通過を確認
2. 提示された選択肢からリリース方法を選択
3. OMC git-master でコミット戦略を最適化
4. PR を作成し、CI を確認
5. OMC release でバージョン管理

Advanced

OMC のコンテキストトレーラーと ECC のデプロイパターンで、本格的なリリースパイプラインを構築。

# OMC: コミットトレーラー
# Constraint: この変更の制約
# Rejected: 却下したアプローチと理由
# Directive: 遵守すべき指示
# Confidence: 変更の信頼度
# Scope-risk: 影響範囲のリスク
# Not-tested: テストされていない部分
# → 決定のコンテキストを保存

# ECC: deployment-patterns スキル
# CI/CD、Docker、ヘルスチェック、ロールバック
/deployment-patterns

# ECC: docker-patterns スキル
# Docker Compose、ネットワーク、ボリューム、コンテナセキュリティ

# Claude Code: リモート実行
claude --remote "リリース作業を実行"
# クラウドで実行。ローカルで並行作業可能

# GitHub Actions での自動化
# anthropics/claude-code-action@v1
# PR open/sync で自動レビュー
# @claude でコメントトリガー

手順:

1. OMC コミットトレーラーで決定のコンテキストを記録
2. ECC deployment-patterns でデプロイ戦略を策定
3. GitHub Actions で CI/CD パイプラインを構成
4. claude --remote でリリース作業をクラウドで実行
5. claude --teleport で必要に応じてセッションを移行

ベストプラクティス

1. マージ前に必ずテストを実行 -- Superpowers finishing-a-development-branch はテスト通過を確認してから選択肢を提示する。テストが通っていないのにマージしない
2. コミットメッセージは構造化 -- feat:, fix:, refactor: 等のプレフィックスを使用。OMC コミットトレーラーで決定のコンテキストを保存
3. PR の説明は包括的に -- 変更概要、影響範囲、テスト計画、チェックリストを含める。Claude Code は gh pr create でこれを自動生成
4. CI/CD を活用 -- GitHub Actions でテスト・Lint・ビルドを自動化。PR 作成時に自動実行
5. リリース通知を設定 -- OMC configure-notifications で、リリース完了を Telegram/Discord/Slack に通知

よくある罠

マージ前の品質確認不足

PR を作成しただけで、CI が通るのを待たずにマージする。CI が失敗している可能性がある。必ず CI の結果を確認してからマージ。

コミットメッセージの不備

「修正」「WIP」などの不十分なコミットメッセージは、後からの変更追跡を困難にする。構造化されたメッセージを心がける。

リリース後のロールバック計画なし

デプロイ後に問題が発生した場合のロールバック手順を用意していない。ECC deployment-patterns のロールバック戦略を参照。

リモートセッションの管理不足

claude --remote で実行したセッションの状況を確認しない。/tasks でセッション一覧を確認し、必要に応じて --teleport で移行する。

リリースノートの未作成

利用者への変更通知なしにリリースする。OMC release で CHANGELOG を自動生成し、OMC configure-notifications で通知を送信する。