---

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