create-control-manifest

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

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

質問ツールを使って質問してください。質問ツールがない場合は、選択肢を番号付きで列挙し、回答を待つためにここで終了してください。スキップまたは閉じられた質問は回答ではありません。通常のテキストで再度質問してください。

コントロールマニフェストを作成する

コントロールマニフェストは、プログラマー向けの簡潔なルール集です。採用済み ADR、プロジェクトの技術的な方針、エンジンのリファレンスドキュメントに基づき、アーキテクチャレイヤーごとに、実施すべきことと決して実施してはならないことをまとめます。ADR は「なぜ」を示し、マニフェストは「何を」を示します。

書き込み先： ユーザーの承認後に docs/architecture/control-manifest.md を作成します。 実行タイミング： /architecture-review に合格し、ADR が採用済みになった後です。ADR が採用または改訂されるたびに、再実行してください。

質問は .claude/docs/automation-modes.md に従います（協調モードでは常に質問し、ガイド付きモードでは重要な選択について質問し、自律モードでは記録して続行します。automation_always_ask のカテゴリでは常に質問します）。

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

ADR

bash .claude/scripts/adr-status.sh は、すべての docs/architecture/adr-*.md を一度に読み込みます。まず件数（adrs、続いて accepted、proposed、deprecated、superseded、unfilled、other、no_status）を出力し、その後、ADR ごとにステータスとレイヤーを示す行を出力します。まず分母を確定します。ADR を読む前に、件数に基づいて判断してください。

件数	意味	対応
adrs 0	ADR がありません。	「ADR が見つかりませんでした。コントロールマニフェストを作成する前に、/architecture-decision を実行してください。」と伝えて停止します。
accepted ≥ 1	通常の状態です。	Accepted の行が集合 A です。フェーズ 4 のプレビューでは、ほかのすべての ADR をステータスとともに示します。ユーザーが、何を含めないかを把握したうえでマニフェストを承認できるようにします。
accepted 0、ステータスのある ADR が存在する	Accepted の ADR がありません。	「[N] 件の ADR が見つかりましたが、Accepted はありません。Proposed の ADR から作成したマニフェストには、今後変更される可能性のある決定が反映されます。」と伝え、Proposed の ADR を使って続行するか、停止するかを尋ねます。空のマニフェストを黙って作成してはいけません。
すべての ADR が no_status	ADR の形式が不正です。Accepted がゼロという意味ではありません。	「[N] 件の ADR が見つかりましたが、## Status セクションがないため、採用済みかどうか判断できません。各 ADR に対して /architecture-decision retrofit [file] を実行してください。」と伝えて停止します。Accepted として扱ってはいけません。

上記の各停止処理では、最後に Verdict: BLOCKED — [the reason] を付けてください。ルールの根拠となるすべての ADR について、番号とタイトルを記録してください。

プロジェクト設定

• project.yaml の naming.* と performance.* を使用します。キーがない場合、または値が空の場合は .claude/docs/technical-preferences.md を使用します。
• 承認済みライブラリと禁止パターンは、.claude/docs/technical-preferences.md を参照します（project.yaml には移行されていません）。

エンジンのリファレンス

• エンジンとバージョンについては、docs/engine-reference/[engine]/VERSION.md を参照します。
• docs/engine-reference/[engine]/deprecated-apis.md を参照します。ここに記載された API は禁止 API になります。
• 存在する場合は、docs/engine-reference/[engine]/current-best-practices.md を参照します。

すでに存在するもの

