create-stories

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,review_gate,automation,workflow,docs.density,story_granularity,qa.level,system_overrides

上記で解決済みの値をそのまま使用します。--review は review_mode を上書きします。ブロックはありません → デフォルト値は .claude/docs/config-resolution.md にあります。

質問ツールで尋ねてください。質問ツールがない場合は、選択肢に番号を付けて列挙し、回答を待つためにそこでターンを終了してください。質問をスキップまたは却下したことは回答ではありません。通常のテキストで再度尋ねてください。

ストーリーを作成する

ストーリーとは、1つの実装可能な動作です。story_granularity が定めるサイズに収まり、単独で完結し、要件と、その動作を規定する決定にたどれる必要があります。依存関係の順に、エピックごとにこのスキルを1回実行します。まず Foundation エピック、次に Core、Feature、Presentation の順です。

書き込み先： production/epics/[epic-slug]/story-NNN-[slug].md、エピックの EPIC.md の Stories テーブル、および production/epics/index.md の該当行。 次の手順： workflow: minimal の場合は /dev-story [story-path]、それ以外の場合は /story-readiness [story-path] を実行してから /dev-story を実行します。

質問は .claude/docs/automation-modes.md に従います（collaborative では必ず質問し、guided では主要な選択について質問し、autonomous では記録して続行します。automation_always_ask のカテゴリでは必ず質問します）。

チェックリスト（コピーして、進行に合わせてチェックしてください）：

- [ ] Phase 1: epic found, tier resolved
- [ ] Phase 2: inputs loaded, each ADR's status reported
- [ ] Phase 3-4: stories drafted, typed, Ready or Blocked
- [ ] Phase 5: QA lead review run, or its skip noted
- [ ] Phase 6: story list shown, one ask to write
- [ ] Phase 7: stories, EPIC.md and index.md written (or index absence said)
- [ ] Phase 8: next step asked, closing block printed

フェーズ 1：エピックと設定

ティア。 エピックのシステムに対する workflow を使います。該当する行があればエピックのスラッグ（その GDD システム）に対応する system_overrides の行を、なければプロジェクトの値を使います。

story_granularity は各ストーリーの受け入れ条件の量を設定します。目標に合わせて条件をまとめたり分割したりしてください。

story_granularity	ストーリーごとの AC 数	サイズ
coarse（デフォルト、rigor: minimal）	5-10	機能全体、複数日
balanced（rigor: standard）	2-4	1つのタスク、約1セッション
fine	1	1つの基準。ストーリー名でその基準を言い換えます

docs.density は各ストーリーの文章（コンテキスト、実装メモ、ADR の要約）の詳しさを設定します。AC の数や AC の文面は変更しません。terse（デフォルト）＝箇条書きのメモのみで、前置きなし。balanced＝短いコンテキスト段落とメモ。thorough＝コンテキスト、ガイダンス、ADR の根拠を詳しく記述します。TR-ID、ADR Version、受け入れ条件は決して省略しません。

対象のエピック。 スキル名の後に入力されたテキストから、--review <mode> の組を除いたものです。エピックのスラッグ（combat）またはパス（production/epics/combat/EPIC.md）を指定します。何も入力されていない場合でも、ユーザーのリクエストで名前が挙がったエピック（「loot エピック」など）は指定済みとして扱います。

