# Release Checklist

> KonomiTV のリリース前チェックリストと手順ガイド。リリースを打つ前にユーザーと一緒に確認事項を順番に潰していくためのスキル。リリース前の準備やリリース手順を確認したいときに使う

- Skill: `tsukumijima/release-checklist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tsukumijima/release-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tsukumijima/release-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tsukumijima (https://skillmd.com/u/tsukumijima)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tsukumijima/release-checklist

---


KonomiTV の新バージョンをリリースする前に、ユーザーと一緒に確認事項を潰していくためのチェックリスト。
リリース頻度が数ヶ月おきのため手順を忘れがちなので、このスキルで毎回漏れなく進められるようにする。

## リリースフローの全体像

```
[手動] リリース前の確認・準備 (このスキルのスコープ)
  ↓
[手動] Dockerfile のリリース準備コミット
  ↓
[手動] GitHub Actions「Create Release Commit」を workflow_dispatch で実行
  ↓ (以降は自動)
[自動] バージョン番号の一括更新・クライアントビルド・Release コミット作成
[自動] release ブランチ更新 → インストーラー & サードパーティビルド
[自動] タグ作成 → GitHub Release 作成 (generateReleaseNotes: true)
[自動] Docker イメージのビルド & 公開
  ↓
[手動] GitHub Release のリリースノートを編集 (generate-release-notes スキルの出力をマージ)
```

## チェックリスト

以下のチェック項目を上から順にユーザーと確認していく。
エージェントが自動で確認できる項目はエージェントが実行し、ユーザーへの確認が必要な項目はユーザーに質問する。

### Phase 1: コードの最終確認

- [ ] **master ブランチが最新か**
  - `git status` と `git log --oneline -5` で確認する
  - 未 push のコミットがないか、意図しない変更が残っていないか
- [ ] **クライアントの lint / 型チェックが通るか**
  - `client/` で `yarn lint` と `yarn typecheck` を実行する
  - クライアントのビルド自体は Create Release Commit ワークフロー内で自動実行されるため、手元での `yarn build` は不要
- [ ] **サーバー側の lint / 型チェックが通るか**
  - `server/` で `poetry run task lint` を実行する

### Phase 2: サードパーティライブラリの確認

- [ ] **サードパーティライブラリのバージョンが最新か**
  - `.github/workflows/build_thirdparty.yaml` に定義されている各ライブラリのバージョンを確認する
  - 特に QSVEncC / NVEncC / VCEEncC / FFmpeg / rkmppenc は頻繁に更新されるので、`gh release list` で各リポジトリの最新リリースを取得し、現在のバージョンと比較する
    - `gh release list --repo rigaya/QSVEnc --limit 1`
    - `gh release list --repo rigaya/NVEnc --limit 1`
    - `gh release list --repo rigaya/VCEEnc --limit 1`
    - `gh release list --repo rigaya/rkmppenc --limit 1`
    - FFmpeg は BtbN/FFmpeg-Builds のリリースを確認する
  - 差分がある場合は「現在 X.XX、最新 X.XX」のように比較結果をユーザーに報告し、更新するか判断を仰ぐ
  - 更新が必要な場合は、ユーザーが `build_thirdparty.yaml` のバージョンを更新してコミットする
- [ ] **開発版 Dockerfile の thirdparty URL が最新の CI ランの成果物を指しているか**
  - `Dockerfile` 内の `nightly.link` URL の `actions/runs/XXXXXXX` が、最新の build_thirdparty ワークフロー実行の run ID と一致しているか確認する
  - サードパーティライブラリのバージョンを更新した場合、CI が完了した後にこの URL も更新する必要がある

### Phase 3: Dockerfile のリリース準備

- [ ] **Dockerfile を「リリース版用」に切り替える**
  - 以下の変更を行い、`Update: [Dockerfile] リリース準備` としてコミットする
  - **ただし、この時点ではまだ push しない。** リリース版 URL のバージョン番号は Create Release Commit ワークフローが自動で更新するため、前回リリースのバージョン番号のままで構わない

  変更内容:
  ```
  # 「リリース版用」の行のコメントを外す
  RUN aria2c -x10 https://github.com/tsukumijima/KonomiTV/releases/download/v(前回バージョン)/thirdparty-linux.tar.xz
  RUN tar xvf thirdparty-linux.tar.xz

  # 「開発版用」の行をコメントアウトする
  # RUN aria2c -x10 https://nightly.link/tsukumijima/KonomiTV/actions/runs/XXXXXXX/thirdparty-linux.tar.xz.zip
  # RUN unzip thirdparty-linux.tar.xz.zip && tar xvf thirdparty-linux.tar.xz
  ```

### Phase 4: リリースノートの下書き生成

- [ ] **generate-release-notes スキルを実行して下書きを生成する**
  - `/tmp/konomi-tv-release-notes-draft.md` に出力される
  - ユーザーがこの下書きをベースに加筆修正し、最終版を用意する
  - リリースノートの最終版は GitHub Release 作成後に編集画面で反映する

### Phase 5: リリースの実行

- [ ] **Dockerfile のリリース準備コミットを push する**
  - Phase 3 で作成したコミットを `git push` する
- [ ] **GitHub Actions「Create Release Commit」を実行する**
  - ユーザーに依頼: GitHub の Actions タブから `Create Release Commit` ワークフローを手動実行してもらう
  - バージョン番号を入力する (例: `0.14.0`、`v` は付けない)
  - このワークフローが以下を自動で行う:
    - 各ファイルのバージョン番号を一括更新
    - クライアントのビルド
    - `Release: version X.X.X` コミットの作成と push
    - `release` ブランチの更新
- [ ] **Publish Release ワークフローの完了を待つ**
  - release ブランチの更新をトリガーに、インストーラー・サードパーティライブラリのビルドとリリース作成が自動実行される
  - 完了まで30分〜1時間程度かかる

### Phase 6: リリース後の作業

- [ ] **GitHub Release のリリースノートを編集する**
  - GitHub が `generateReleaseNotes: true` で自動生成した内容 (Dependabot PR 一覧・外部 PR 一覧・New Contributors) に、Phase 4 で準備した下書きをマージする
  - スクリーンショットや動画の追加、文面の最終調整を行う
- [ ] **Docker イメージが正常に公開されたか確認する**
  - `Publish Docker Image` ワークフローの実行結果を確認する
- [ ] **Dockerfile を「開発版用」に戻す**
  - Phase 3 の逆の変更を行う
  - thirdparty の nightly.link URL は最新リリースの build_thirdparty ワークフローの run ID に更新する
  - `Update: [Dockerfile] 開発版用サードパーティーライブラリを更新` としてコミット & push する
- [ ] **リリースの告知**
  - ユーザーに確認:「Twitter (X) での告知は行いますか？」

## エージェントが自動実行できる項目

以下はエージェントが自律的に実行してよい項目:

- `git status` / `git log` による状態確認
- `yarn lint` / `yarn typecheck` によるクライアント側 lint / 型チェック確認
- `poetry run task lint` によるサーバー側 lint 確認
- Dockerfile の diff 確認
- `.github/workflows/build_thirdparty.yaml` のバージョン確認
- `gh release list` で各サードパーティライブラリの最新バージョンとの比較

## エージェントがユーザーに確認すべき項目

以下は必ずユーザーの判断・操作が必要:

- サードパーティライブラリの更新判断
- GitHub Actions ワークフローの手動実行
- リリースノートの最終承認
- リリース告知の判断