docs/architecture/control-manifest.md が存在する場合、この実行で再生成します。フェーズ 5 で置き換える前に読み込んでください。production/epics/*/EPIC.md が存在する場合、エピックが存在します。フェーズ 6 では、両方をもとに次のステップを選択します。

報告：「[A] 件の Accepted ADR を [N] 件中読み込みました。エンジン：[name + version]。」

フェーズ 2：各 ADR からルールを抽出する

A に含まれる各 ADR について、ファイル全体ではなく、次の 4 つのセクションだけを読みます。

bash .claude/scripts/md-section.sh extract docs/architecture/[adr-file].md "Decision"

同様に、Alternatives Considered、Performance Implications、Engine Compatibility も読みます。Context、Consequences、Migration Plan、Validation Criteria には、判断がなされた理由が記載されています。マニフェストには、実行する内容を記録します。ADR にないセクションがあれば、その ADR について記録して先に進みます。A のすべての ADR に存在しないセクションがあれば、「No Accepted ADR has a [section] section — the manifest's [category] rules will be empty. Verify this is intended.」と報告します。セクション内で参照先がセクション外にある場合（「Context の制約に従う」など）に限り、4 つのセクション以外も読み、そのセクションだけを確認します。

各 ADR から抽出する内容：

• 必須パターン（Decision）：すべての「must」、「should」、「required to」、「always」と、義務付けられているすべてのパターンやアプローチを含めます。### Implementation Guidelines が含まれている場合は、それも対象です。このサブ見出しだけを探してはいけません。多くの ADR では、Decision の直下に要件が直接記載されています。サブ見出しだけを検索すると、セクションが空だと判断してしまいます。
• 禁止するアプローチ（Alternatives Considered）：却下されたすべての選択肢と、却下理由をルールとして記載します（「理由 Y のため、X は決して使用しない」）。名前が挙げられているアンチパターンも含めます。
• パフォーマンス上の制約（Performance Implications）：予算（「このシステムではフレームあたり最大 N ms」など）とメモリ上限。
• エンジン API の制約（Engine Compatibility）：カットオフ後に追加され、検証が必要な API、モデルが想定する動作とは異なる動作、固定バージョンで変更されたフィールドやメソッド。

レイヤー。 各ルールは、そのルールが対象とするシステムのレイヤーに配置します。ADR に layer 列がある場合は、その列を参照します。

• **基盤：**シーン管理、イベントアーキテクチャ、セーブ／ロード、エンジンの起動
• **コア：**コアゲームループ、主要なプレイヤーシステム、物理演算と衝突判定
• **機能：**副次的なシステムとメカニクス、AI
• **プレゼンテーション：**レンダリング、オーディオ、UI、VFX、シェーダー

複数のレイヤーにまたがる ADR のルールは、それぞれのレイヤーに配置します。

フェーズ 3：グローバルルールを追加する

すべてのレイヤーに適用されるルールには、それぞれの出典（project.yaml のキー、technical-preferences.md、またはエンジンリファレンスファイル）を付記します。レイヤールールと同様に、次の項目を含めます。

• 命名規則：naming.* に基づき、クラス、変数、シグナルとイベント、ファイル、定数を対象とします。
• パフォーマンス予算：performance.* に基づき、目標フレームレート、フレーム予算、ドローコール数、メモリ上限を対象とします。
• 禁止 API：deprecated-apis.md に記載されているもののうち、このプロジェクトで構築するものに適用される項目だけを対象とします。表全体をそのままコピーしてはいけません。GodotPhysics3D → Jolt Physics 3D の行は 3D 専用であり、2D プロジェクトではそのエンジンを使用しません。項目が適用されるか判断できない場合（2D か 3D か、プロジェクトに含まれるか不明なモジュールなど）は、ルールの適用範囲を限定します（「3D 物理演算を使用する場合：…」など）。または、その項目を除外して未解決の項目として列挙します。/create-stories はこのファイルを読み込みます。適用されないルールは、誰にも読まれないルールです。
• 必須パターン：current-best-practices.md が存在する場合は、そこから抽出します。
• 禁止パターン：technical-preferences.md に記載されている内容を、そのまま記載します。

フェーズ 4：要約を表示してから、レビューを行います

## Control Manifest Preview
Engine: [name + version]
ADRs covered: [ADR numbers]
ADRs left out: [ADR-NNNN ([status]), … — every ADR not in A, or "None"]
Rules extracted:
  - Foundation layer: [N] required, [M] forbidden, [P] guardrails
  - Core layer: [N] required, [M] forbidden, [P] guardrails
  - Feature layer: …
  - Presentation layer: …
  - Global: [N] naming conventions, [M] forbidden APIs, [P] approved libraries
Unresolved: [engine entries left out because whether they apply is unclear, or "None"]

質問：「このルールの要約で漏れはありませんか？」選択肢：はい — レビューして書き込む / ルールを追加 — 追加したい内容があります / ルールを削除 — 削除したいものがあります / 中止 — まず ADR を確認する必要があります。

技術レビュー。 上記の review_gate 行を確認します。skill-gates=skip （単独またはリーン）：エージェントなし。TD-MANIFEST skipped — [Solo | Lean] mode と記録します。 skill-gates=run：レビューを TD-MANIFEST ゲート（.claude/docs/director-gates/td-manifest.md。エージェント自身が読み取ります）とともに technical-director エージェントに引き渡します。要点：

• 目的： 抽出したルールが書き込まれる前に確認します。
• 渡すもの： 上記のプレビューと、ルールの全一覧、対象となる ADR、エンジンのバージョン、技術的な設定またはエンジンのリファレンスから採用したルール。
• 確認事項： 必須の ADR パターンがすべて正確に取り込まれ、記述されていること。禁止されているアプローチが漏れなく、正しく出典に帰属していること。出典となる ADR または設定文書のないルールがないこと。ガードレールが ADR の制約と一致していること。
• 返答： APPROVE、CONCERNS、REJECT、または不足している入力を示した NOT ASSESSED。
• 境界： ファイルは書き込みません。

判定に応じて対応します：

• APPROVE： フェーズ 5 に進みます。
• CONCERNS： 「テクニカルディレクターから懸念が示されました。どのように進めますか？」と尋ねます。選択肢：指摘されたルールを修正する / 受け入れて続行する / さらに話し合う。
• REJECT： 何も書き込まず、指摘されたルールを修正して、要約を再度表示します。
• NOT ASSESSED： 承認ではありません（.claude/docs/director-gates.md）。不足している内容を明示してから補い、レビューを再実行します。または、ユーザーがレビューなしで続行することを選んだ場合は、フェーズ 5 に進み、返信と最終判定行に TD-MANIFEST: NOT ASSESSED — [input] と記載します。

フェーズ 5：コントロールマニフェストを書き込む

「コントロールマニフェストを docs/architecture/control-manifest.md に書き込んでもよいですか？」と尋ねます。 選択肢：はい、書き込む / まず完全なドラフトを表示してから、再度尋ねる / まだ書き込まない — 変更を追加したい。明確な「はい」の場合にのみ書き込みます。

# Control Manifest

> **Engine**: [name + version]
> **Last Updated**: [date]
> **Manifest Version**: [date]
> **ADRs Covered**: [ADR-NNNN, ADR-MMMM, ...]
> **Status**: Active — regenerate with `/create-control-manifest update` when ADRs change

`Manifest Version` is the date this manifest was generated. Stories embed it when
they are written, and `/story-readiness` compares a story's version with this one
to find stories written against old rules. It always equals `Last Updated`: the
same date, for different readers.

This manifest is a programmer's quick reference taken from the Accepted ADRs, the
technical preferences and the engine reference docs. For the reason behind a rule,
read its ADR.

---

## Foundation Layer Rules

*Applies to: scene management, event architecture, save/load, engine start-up*

### Required Patterns
- **[rule]** — source: [ADR-NNNN]

### Forbidden Approaches
- **Never [anti-pattern]** — [brief reason] — source: [ADR-NNNN]

### Performance Guardrails
- **[system]**: max [N]ms/frame — source: [ADR-NNNN]

---

## Core Layer Rules

*Applies to: core gameplay loop, main player systems, physics, collision*

### Required Patterns
...

### Forbidden Approaches
...

### Performance Guardrails
...

---

## Feature Layer Rules

*Applies to: secondary mechanics, AI systems, secondary features*

### Required Patterns
...

### Forbidden Approaches
...

---

## Presentation Layer Rules

*Applies to: rendering, audio, UI, VFX, shaders, animations*

### Required Patterns
...

### Forbidden Approaches
...

---

## Global Rules (All Layers)

### Naming Conventions
| Element | Convention | Example | Source |
|---------|-----------|---------|--------|
| Classes | [convention] | [example] | [`naming.classes` in project.yaml, or technical-preferences.md] |
| Variables | [convention] | [example] | [`naming.variables` in project.yaml, or technical-preferences.md] |
| Signals/Events | [convention] | [example] | [`naming.signals` in project.yaml, or technical-preferences.md] |
| Files | [convention] | [example] | [`naming.files` in project.yaml, or technical-preferences.md] |
| Constants | [convention] | [example] | [`naming.constants` in project.yaml, or technical-preferences.md] |

### Performance Budgets
| Target | Value | Source |
|--------|-------|--------|
| Framerate | [value] | [`performance.target_framerate` in project.yaml, or technical-preferences.md] |
| Frame budget | [value] | [`performance.frame_budget_ms` in project.yaml, or technical-preferences.md] |
| Draw calls | [value] | [`performance.draw_call_limit` in project.yaml, or technical-preferences.md] |
| Memory ceiling | [value] | [`performance.memory_ceiling_mb` in project.yaml, or technical-preferences.md] |

### Approved Libraries / Addons
- [library] — approved for [purpose] — source: technical-preferences.md

### Forbidden APIs ([engine version])
These APIs are deprecated or unverified for [engine + version]:
- `[api name]` — deprecated since [version] / unverified post-cutoff
- Source: `docs/engine-reference/[engine]/deprecated-apis.md`

### Cross-Cutting Constraints
- [constraint that applies in every layer] — source: [ADR-NNNN, preference key or engine-reference file]

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

• エピックがまだない場合：「/create-epics layer: foundation を実行してから、/create-stories [epic-slug] を実行してください。ストーリーには、このマニフェストのルールとバージョンが埋め込まれます。」
• 再生成の場合：「更新しました。変更されたルール、特に新しい Forbidden エントリについて、チームに伝えてください。」

各ルールは ADR、技術的な設定、またはエンジンのリファレンス文書に必ず紐づいています。ルールを捏造せず、意味が変わるような言い換えもしていません。書き込み後は Verdict: COMPLETE — control manifest written で締めくくり、書き込みが拒否された場合は Verdict: BLOCKED — user declined the write で締めくくります。