mcpField
R
release-checklist

release-checklist

github.com/donchitosテスト・品質28.5k480 回インストール1 週間前に更新
リポジトリ

release-checklist について

release-checklist は、プロジェクトに合わせたリリースチェックリストを作成する Claude スキルです。プロジェクト段階、厳密さ、認証ティアに基づいて項目を選び、未評価のコードスキャンやテスト証拠も明示します。

主な機能

  1. 01範囲を絞ったリリースチェックリストの作成
  2. 02デバイス要件と認証要件の分離
  3. 03ソースファイル内の TODO、FIXME、HACK の検索
  4. 04バグ記録と利用可能なテスト結果の確認
  5. 05承認後のチェックリスト保存

活用シーン

  1. 01プロジェクト段階に応じたリリース確認の準備
  2. 02認証チェックを設定済みティアに限定
  3. 03コード上の問題と不足するテスト証拠の把握

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/donchitos/claude-code-game-studios --skill release-checklist

インストール後、Claude Code で/release-checklistを入力して読み込まれたか確認します。

詳細

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys rigor,workflow,project.stage,cert_tier,automation

自動化モード:modes.automation を解決します(project.local.yaml → project.yaml → デフォルトの collaborative)。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは、.claude/docs/automation-modes.md に従います (collaborative は常に確認 · guided は重大な項目のみ · autonomous は記録して続行; automation_always_ask カテゴリは常に確認)。

上で解決済みです。そのまま使用してください。ブロックがない場合 → .claude/docs/config-resolution.md のデフォルトを使用します。

リリースチェックリスト

このチェックリストの範囲をプロジェクトに合わせてください。 すべてのプラットフォーム向けの項目をすべて列挙すると、読者はリストを読み飛ばすようになり、チェックリストの役割を損ないます。

  • project.stage — プロジェクトがまだ到達していないフェーズの項目は対象外です。未チェックのまま列挙するのではなく、その旨を明記してください。

  • modes.rigor — minimal の場合、このプロジェクトが採用しないことを選んだプロセス上の負荷だけを根拠とする項目は削除してください。

  • platform.cert_tier — 認定項目は、プロジェクトが対象とするティアのものだけを出力してください。値が未設定の場合は、すべての認定トラックを出力するのではなく、対象プラットフォームを確認してください。未設定は質問すべき状態であり、すべての認定トラックを出力してよいという意味ではありません。判定できない場合は、セクションに NOT ASSESSED — cert tier unknown と記載してください。未設定は none ではありません。 none は決定済み、未設定は未決定であり、同じ出力にしてはいけません。このキーが取りうる4つの値 — none | itch | steam | console — に基づいて分岐し、プラットフォーム名では分岐しないでください。要件の全表は .claude/docs/effects-map.md の ## platform.cert_tier セクションです。そのセクションだけを読み取ってください(見出しを Grep し、その後、範囲を限定して Read します)。ファイル全体は実行時入力ではありません。

    • none — 認定セクションは一切出力しないでください。 社内リリース、アルファ版、またはゲームジャム向けゲームです。セクションを省略した理由を明記してください。空欄のまま残してはいけません。
    • itch — itch.io へのアップロード要件のみ:ビルドサイズ、ページ設定、年齢タグ。コンソールおよび Steamworks の項目は含めません。
    • steam — Steamworks:ストアページ、デポビルド、実績、システム要件、共通コンテンツルール。コンソール認定項目は含めません。
    • console — プラットフォームの完全な認定要件(TRC / XR / Lotcheck)、セーブデータのルール、コントローラーマッピングのルール、年齢評価機関。最も負荷の高いティアです。

    プラットフォーム名ではなく、上記の cert_tier の値に基づいて分岐してください。 対象プラットフォームで判定すると、itch のプロジェクトと steam のプロジェクトを同一視し、none と未設定を混同し、cert_tier の値ではない mobile をキーにしてしまいます。設定で定義された語彙を使用してください。

設定がないために項目の範囲を決められない場合は、NOT ASSESSED — platform/stage unknown と記載してください。黙って含めないでください。そうしないと、たとえば rigor: standard の単一プラットフォームのプロジェクトに、PC およびコンソール およびモバイルの認定と年齢評価を要求する約150項目のチェックリストが生成され、そのうち約140項目が評価不能になってしまいます。


