playtest-report

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation

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

プレイテストレポート

フェーズ 1：引数の解析

チェックパターンの全体については .claude/docs/director-gates.md を参照してください。各ゲートの定義は .claude/docs/director-gates/[gate-id].md にあります。起動されたエージェントは自身のゲートファイルを読み込みます。親セッションでは読まないでください。

すべての AskUserQuestion 呼び出しは .claude/docs/automation-modes.md に従います （共同モードでは常に質問し、ガイド付きモードでは主要な項目のみ質問し、自律モードでは記録して続行します。 automation_always_ask カテゴリーでは常に質問します）。

モードを判定します。

• new → 空のプレイテストレポートテンプレートを生成します。このモードは フェーズ 2A の後に終了します。空のテンプレートには、振り分け、レビュー、保存するものがありません。
• analyze [path] → 生のメモを読み込み、構造化された所見をテンプレートに記入します
• 引数なし → AskUserQuestion で質問します。[A] 新しい空のテンプレート / [B] メモを分析 — パスを指定します

---

フェーズ 2A：新規テンプレートモード

このテンプレートを生成して、ユーザーに出力します。

# Playtest Report

## Session Info
- **Date**: [Date]
- **Build**: [Version/Commit]
- **Duration**: [Time played]
- **Tester**: [Name/ID]
- **Platform**: [PC/Console/Mobile]
- **Input Method**: [KB+M / Gamepad / Touch]
- **Session Type**: [First time / Returning / Targeted test]

## Test Focus
[What specific features or flows were being tested]

## First Impressions (First 5 minutes)
- **Understood the goal?** [Yes/No/Partially]
- **Understood the controls?** [Yes/No/Partially]
- **Emotional response**: [Engaged/Confused/Bored/Frustrated/Excited]
- **Notes**: [Observations]

## Gameplay Flow
### What worked well
- [Observation 1]

### Pain points
- [Issue 1 -- Severity: High/Medium/Low]

### Confusion points
- [Where the player was confused and why]

### Moments of delight
- [What surprised or pleased the player]

## Bugs Encountered
| # | Description | Severity | Reproducible |
|---|-------------|----------|-------------|

## Feature-Specific Feedback
### [Feature 1]
- **Understood purpose?** [Yes/No]
- **Found engaging?** [Yes/No]
- **Suggestions**: [Tester suggestions]

## Quantitative Data (if available)
- **Deaths**: [Count and locations]
- **Time per area**: [Breakdown]
- **Items used**: [What and when]
- **Features discovered vs missed**: [List]

## Overall Assessment
- **Would play again?** [Yes/No/Maybe]
- **Difficulty**: [Too Easy / Just Right / Too Hard]
- **Pacing**: [Too Slow / Good / Too Fast]
- **Session length preference**: [Shorter / Good / Longer]

## Top 3 Priorities from this session
1. [Most important finding]
2. [Second priority]
3. [Third priority]

new モードでは、ここで「判定：完了 — 空のテンプレートを出力しました。保存するものはありません。」と示して終了します。

---

フェーズ 2B：分析モード

指定されたパスにある生のメモを読み込みます。既存の設計ドキュメントと照合し、各ドキュメントをセクションごとに読み込みます。必要な見出しを Grep ツール（パターン ^#、コンテンツモード）で検索し、該当範囲を offset と limit を指定して Read します。上記のテンプレートに構造化された所見を記入します。プレイテストでの観察結果が設計意図と矛盾する場合は、その旨を明記します。

クラッシュ、フレームレートの低下、ソフトロックなど、プレイフィールの悪さではなく明らかな不具合を示す観察結果は、ゲームプレイの流れ → 問題点ではなく、発生したバグテーブルに記載し、フェーズ 3 でバグとして振り分けます。問題点は、ゲームのプレイフィールに関する項目です。

---

フェーズ 3：対応の振り分け

すべての所見を次の 4 つのカテゴリーに分類します。

• 必要な設計変更 — 面白さに関する問題、プレイヤーの混乱、壊れたメカニクス、GDD が意図する体験と矛盾する観察結果
• バランス調整 — 数値に違和感がある、難易度の山が急すぎる、または平坦すぎる
• バグ報告 — 再現可能な明確な実装上の不具合
• ポリッシュ項目 — 進行を妨げるものではないが、後で解消する摩擦やプレイフィールの問題

分類した一覧を提示してから、次のように振り分けます。

• 設計変更：「変更の前に、影響する設計ドキュメントに /propagate-design-change [path] を実行し、下流への影響を確認してください。」
• バランス調整：「値を調整する前に、バランス全体を確認するため /balance-check [system] を実行してください。」
• バグ：「正式に追跡するには /bug-report を使用してください。」
• ポリッシュ項目：「チームがそのフェーズに入ったら、production/ のポリッシュバックログに追加してください。」

---

フェーズ 3b：クリエイティブディレクターによるプレイヤー体験レビュー

レビュー方式の確認 — CD-PLAYTEST を起動する前に適用します。

• solo → スキップします。次のように記録します："CD-PLAYTEST skipped — Solo mode."。フェーズ 4（レポートの保存）に進みます。
• lean → スキップします（PHASE-GATE ではありません）。次のように記録します："CD-PLAYTEST skipped — Lean mode."。フェーズ 4（レポートの保存）に進みます。
• full → 通常どおり起動します。

調査結果を分類した後、ゲート CD-PLAYTEST（.claude/docs/director-gates/cd-playtest.md）を使用し、Agent 経由で creative-director を起動します。

構造化レポートの内容、ゲームの柱とコアとなるファンタジー（design/gdd/game-concept.md の内容）、検証対象の具体的な仮説を渡します。game-concept.md が存在しない場合 — design/game-brief.md が代わりとなる minimal では想定される状態です — ブリーフにはゲームの柱がありません。その場合は、代わりに1文のピッチと「対象ユーザー／プレイヤーに感じてほしいこと」の行を渡し、それらがゲームの柱の代わりであることを伝えます。どちらのドキュメントも存在しない場合は、プロンプトに次のように記載します。 「ゲームの柱はありません — 仮説のみを基準に評価してください。」 ゲートにゲームの柱について何も伝えないと、ディレクターがそれを勝手に作り出します。

レポートを保存する前に、クリエイティブディレクターの評価を提示します。CONCERNS または REJECT の場合、判定とフィードバックを記録する ## Creative Director Assessment セクションをレポートに追加します。APPROVE の場合は、レポートに承認を記録します。NOT ASSESSED（入力情報が不足していた場合 — .claude/docs/director-gates.md）の場合は、不足していた情報を明記した同じセクションを追加します。これは承認ではありません。

---

フェーズ 4：レポートの保存

「このプレイテストレポートを production/qa/playtests/playtest-[date]-[tester].md に書き込んでもよろしいですか？」と尋ねます。

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

---

フェーズ 5：次のステップ

判定：完了 — プレイテストレポートを生成しました。

• 最も優先度の高い調査結果のカテゴリーから対応します。
• デザイン変更に対応した後、更新した GDD に対して /design-review を再実行します。
• バグを修正した後、優先度を更新するため /bug-triage を再実行します。