Skills Guide

Release Management

End-to-end release execution for the Dayopt project. Triggered only by explicit release intent. Automatically determines git state and starts from appropriate phase.

Sby Skills Guide Bot
DevOpsAdvanced
007/24/2026
Claude CodeCursorWindsurfCopilotCodex
#release-management#version-bumping#git-tagging#github-release#devops

Recommended for

Claude CodeBackend developerCursorCopilotDevOps engineerWindsurf

name: releasing description: Dayopt の release 作業を end-to-end で実行する時に発動。明示的な release 意図（「v0.X.0 をリリース」「リリースしたい」「タグを切る」）を契機に、現在の git state（feature branch / main / tag 状態）を自動判定し、適切な Phase（version bump → 品質チェック → PR merge → tag → GitHub Release → リリースノート）から開始する。明示的な release 意図がない限り他のトリガーでは発動しない。 effort: high maxTurns: 25

Releasing Skill

Dayoptプロジェクトのリリース作業を安全かつ確実に実行するためのスキルです。

When to Use

明示発動型 — この skill はユーザーの explicit な release 意図のみを契機に発動する（コード変化や他 skill からの handoff では発動しない）。

  • 「v{n}.{n}.{n} をリリースしたい」「リリース作業を進める」等、明確な release 意図が発話された時
  • tag 作成（git tag v...）や GitHub Release 作成を明示的に指示された時
  • package.json の version フィールドを bump する作業を指示された時
  • 既存タグに対応する GitHub Release / リリースノートを更新・作成する指示時

When NOT to Use

この skill は explicit release 意図のみを契機とする。暗黙的な invocation ケースは該当なし（型の穴埋めとして明記）。参考として近接するが発動しないケース:

  • 単なる main への merge（tag / release を伴わない）→ 通常の git 操作
  • commit 作成のみで version bump を含まない時 → 通常の development flow
  • Breaking change を含む変更が release 作業と分離されている時 → docs-writing skill で ADR / 技術ドキュメント更新を先行

状態自動判定

スキル起動時、まず現在の状態を判定して適切なフェーズから開始する：

ユーザー: 「v0.17.0リリースしたい」
│
├─ featureブランチにいる？（PRがオープン）
│  └─ Phase 0 から: version bump → 品質チェック → PRマージを促す → タグ → リリースノート
│
├─ mainにいてタグがまだ？
│  └─ Phase 1 から: promote 完了確認 → 観察 → タグ作成・push → リリースノート
│     （Production Release status が success になるまでタグを打たない）
│
├─ タグはあるがReleaseがまだ？
│  └─ Phase 2 から: GitHub Actions確認 → リリースノート
│
└─ タグもReleaseも既にある？
   └─ Phase 3 から: リリースノート上書きのみ

判定コマンド

# 1. 現在のブランチを確認
git branch --show-current

# 2. タグの存在確認
git tag -l "v${VERSION}"

# 3. GitHub Releaseの存在確認
gh release view v${VERSION} 2>/dev/null && echo "exists" || echo "not found"

# 4. package.json の現在バージョン
node -p "require('./package.json').version"

リリースワークフロー

Phase 0: 準備（featureブランチにいる場合）
  ├── 0.1 バージョン番号決定・重複チェック ← 最重要
  ├── 0.2 package.json バージョン更新（このPRに含める）
  └── 0.3 コード品質確認（lint, typecheck, test, build）
  → ユーザーにPRマージを促す

Phase 1: Production公開の確認とタグ作成（mainブランチ）
  ├── 1.1 mainブランチ最新取得
  ├── 1.2 Production Release の promote 完了を待つ
  ├── 1.3 Production を観察する（主要route / Sentry）
  ├── 1.4 Gitタグ作成・プッシュ（promote成功の証跡）
  └── 1.5 GitHub Release作成の確認（auto-generated notes）

Phase 2: リリースノート反映
  ├── 2.1 前回リリース以降の全PRを取得
  ├── 2.2 詳細なリリースノートを作成
  └── 2.3 gh release edit で GitHub Release に反映

Phase 3: リリース後作業
  ├── 3.1 デプロイ確認
  └── 3.2 Sentry監視

必須チェック項目

Phase 0.1: バージョン重複チェック（スキップ厳禁）

# 1. 既存リリースを確認
gh release list

# 2. 重複チェック
VERSION="0.X.0"  # リリースするバージョン
gh release view v${VERSION} 2>/dev/null && echo "❌ Already exists!" || echo "✅ OK"

重複が見つかった場合: 必ず「v0.X.0ではなくv0.Y.0じゃないですか？」と確認する

Phase 0.2: package.json バージョン更新

# 現在のPRブランチでバージョンを更新
npm version ${VERSION} --no-git-tag-version
# → コミットに含める（タグ打ち前にmainのpackage.jsonが正しい状態になる）

ポイント: リリース前の最後のPRにversion bumpを含めることで、タグ打ち後の後片付けがゼロになる。

Phase 0.3: コード品質

pnpm lint && pnpm typecheck && pnpm test:run && pnpm build

Phase 1.1: mainブランチ最新取得

git checkout main
git pull origin main

Phase 1.2: Production promote の完了を待つ

main への merge は Product / Web の Production build を作るだけで、Production domain は切り替わらない。Production Release workflow が同一 SHA の両 candidate を smoke・監査してから promote する。

# promote の実行状況を確認
gh run list --workflow=release.yml --limit 1
gh run watch --exit-status