フェーズ 1:引数を解析する

対象プラットフォームの引数(pc、console、mobile、または all)を読み取ります。プラットフォームが指定されていない場合は、デフォルトで all を使用します。

引数が選択するのはデバイス要件です。認定トラックを選択することはありません。 認定は、このスキルの先頭にある解決済み設定ブロックで解決された platform.cert_tier によって決まります。 上記の platform.cert_tier のルールを参照してください。この2つの軸は別々のリストですが、たまたま1つの単語を共有しています。pc/console/mobile はハードウェアの形状であり、none|itch|steam|console は認定制度です。両者が一致するのは console だけです。それ以外では一致しません。itch と none にはデバイスブロックがなく、mobile は cert_tier の値ではありません。したがって、デバイスブロックを出力しても、どの認定ブロックを出力するかは決まりません。また、all はすべての認定トラックを出力してよいという意味ではありません。


フェーズ 2:プロジェクトのコンテキストを読み込む

  • プロジェクトのコンテキスト、バージョン情報、対象プラットフォームを把握するため、CLAUDE.md を読みます。
  • このリリースに含めるべき機能とコンテンツを把握するため、production/milestones/ から現在のマイルストーンを読みます。
  • production/qa/bugs/ から未解決のバグを読み取ります。/bug-triage と同様に、production/qa/bugs/*.md の **Severity** と **Status** の行を grep します。Status が Closed または Verified Fixed でないバグは未解決です。バグ項目には、解決済みの workflow に /gate-check release が適用するしきい値を使用します。full では、未解決の S1、S2、S3 バグがあるとその項目は不合格になります。standard と minimal では、未解決の S1 のみが不合格となり、未解決の S2 または S3 はリスクとして Rationale に記載されます。不合格となる各バグは、ブロッキング項目として Rationale に記載されます。production/qa/bugs/ にバグファイルがない場合 → バグ項目は NOT ASSESSED — no bug records と記載します。ゼロ件として扱ったり、チェック済みにしたりしてはいけません。記録がない状態と、問題がない状態を同じチェックリストにしてはならないためです。バグは /bug-report で登録します。

フェーズ 3:コードベースをスキャンする

すべての件数で、分母を明記してください。 これらのスキャンは問題のあるものを探すため、0 は「検索した結果、見つからなかった」場合と「検索対象がなかった」場合のどちらも意味します。リリースゲートでは、この2つは正反対の結果です。scanned [N] source files: [M] TODO, [M] FIXME, [M] HACK と報告してください。コードのルート(src/、Assets/、または Source/。.claude/docs/code-root-resolution.md に従って特定します)が未解決の場合は、NOT ASSESSED — code root unresolved と記載します。また、ルートが存在しない、またはソースファイルが含まれていない場合は、NOT ASSESSED — no source files found to scan と記載します。単に 0 とするのは結果になりません。

未対応の問題をスキャンします。

  • TODO コメントの件数を数えます
  • FIXME コメントの件数を数えます
  • HACK コメントの件数を数えます
  • それらの場所と重大度を記録します

利用できる場合は、テスト出力ディレクトリまたは CI ログでテスト結果を確認します。 見つからなかった場合は、その旨を明記してください。行を省略するのではなく、Test results: NOT ASSESSED — no test output or CI logs found と記載します。テスト結果がない状態と、テストに合格した状態を同じリリースチェックリストにしてはなりません。


フェーズ 4:リリースチェックリストを生成する

## Release Checklist: [Version] -- [Platform]
Generated: [Date]

### Codebase Health
- Scanned: [N] source files (or `NOT ASSESSED — [reason]`, per Phase 3)
- TODO count: [N] ([list top 5 if many])
- FIXME count: [N] ([list all -- these are potential blockers])
- HACK count: [N] ([list all -- these need review])

### Build Verification
- [ ] Clean build succeeds on all target platforms
- [ ] No compiler warnings (zero-warning policy)
- [ ] All assets included and loading correctly
- [ ] Build size within budget ([target size])
- [ ] Build version number correctly set ([version])
- [ ] Build is reproducible from tagged commit

### Quality Gates
- Open bugs (`production/qa/bugs/`): [N] S1, [N] S2, [N] S3 -- or `NOT ASSESSED — no bug records`
- [ ] Zero open S1 (Critical) bugs
- [ ] Zero open S2 (High) and S3 (Medium) bugs, no exceptions -- this row at `workflow: full` only; at `standard`/`minimal` open S2/S3 bugs go in the Rationale as risks
- [ ] All critical path features tested and signed off by QA
- [ ] Performance within budgets:
  - [ ] Target FPS met on minimum spec hardware
  - [ ] Memory usage within budget
  - [ ] Load times within budget
  - [ ] No memory leaks over extended play sessions
- [ ] No regression from previous build
- [ ] Soak test passed (4+ hours continuous play)

### Content Complete
- [ ] All placeholder assets replaced with final versions
- [ ] All TODO/FIXME in content files resolved or documented
- [ ] All player-facing text proofread
- [ ] All text localization-ready (no hardcoded strings)
- [ ] Audio mix finalized and approved
- [ ] Credits complete and accurate

引数に基づいてデバイスのセクションを追加します。これらには認証やストアフロント SDK の項目は含まれません。これらは次のサブセクションで platform.cert_tier によって制御されており、ここで繰り返すと itch プロジェクトに Steamworks の項目が含まれてしまいます。

pc の場合:

### Platform Requirements: PC
- [ ] Minimum and recommended specs verified and documented
- [ ] Keyboard+mouse controls fully functional
- [ ] Controller support tested (Xbox, PlayStation, generic)
- [ ] Resolution scaling tested (1080p, 1440p, 4K, ultrawide)
- [ ] Windowed, borderless, and fullscreen modes working
- [ ] Graphics settings save and load correctly

console の場合:

### Platform Requirements: Console
- [ ] Platform-specific controller prompts display correctly
- [ ] Suspend/resume works correctly
- [ ] User switching handled properly
- [ ] Network connectivity loss handled gracefully
- [ ] Storage full scenario handled

mobile の場合:

### Platform Requirements: Mobile
- [ ] App store guidelines compliance verified
- [ ] All required device permissions justified and documented
- [ ] Privacy policy linked and accurate
- [ ] Data safety/nutrition labels completed
- [ ] Touch controls tested on multiple screen sizes
- [ ] Battery usage within acceptable range
- [ ] Background behavior correct (pause, resume, terminate)
- [ ] Push notification permissions handled correctly
- [ ] In-app purchase flow tested (if applicable)
- [ ] App size within store limits

モバイルのストアフロント項目をここに置くのは意図的です。 platform.cert_tier は none|itch|steam|console をモデル化しており、モバイル向けの区分はないため、App Store / Play Store の コンプライアンスをこれで制御することはできません。これらをデバイスのブロックに残すのは 意図的な判断であり、見落としではありません。mobile ティアをでっち上げて「修正」しないでください。 それは cert_tier のルールが警告している、まさに誤った用語です。

認証 — platform.cert_tier に一致するブロックのみを出力します(このスキルの先頭にある 解決済み設定ブロックで解決されます)。このサブセクションの他のブロックは出力せず、プラットフォーム引数が all だったからといって、すべてのブロックを出力しないでください。

none の場合 — 認証ブロックを一切出力しません。セクションが欠落しているように見えないよう、省略を明示するため、代わりに次の1行だけを出力します。

Certification: omitted — cert_tier is 'none' (internal build, alpha or jam release).

itch の場合:

### Certification: itch.io
- [ ] Build size within itch.io upload limits
- [ ] itch.io page complete (cover art, screenshots, description)
- [ ] Age/content tags set honestly
- [ ] Downloadable vs browser build decided and tested
- [ ] Butler channel names correct for each platform uploaded

steam の場合:

### Certification: Steamworks
- [ ] Steamworks SDK integrated and tested
- [ ] Depot build uploaded and installs cleanly from a fresh account
- [ ] Achievements functional
- [ ] Cloud saves functional
- [ ] Steam Deck compatibility verified (if targeting)
- [ ] Steam common content rules reviewed

console の場合:

### Certification: Console
- [ ] TRC/TCR/Lotcheck requirements checklist complete
- [ ] First-party certification submission prepared
- [ ] Platform-specific achievement/trophy integration tested
- [ ] Parental controls respected
- [ ] Save-data rules compliant (corruption, full storage, user switching)
- [ ] Age ratings obtained (ESRB, PEGI, regional)

cert_tier が未設定の場合、すべてのトラックを出力するのではなく、対象となるプラットフォームを確認してください。判断できない場合は ### Certification: NOT ASSESSED — cert tier unknown を出力し、その理由を説明してください。未設定は none ではありません — none は決定済みであり、未設定は決定が欠けています。

認証項目は、1つの cert_tier で制御されるサブセクションに置きます。 PC、Console、Mobile の デバイスブロックには置かないでください。これらはコマンド引数で選択され、デフォルトは all です。そのため、 引数なしで /release-checklist を実行する itch プロジェクトに、Steamworks SDK の項目 と Lotcheck の項目が渡されてしまいます。これは、このスキルの先頭にある cert_tier ルールで 禁止されています。

このファイルでは、console は2つの異なる意味を持ちます。 デバイスブロックの 引数値であり、同時に cert_tier の値でもあります。4つのうち1つの単語が重複しています。 **For \console`:**` という見出しは引数による制御であり、ティアによる制御ではありません。 これを、認証がすでにティアによって指定されている証拠と解釈しないでください。

ストアとローンチのセクション(全プラットフォーム):

### Store / Distribution
- [ ] Store page metadata complete and proofread
  - [ ] Short description
  - [ ] Long description
  - [ ] Feature list
  - [ ] System requirements (PC)
- [ ] Screenshots up to date and per-platform resolution requirements met
- [ ] Trailers up to date
- [ ] Key art and capsule images current
- [ ] Age rating obtained and configured:
  - [ ] ESRB
  - [ ] PEGI
  - [ ] Other regional ratings as required
- [ ] Legal notices, EULA, and privacy policy in place
- [ ] Third-party license attributions complete
- [ ] Pricing configured for all regions

### Launch Readiness
- [ ] Analytics / telemetry verified and receiving data
- [ ] Crash reporting configured and dashboard accessible
- [ ] Day-one patch prepared and tested (if needed)
- [ ] On-call team schedule set for first 72 hours
- [ ] Community launch announcements drafted
- [ ] Press/influencer keys prepared for distribution
- [ ] Support team briefed on known issues and FAQ
- [ ] Rollback plan documented (if critical issues found post-launch)

### Go / No-Go: [READY / NOT ASSESSED / NOT READY]

First match wins: **NOT READY** if any blocking item fails; else **NOT ASSESSED**
if any section or item came out `NOT ASSESSED` (name each one); else **READY**. NOT
ASSESSED outranks READY — an unassessed section is not a passed one — and ranks
below NOT READY, so a known blocker is never buried behind it.

**Rationale:**
[Summary of readiness assessment. List any blocking items that must be
resolved before launch. If NOT READY, list the specific items that need
resolution and estimated time to address them.]

**Sign-offs Required:**
- [ ] QA Lead
- [ ] Technical Director
- [ ] Producer
- [ ] Creative Director

フェーズ 5:チェックリストを保存する

チェックリスト項目の合計数と、既知のブロッカーの数(FIXME/HACK の件数、既知のバグ)を添えて、チェックリストをユーザーに提示します。

「これを production/releases/release-checklist-[version].md に書き込んでもよいですか?」

承認された場合は、必要に応じてディレクトリを作成し、ファイルを書き込みます。


フェーズ 6:次のステップ

  • まだ作成していない場合は、変更履歴またはパッチノート(/changelog、/patch-notes)を作成します。リリースゲートで確認されます。
  • /gate-check release を実行します。Polish → Release ゲートでこのチェックリストが読み込まれます。
  • PASS の後は、/launch-checklist を実行し、その後 /team-release でリリースを調整します。

コメント