• 名前は指定されているが、そこに EPIC.md がない場合： standard および full では、「production/epics/[slug]/EPIC.md にエピックがありません。/create-epics を実行して作成するか、ls production/epics/ でスラッグを確認してください。」と伝えて停止します。推測で分解してはいけません。minimal では、このティアでは /create-epics のエピックは不要だと伝え、フェーズ 2 の minimal 分岐に進み、使用するスラッグを明記します。
• minimal で未指定の場合： フェーズ 2 の minimal 分岐に進みます。
• standard または full で未指定の場合： production/epics/*/EPIC.md を各ステータスとともに一覧表示し、「どのエピックをストーリーに分解しますか？」と尋ねます。各エピックを1つずつ選択肢として提示します。エピックが見つからない場合： 停止して、「production/epics/ にエピックが見つかりません。まず /create-epics layer: foundation を実行してください。」と伝えます。選択肢がない状態で質問してはいけません。

フェーズ 2：入力を読み込む

minimal：ブリーフからエピックを作成する

1. **design/game-brief.md がない場合：**停止します。「ストーリーを作成するためのブリーフがまだありません。まず /brainstorm を実行してください。1ページのブリーフが作成されます。」コードルートにすでにゲームがある場合（ソースファイルが10個以上）、代わりに /reverse-document design [code root] を案内します。
2. design/game-brief.md をすべて読みます（1ページ）。
3. エピック。 <slug> はブリーフの仮タイトルをスラッグ化したもの（タイトルがない場合は mvp）、またはユーザーが指定したエピックです。
   • production/epics/<slug>/EPIC.md が存在する場合、それがエピックです。ブリーフに対応づけられたスコープを使用し、書き換えてはいけません。
   • 存在しない場合：Phase 6 で名前が指定されるのを待ち、Phase 7 で初めてエピックを作成します。Goal = ブリーフの1文のピッチ、scope = MVP機能一覧、order = Build order です。簡潔にまとめます。
   • フォルダーにすでにストーリーがある場合（再訪時）：既存の story-*.md は書き換えてはいけません。ブリーフの項目のうち既存ストーリーで扱われていないもの、またはユーザーが指定した新しい項目に限って追加し、番号は既存の最大の story-NNN の次から付けます。
4. **MVP機能ごとに1つのストーリーを、Build order に沿って作成し、**各ストーリーをブリーフに対応づけます。ADRを理由にブロックされるストーリーはありません。このティアにはADRがありません。

minimal ではGDD、control manifest、TR registry、ADRを読みません。Phase 3 に進みます。

standard と full：エピックと、その適用ルール

1. エピック：production/epics/[epic-slug]/EPIC.md をすべて読みます（そのレイヤー、GDD、適用されるADR、TR-IDを含むGDD Requirements表）。
2. **GDD：**ファイル全体ではなく、見出しごとにセクションを読みます。 bash .claude/scripts/md-section.sh extract design/gdd/[file].md "Acceptance Criteria" を実行し、同様に Formulas、Edge Cases、Detailed Design も読みます（終了コード3の場合は、デザイン標準で同じセクションを指す名称である Detailed Rules を試します）。full では、その他の必須セクションも読みます（見出しは list で確認できます）。
3. **control manifest：**エピックのレイヤーのみとバージョンを確認します。 bash .claude/scripts/md-section.sh extract docs/architecture/control-manifest.md "[Layer] Layer Rules" に加え、Manifest Version の行も読みます。
4. **TR registry：**このシステムのエントリーのみを確認します。docs/architecture/tr-registry.yaml で system: <slug>\s*$ に一致する行と、各エントリーの上にある id および下にあるテキストを読みます。アンカーにより combat が combat-ai に一致するのを防ぎ、\s* はWindowsの行末にも対応します。
5. **ADR：**エピックに記載されているADR（適用されるもの、Requirements表に記載されているもの、Proposedのものを含む）をすべて、1回の呼び出しで確認します。

   bash .claude/scripts/adr-status.sh ADR-0001 ADR-0003 ...
   

   各行には、ステータス、レイヤー、version（ストーリーのADR Versionスタンプ）、depends_on、不足しているセクションが示されます。その後、各ADRの Summary、Decision（その中のImplementation Guidelinesを含む）、Engine Compatibility のみを md-section.sh extract で読みます。Engine Notesはストーリーのフィールドであり、ADRのセクションではありません。これらのセクションが1つもないADRはテンプレート導入前のものです。一度すべて読み、/architecture-decision retrofit [file] を実行する必要があることを明記します。

名前が挙がっているADRのファイルがない場合（NOT_FOUND）：

• full：ストーリーを分解する前に停止します。
• standard：そのADRがクリティカル（Foundationレイヤー）の場合のみ停止します。それ以外の場合は警告して続行し、対象となるストーリーがADRの作成まで Blocked になるよう記載します。
• 停止時：「エピックには [ADR-NNNN: title] が記載されていますが、docs/architecture/ にそのファイルが見つかりません。エピックのGoverning ADRs一覧を確認するか、/architecture-decision を実行して作成してください。参照先のADRファイルが揃うまで、ストーリーは作成できません。」

**下書きの前に、**実際の状態を報告し、各ADRのステータスを個別に示します。

Loaded: epic [name] · GDD [file] · manifest v[date], [layer] rules
ADRs: ADR-0001 Accepted · ADR-0002 Accepted · ADR-0003 Accepted · ADR-0004 Proposed · [ADR-NNNN missing]

1つでも欠けている場合は「すべて揃っています」と決して言わず、存在しない場合はmanifestのバージョンを記載してはいけません。

フェーズ 3：各ストーリーを分類する

種類	受け入れ条件が参照する内容
ロジック	数式、しきい値、状態遷移、AI の判断、計算
インテグレーション	2 つ以上のシステム、境界をまたぐ信号、保存／読み込みの往復処理
ビジュアル／操作感	アニメーション、VFX、「反応がよい操作感」、タイミング、画面の揺れ、音声同期
UI	メニュー、HUD、ボタン、画面、ダイアログボックス、ツールチップ
設定／データ	バランス値とデータファイルのみ。新しいロジックは含めない

複数の種類にまたがるストーリーには、実装リスクが最も高い種類を割り当てます。種類によって、/story-done に必要な証拠が決まります。

フェーズ 4：ストーリーを作成する

同じ中核的な実装を必要とする要件をまとめ、story_granularity に合わせてストーリーを作成します。順序は、基盤となる動作、エッジケース、UI の順にします。各ストーリーには、次の項目を記載します。

• Requirement： レジストリの TR-ID。エピックの GDD Requirements テーブルを通じて対応付けます。一致する項目がない場合に限り、TR-[system]-??? と記載し、その旨を明記します。
• ADR： 実装方法を規定する ADR（Requirements テーブルに記載されています）。
  • Accepted：内容を組み込みます。
  • Proposed：Status: Blocked とし、「BLOCKED: ADR-NNNN is Proposed — accept it with /architecture-decision accept ADR-NNNN once decided」と記載します。
  • Deprecated または Superseded：Status: Blocked とし、「BLOCKED: ADR-NNNN is [status] — point the story at [successor] (edit its ADR field; /create-stories never rewrites an existing story) before implementing」と記載します。
  • depends_on に Accepted ではない ADR が指定された Accepted ADR：その ADR を明記して、同様に Blocked とします。
  • 該当する ADR が複数ある場合：すべて列挙し、最も直接関係するものを先に記載します。
  • 該当する ADR がない場合：ADR: N/A — [reason] と記載します。例：「純粋なデータ設定」。空欄にしないでください。空欄は未確認を意味します。
• ADR Version： ストーリーの ADR Version は、ADR の ## Last Verified の日付、なければ ## Date の日付、それもなければ unversioned（version 列）です。ADR の概要が引き続きこのバージョンと一致している間、/dev-story はその概要を信頼します。
• エンジンリスク： ADR の Engine Compatibility（その知識リスク）から設定します。
• 見積もり： 受け入れ条件とストーリーが扱うファイルに基づいて、T シャツサイズを提案します。S（数時間）、M（約 1 日）、L（数日）から選びます。これは提案です。フェーズ 6 で提示し、ユーザーが変更できます。Estimate がテンプレートの角括弧のままのストーリーは /story-readiness で失敗するため、未記入のままにしないでください。

フェーズ 5：QA リードによるレビュー

上記の review_gate 行を確認します。skill-gates=skip（ソロまたはリーン）の場合はレビューを行いません。フェーズ 6 のリストと締めくくりのブロックに「QL-STORY-READY skipped — [Solo | Lean] mode」と記載します。skill-gates=run の場合は、references/qa-lead-gate.md と .claude/docs/director-gates.md を読み、フェーズ 6 の確認を求める前に実行します。スキップする場合は、読み込まないでください。

フェーズ 6：ストーリーを提示し、一度だけ確認を求める

## Stories for Epic: [name]
ADRs: ADR-0001 Accepted · ADR-0002 Accepted · ADR-0004 Proposed   (every ADR, from Phase 2)

Story 001: [title] — Logic — ADR-0001 — Ready — Estimate M
  Covers: TR-[system]-001 ([one-line requirement])
  Test required: tests/unit/[system]/[slug]_test.[ext]

Story 002: [title] — Integration — ADR-0004 — BLOCKED (ADR-0004 is Proposed) — Estimate L
  Covers: TR-[system]-002, TR-[system]-003
  Test required: tests/integration/[system]/[slug]_test.[ext]

Story 003: [title] — Visual/Feel — ADR-0001 — Ready — Estimate S
  Covers: TR-[system]-004
  Evidence required: retained screenshot + sign-off in production/qa/evidence/[slug]-evidence.md

[N stories: N Logic, N Integration, N Visual/Feel, N UI, N Config/Data; N Blocked]
QL-STORY-READY: [skipped — Solo mode | its verdicts]

minimal の場合、各行を Brief MVP feature N に対応付け、ADR 行は設けず、MVP の機能ごとに 1 つのストーリーを作成します。MVP リストに含まれないブリーフ項目について、追加のストーリーを作成してはいけません。その後、次のように確認を求めます。「これら [N] 件のストーリーを production/epics/[epic-slug]/ に書き込み、production/epics/[epic-slug]/EPIC.md を[作成 | 更新]し、production/epics/index.md を更新してもよろしいですか？」選択肢：はい、[N] 件すべてを書き込む／まだです。先に調整したいです。調整では、どの見積もりも変更できます。フェーズ 7 で変更するすべてのファイル名を提示します。EPIC.md は存在しない場合にのみ作成し、index.md が存在しない場合は対象に含めません。はいという確認を得る前に何も書き込まないでください。

フェーズ 7：書き込む

ストーリーファイル

各ストーリーは production/epics/[epic-slug]/story-[NNN]-[slug].md に作成し、 .claude/docs/templates/story.md の形式にします。ストーリー番号は再利用しないでください。各ファイルはファイルとして作成し、シェルコマンド経由では作成しないでください。シェルで書き込むと、プロジェクトの書き込みチェックがスキップされます。

minimal では、GDD、ADR、TR レジストリ、マニフェストはありません。以下のフィールドに正確に記入してください。

フィールド	minimal での値
GDD	design/game-brief.md
Requirement	Brief MVP feature N。TR-ID は使用しません
ADR Governing Implementation、ADR Decision Summary、ADR Version	N/A (minimal — no ADRs)
Manifest Version、Control Manifest Rules	N/A (minimal — no control manifest)
Engine	engine.name + engine.version
Risk	固定バージョンが docs/engine-reference/<engine>/VERSION.md に記載されているレベル（タイムラインの行、または全体評価）。ファイルまたはレベルがない場合は、推測せず NOT ASSESSED (no VERSION.md risk rating) とします。/dev-story は NOT ASSESSED を HIGH として扱います
Engine Notes	none (no ADR engine-compatibility analysis at minimal)
Acceptance Criteria	ブリーフの Player goal & fail state と MVP 機能に基づき、具体的かつテスト可能にします。箇条書きだけを根拠に作り出してはいけません

すべてのティアで：

• **QA Test Cases：**レビューがスキップされた場合は、 *N/A — no qa-lead specs at this tier; implement against the Acceptance Criteria above* と記入します。テストケースを独自に考案してはいけません。
• Test Evidence： qa.level に従います。qa.level: minimal ではテストは免除されます（参考扱い）が、Visual/Feel または UI ストーリーで保持するスクリーンショットは免除されません。
• Estimate： Phase 6 のサイズを記入し、ユーザーによる変更があれば反映します。
• **Dependencies：**このストーリーが必要とする各ストーリーを、そのパスで指定します。
• **Files：**コードルートとテストルートの配下に、作成または変更する予定のコードファイルとテストファイルを記載します。/dev-story が実際の一覧に置き換えます。

EPIC.md

minimal でまだファイルがない場合は、以下の表を使って Phase 2 のドラフトを作成します。それ以外の場合は、「Stories: Not yet created」の行を表に置き換えます。再訪時には、新しいストーリーごとに1行追加し、ファイルの残りの部分はそのままにします。

## Stories

| # | Story | Type | Status | ADR |
|---|-------|------|--------|-----|
| 001 | [title] | Logic | Ready | ADR-0001 |
| 002 | [title] | Integration | Blocked | ADR-0004 |

production/epics/index.md

そのエピックの Stories セルを [N] stories に設定します。ここでのエピックの合計数は今回の実行後の数です。ファイルが存在しない場合は、次のように伝えます。 Epics index not updated: production/epics/index.md absent

Phase 8: 完了

production/epics/ 内にストーリーがない他のエピックがあれば、列挙します。その後、次のように質問します。 「production/epics/[epic-slug]/ に [N] 件のストーリーを作成しました。次は何をしますか？」該当する選択肢を提示します。

• 実装を開始する：minimal では /dev-story [first-story-path]、それ以外では /story-readiness [first-story-path]（推奨）
• [next epic] のストーリーを作成する：/create-stories [slug]（ストーリーがないエピックがある場合のみ）
• スプリントを計画する：/sprint-plan new（すべてのエピックにストーリーがある場合のみ。ブリーフのビルド順が計画となる minimal では実行しません）
• 今回のセッションはここで終了する

実装を開始したり、コードを書いたりしてはいけません。このスキルはストーリーファイルの作成で終了します。受け入れ基準は GDD（minimal ではブリーフ）、実装メモは ADR、ルールはマニフェストに基づきます。いずれも独自に作り出してはいけません。

実行の最後の返信は、上記の質問への回答の後に、次のブロックで終わらせます（先に提示していた場合も、もう一度繰り返します）。

Verdict: COMPLETE — [N] stories written to production/epics/[epic-slug]/ ([N] Ready, [N] Blocked)
Review: [QL-STORY-READY skipped — Solo mode | skipped — Lean mode | its verdicts]
Index: [production/epics/index.md updated | Epics index not updated: production/epics/index.md absent]
Next step: [/dev-story [first-story-path] | /story-readiness [first-story-path]]

ユーザーが書き込みを拒否した場合： Verdict: BLOCKED — user declined. No story files written.