steam-launch-readiness

Steam のリリース準備

Steam のリリースを、製品、ストア、コミュニティ、ライブ運営が連携したローンチに仕上げるために、このスキルを使用します。

ワークフロー

1. ゲームのジャンル、対象ユーザー、ローンチ段階、収益化モデル、対応言語、リリース戦略を特定します。
2. references/steam-launch-systems.md を読みます。
3. ストアページでの訴求、ウィッシュリスト獲得の導線、デモ／プレイテスト計画、ビルド品質、コミュニティの準備状況、価格設定、サポートを監査します。
4. ローンチ前、ローンチ当日、最初の1週間、ローンチ後の運用を分けます。
5. 曖昧なローンチの助言を判断ゲートに落とし込みます。技術的なリリースゲート、商業ポリシーのゲート、コミュニティ対応のゲート、数値または事前合意済みのしきい値を設けた最初の1週間の学習ゲートを含めます。
6. ストアでの訴求内容をビルドの実態と照合します。カプセル画像、短い説明、タグ、トレーラー、スクリーンショット、実績、クラウドセーブ、コントローラー対応、設定、ローカライズ、システム要件、デモの範囲、DLC の表現を確認します。
7. プレイヤーへのコミュニケーションを運用可能な形にします。不具合報告の形式、既知の問題の状況、ETA の方針、サポート用マクロ、公開アップデートの頻度、修正をホットフィックス、ロールバック、説明文の変更、ロードマップ項目のいずれにするかを定めます。
8. Steam の割引／返金／レビューに関するポリシーを記憶に頼って断定しないでください。ポリシー確認マトリクスを使用し、数値の警戒ラインは、スタジオが承認済みの目標を提示していない限り、社内向けの初期しきい値として明記します。
9. 準備状況マトリクスを作成し、ブロッカー、アセット、テレメトリー、レビューリスクの軽減策を含めます。

使用しない場合

• このスキル固有の成果物要件がなくてもベースモデルが対応できる一般的な助言には使用しないでください。

ガードレール

• ビルドで実現できない内容をストアで訴求しないでください。
• ウィッシュリストを見栄えだけの指標として扱わず、デモ、アップデート、ローンチ時期、コンバージョンと結び付けてください。
• ローンチ週に返金、セーブデータ消失、パフォーマンス、コントローラー、コミュニティの問題を無視しないでください。
• ビルド、ストアページ、サポート計画で裏付けられない価格設定、割引、DLC、互換性、アンチチート、プラットフォーム機能への対応を主張しないでください。
• 初回プレイ時のクラッシュ、セーブデータの破損、誤解を招くストア上の主張、担当者のいないモデレーションは、仕上げの課題ではなくローンチのブロッカーとして扱ってください。
• 返金、レビュー、クラッシュ、デモ、サポート、サーバーの健全性に関する監視を定性的なものにしないでください。スタジオから目標が提示されている場合はそれを使い、そうでない場合はローンチ前に置き換えることを明記した初期しきい値を提示してください。
• 初期しきい値をプラットフォームのポリシーとして扱わないでください。これらは、ホットフィックス、ロールバック、説明文の変更、サポートへのエスカレーション、プロモーションの一時停止を判断するための社内運用上の警戒ラインです。

出力形式

Game/launch context:
Release strategy:
Launch calendar:
- <pre-launch/demo/embargo/launch/day-1/week-1 beat> -> owner, decision gate

Readiness matrix:
- Store page:
- Build/platform:
- Community/support:
- Launch operations:
- Creator/press readiness:

Technical gates:
- <gate> -> metric/threshold, owner, proof

Store/build promise audit:
- <capsule/short-description/tag/trailer/screenshot/demo/DLC/achievement/cloud-save/controller/localization/system-requirement/settings claim> -> build proof, owner, blocker/fix

First-week decision thresholds:
- <signal> -> <numeric/pre-agreed threshold>, segment, owner, action

P0 blockers:
- <blocker> -> owner, proof needed

Commercial policy:
- <pricing/discount/DLC/refund risk decision> -> rationale, evidence, rollback/communication path
- Creator keys / embargo / press kit -> build version, known-issues note, support owner, embargo time, content guidance

Wishlist/review/learning plan:
- <action> -> metric, timing

Review-bombing / incident response:
- <signal> -> valid-defect triage, moderation/reporting path, player communication
- Bug-report format / support macro / ETA policy / roadmap-or-hotfix decision: