perf-profile

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

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

パフォーマンスプロファイル

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

入力が不足している場合 — レポートを作成する前に確認

このスキルが必要とする入力が存在しない場合、回答は「実行できません」であり、入力を埋めたレポートではありません。 まず確認し、確認に失敗した場合は停止してください。

1. このスキルが読み取る入力（データファイル、以前のレポート、プロファイラーの出力、テスト結果、レジストリ、ソースコード）を列挙します。
2. それぞれについて、「存在すると想定」ではなく、FOUND または ABSENT を記録します。
3. セクションに必要な入力が1つでも ABSENT の場合、そのセクションは NOT ASSESSED — NO DATA です。推定したり、隣接する成果物から推論したり、次にテンプレートを読む人が記入する必須セルを未記入のままにしたりしないでください。
4. 必要な入力がすべて ABSENT の場合は停止し、不足しているものと、それを生成するスキルを示して、全体の判定として NOT ASSESSED — NO DATA を報告します。

NOT ASSESSED という判定は成功です。 データがないときに「データは何を示しているか」と尋ねられた場合の、正しく有用な回答です。これによって防ぐ失敗の形は明確です。判定の選択肢に「実行できません」がないレポートは、誤った問題なし判定を生みます。たとえば、アセットも基準もないプロジェクトのアセット監査が COMPLIANT を返したり、プロファイラーデータがなく、予算も一度も設定されていないのに、パフォーマンスプロファイルが「16.67ms の予算に対して >99% の余裕」と報告したりするケースです。

証拠がないことは、不在の証拠ではありません。 スキャン対象のファイルがないために一致が見つからなかったスキャンは、何も検証していません。どちらが起きたのかを明記してください。結果が緑色で表示されているだけでは、読み手は判断できません。

---

フェーズ 0：予算の適用方法を解決する

performance.enforce は、この実行で予算超過が何を意味するかを決定します。測定する予算は変更しません。performance.target_framerate、frame_budget_ms、draw_call_limit、memory_ceiling_mb は、どのレベルでも同じ方法でプロファイリングされます。

値	このプロファイルの検出結果への影響
warn（デフォルト）	超過は検出結果として報告されます。ブロックはしません。CI は失敗せずにログへ記録します。
block	超過はブロッカーです。レポートで明示してください。block のプロジェクトでは、予算超過のシステムはリリースを停止させるものとして扱われ、/gate-check はそれによって Polish ゲートを FAIL にします。
off	予算は情報提供のみです。測定値は引き続き報告しますが、超過を検出結果や修正の推奨事項として挙げないでください。

認識される値は warn、block、off のみです。それ以外の値があればユーザーに提示し、推測せずに warn にフォールバックしてください。

この値はローカルで上書き可能です（/settings --local performance.enforce=block）。そのため、project.yaml を読み取るのではなく、上記で解決されたブロックを使用してください。チームメイトのより厳しいローカル設定は、その人のマシンでのみ適用される想定です。

フェーズ 1：スコープを決定する

引数を読み取ります。

• システム名 → その特定のシステムに絞ってプロファイリングします
• full → すべてのシステムを対象に包括的なプロファイルを実行します

---

フェーズ 2：パフォーマンス予算を読み込む

まず、コミット済みの予算を設定ファイルから読み込みます。これらはプロジェクトが合意した内容を記録したものであり、設計ドキュメントはあくまで代替情報で、情報源ではありません。

bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" get_effective_yaml_key performance.target_framerate
bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" get_effective_yaml_key performance.frame_budget_ms
bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" get_effective_yaml_key performance.draw_call_limit
bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" get_effective_yaml_key performance.memory_ceiling_mb

各行を個別のプレーンコマンドとして実行し、1 回の呼び出しにつき 1 つのキーを指定します。このヘルパーは自動的にプロジェクトのルートに移動するため、セッションをサブフォルダーから開始した場合でも動作します。また、このスキルで事前承認されているのはこの形式のみです（source や cd ... && でラップすると、毎回ユーザーへの確認が求められます）。出力が空の場合、その予算は設定されていません。

これらの予算は、文章ではなく project.yaml から解決してください。 上記のフェーズ 0 では、これら 4 つの予算は「どのレベルでも同じ方法でプロファイリングされる」としています。ユーザーが project.yaml で performance.target_framerate: 60 を設定していても、設計ドキュメントや CLAUDE.md から予算を読み込むと、その設定は無視されます。

設定にない情報については、設計ドキュメントまたは CLAUDE.md を参照します。

• 目標 FPS（例：60fps = フレーム予算 16.67ms）
• メモリ予算（合計およびシステムごと）
• 読み込み時間の目標
• ドローコールの予算
• ネットワーク帯域幅の上限（マルチプレイヤーの場合）

コミット済みの予算がない指標は、合格ではなく NOT ASSESSED です。 テンプレートの [16.67ms] というプレースホルダーを基準に測定してはいけません。未設定の予算は、達成済みの予算ではありません。誰も選んでいない数値に対する余裕を報告することこそ、このスキル自身のヘッダーが警告している捏造です。

---

フェーズ 3：コードベースを分析する

CPU プロファイリングの対象：

• _process() / Update() / Tick() 関数 — すべて列挙し、コストを推定します
• 大規模なコレクションを走査するネストされたループ
• ホットパス内の文字列操作
• フレームごとのコードにおけるメモリ割り当てのパターン
• 最適化されていない、ゲームエンティティに対する検索／ソート
• 毎フレーム実行される高コストな物理クエリ（レイキャスト、オーバーラップ）

メモリプロファイリングの対象：

• 大規模なデータ構造と、その増加パターン
• テクスチャ／アセットのメモリ使用量の推定
• オブジェクトプールと、インスタンス生成／破棄のパターン
• 解放されるべきなのに解放されていないオブジェクトなど、リークした参照
• キャッシュサイズと削除ポリシー

レンダリングの対象（該当する場合）：

• ドローコールの推定
• 透明なオブジェクトの重なりによるオーバードロー
• シェーダーの複雑さ
• 最適化されていないパーティクルシステム
• LOD やオクルージョンカリングの欠如

I/O の対象：

• 保存／読み込みのパフォーマンス
• アセット読み込みのパターン（同期／非同期）
• ネットワークメッセージの頻度とサイズ

---

フェーズ 4：プロファイリングレポートを作成する

レポートは production/polish/[scope]-report-[date].md に書き込みます。まず、コラボレーションプロトコルに従って、「このプロファイリングレポートを production/polish/[scope]-report-[date].md に書き込んでもよいですか？」と確認します。ディレクトリが存在しない場合は作成します。

保存先を明示してください。テンプレートを会話に表示するだけではいけません。 トランスクリプトにしか存在しないプロファイルは、セッションが終了した時点で失われ、複数回の実行結果を比較できません。production/polish/ は /team-polish が書き込む場所と同じです。意図的に同じ場所にしてあります。どちらの方法で取得したプロファイルも一か所に保存しなければ、このスキルの目的である比較ができません。

レポートに NOT ASSESSED のセクションが残る場合は、書き込むファイルにもそのまま残してください。ディスクに保存する過程で不足部分が削除されたプロファイルは、後になって完全な測定結果のように見えてしまいます。

## Performance Profile: [System or Full]
Generated: [Date]

### Performance Budgets
| Metric | Budget | Estimated Current | Status |
|--------|--------|-------------------|--------|
| Frame time | [16.67ms] | [estimate] | [OK/WARNING/OVER/NOT ASSESSED] |
| Memory | [target] | [estimate] | [OK/WARNING/OVER/NOT ASSESSED] |
| Load time | [target] | [estimate] | [OK/WARNING/OVER/NOT ASSESSED] |
| Draw calls | [target] | [estimate] | [OK/WARNING/OVER/NOT ASSESSED] |

### Hotspots Identified
| # | Location | Issue | Estimated Impact | Fix Effort |
|---|----------|-------|------------------|------------|

### Optimization Recommendations (Priority Order)
1. **[Title]** — [Description]
   - Location: [file:line]
   - Expected gain: [estimate]
   - Risk: [Low/Med/High]
   - Approach: [How to implement]

### Quick Wins (< 1 hour each)
- [Simple optimization 1]

### Requires Investigation
- [Area that needs actual runtime profiling to confirm impact]

レポートには概要を含め、上位 3 件のホットスポット、設定済みの各予算に対する推定余裕を記載します。予算が設定されていない指標には no budget set — headroom not assessed と記載し、次に推奨するアクションも示します。

---

フェーズ 5：スコープとタイムラインの決定

ホットスポットのいずれかで修正工数が M または L と評価された場合にのみ、このフェーズを有効にします。

工数が大きい項目を提示し、それぞれについてユーザーに選択してもらいます。

• A）最適化を実施する（今すぐ修正するか、予定に組み込みます。スプリントのない workflow: minimal の場合は、ブリーフのビルド順序に追加します）
• B）機能のスコープを縮小する（トレードオフを分析するため、/scope-check [feature] を実行します）
• C）パフォーマンスへの影響を受け入れ、Polish フェーズまで延期する（既知の問題として記録します）
• D）アーキテクチャ上の判断を technical-director にエスカレーションする（/architecture-decision を実行します）

複数の項目を Polish まで延期する場合（選択肢 C）、### Deferred to Polish の下に記録します。

---

判定

レポートを生成した実行はすべて、フェーズ 5 を実行したかどうかにかかわらず、次の内容で終了します。 Verdict: COMPLETE — パフォーマンスプロファイルを生成しました（書き込みが承認された場合は、 production/polish/[scope]-report-[date].md に保存されます）。ほかの結果は、前述の NOT ASSESSED — NO DATA のみです。

---

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

• ボトルネックにアーキテクチャの変更が必要な場合：/architecture-decision を実行します。
• スコープの縮小が必要な場合：/scope-check [feature] を実行します。
• 最適化を予定に組み込む場合：/sprint-plan update を実行します（スプリントのない workflow: minimal の場合は、代わりにブリーフのビルド順序に追加します）。

ルール

• 最初に測定せずに最適化してはいけません。パフォーマンスに関する直感は信頼できません。
• 推奨事項には影響の推定値を含める必要があります。「高速化する」だけでは実行可能な内容になりません。
• 開発マシンだけでなく、対象ハードウェアでプロファイリングしてください。
• 静的解析（このスキル）は候補を特定し、実行時プロファイリングで確認します。