# 対象 SHA が Production に出たことを確認
gh api "repos/Dayopt/dayopt/commits/$(git rev-parse HEAD)/status" \
  --jq '.statuses[] | select(.context == "Production Release") | .state'

success にならないうちはタグを打たない。失敗時は docs/operations/runbook.md の Playbook 2 に従う。

Phase 1.3: Production を観察する

promote 直後に主要 route と監視を確認する。異常があればタグを打たず、runbook の rollback 手順へ移る。

curl -s -o /dev/null -w "%{http_code}\n" https://dayopt.app/
curl -s -o /dev/null -w "%{http_code}\n" https://app.dayopt.app/api/health

Sentry の新規 issue と Vercel の runtime log も確認する。

Phase 1.4: Gitタグ作成・プッシュ

観察まで終わってからタグを打つ。タグは deploy trigger ではなく、Production 公開が成功した証跡である。

git tag v${VERSION}
git push origin v${VERSION}

create-release.yml はタグ SHA の Production Release status が success であることを確認してから GitHub Release を作成する。未 promote の SHA にタグを打つと、この検証で止まる。

Phase 1.5: Release 作成の確認

gh run list --workflow=create-release.yml --limit 1
gh release view v${VERSION}

Phase 2: リリースノート反映（詳細化必須）

Step 1: PRとコミット情報を取得

# 前回リリース以降の全PRを取得
gh pr list --state merged --base main --limit 100 --json number,title,mergedAt

# 各PRのコミット詳細を取得（重要：PRタイトルだけでは不十分）
for pr in <PR番号リスト>; do
  echo "=== PR #$pr ==="
  gh pr view $pr --json title,body --jq '.title + "\n" + .body'
  echo "--- Commits ---"
  gh pr view $pr --json commits --jq '.commits[].messageHeadline'
done

Step 2: 詳細なリリースノートを作成

粒度の基準: 第三者が見ても「何が変わったか」がわかるレベル

構造テンプレート: docs/operations/runbook.md を参照

❌ 悪い例（抽象的）:

- タグ機能リファクタリング
- パフォーマンス改善

✅ 良い例（具体的）:

#### タグ機能の大幅強化 ([#910])

**データモデル変更**

- タグの親子階層モデルへ移行（`tag_groups` テーブル → `parent_id` カラム）
- 子タグの昇格処理を含むタグマージ機能

**UI/UX改善**

- タグ作成モーダルをポータルで実装（モーダル内でも正常動作）
- カレンダーサイドバーでのタグドラッグ&ドロップ並び替え
- 未タグ付けフィルターにアイコンと件数表示

**楽観的更新**

- タグ作成・編集・削除・マージ・並び替えに楽観的更新を実装

Step 3: 必須セクション

カテゴリは docs/operations/runbook.md 第4部「リリースノート執筆規約」の5分類に従う（Web版リリースノート docs-writing skill とも共通のタクソノミー。ここでは再定義しない）:

  1. 新機能: 機能名 + 具体的な実装内容
  2. 改善: 何がどう変わったか + 影響範囲（パフォーマンス最適化を含む）
  3. バグ修正: 問題の原因 + 修正内容
  4. 破壊的変更: DB変更、削除されたAPI/コンポーネント
  5. セキュリティ: セキュリティ関連の対応

Step 4: GitHub Release に反映

# 一時ファイルにリリースノートを書き出してから反映
gh release edit v${VERSION} --notes-file /tmp/release-notes-v${VERSION}.md

Step 5: Web 公開リリースノート

エンドユーザー向けの Web 版リリースノートは、docs-writing skill で apps/web/content/blog/{en,ja}/ に category: 'release' の blog 記事として作成する（/blog/release タブに表示。独立した releases ページは持たない）。GitHub Release 本文と同じ5分類タクソノミーを使い、PR リンクを含めず平易な言葉で書く。

チェックリスト

  • [ ] 各PRのコミットを確認した
  • [ ] 抽象的な記述を具体化した
  • [ ] データモデル変更を明記した
  • [ ] 削除されたコンポーネント/機能をリストした
  • [ ] Full Changelogリンクがある

Phase 3: リリース後作業

# デプロイ確認
# Vercel Dashboard で本番環境の動作確認

# Sentryでエラー監視
# エラーが急増していないことを確認

よくある失敗

| 失敗 | 対策 | | ---------------------- | ---------------------------------------------- | | バージョン重複 | Phase 0.1で必ず gh release view | | リリースノートが抽象的 | 各PRのコミットを取得して具体的な変更内容を記載 | | 破壊的変更の記載漏れ | DB変更、削除コンポーネントを明記 | | 一部PRのみ記載 | gh pr list --state merged で全件取得 | | Full Changelog抜け | template.mdの構造を参考にする | | version bump忘れ | Phase 0.2でPRに含める（タグ前に完了） |

スクリプト

バージョン重複チェック

.claude/skills/releasing/scripts/check-version.sh 0.X.0

マージ済みPR取得

.claude/skills/releasing/scripts/get-merged-prs.sh

詳細ドキュメント

完全なチェックリスト: docs/operations/runbook.md

Related skills

Docker Compose Architect

DevOps

Designs optimized Docker Compose configurations.

Claude CodeCopilotadvanced
430
156
1,660
Admin

Incident Postmortem Writer

DevOps

Writes structured and blameless incident postmortem reports.

claudeCursorWindsurfintermediate
141
43
575
Admin

Runbook Creator

DevOps

Creates clear operational runbooks for common DevOps procedures.

claudeCursorWindsurfintermediate
108
32
508
Admin