fix-fast

［IMPORTANT］ 作業を開始する前に、TaskCreate を使用して、ファイルを読む作業も含め、すべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI はスキップするかどうかを必ずユーザーに確認してください。

まずコードを理解する — 厳格な必須条件：既存のコードを読むまでは、記述、計画、修正を行わないでください。

1. 類似パターンを3つ以上検索します（grep／glob）。根拠として file:line を示してください
2. 対象領域の既存ファイルを読み、構造、基底クラス、規約を理解します
3. .code-graph/graph.db が存在する場合は、python .claude/scripts/code_graph trace <file> --direction both --json を実行します
4. connections または callers_of を使って依存関係を把握し、対象に依存するものを確認します
5. 重要なタスク（3ファイル以上）の調査内容を .ai/workspace/analysis/ に記録します
6. 実装前に分析ファイルを読み直します。記憶だけに頼って作業してはいけません
7. 既存のパターンが使える場合、新しいパターンを決して作らないでください。既存のものに厳密に従うか、逸脱を記録します

以下が完了するまで作業は禁止です： - [ ] 対象ファイルを読んだ - [ ] 3つ以上のパターンをgrepで検索した - [ ] グラフをトレースした（graph.db が存在する場合） - [ ] 仮定を根拠に基づいて検証した

根拠に基づく推論 — 推測は禁止です。すべての主張には証拠が必要です。

1. すべての主張に file:line、grep の検索結果、またはフレームワークのドキュメントを根拠として示します
2. 確信度を明示します：80%超なら自由に進め、60～80%なら先に検証し、60%未満なら推奨してはいけません
3. アーキテクチャの変更には、サービス間の検証が必須です
4. 「証拠が不十分です」は妥当であり、期待される回答です

以下が完了するまで作業は禁止です： - [ ] 根拠のファイルパス（file:line） - [ ] grep検索を実施した - [ ] 類似パターンを3つ以上見つけた - [ ] 確信度を明示した

証拠なしに使用してはいけない表現： "明らかに"、"私はそう思います"、"～のはずです"、"おそらく"、"これは～が原因です" 未完了の場合 → 次のように出力します："証拠が不十分です。検証済み：[...]。未検証：[...]。"

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関係、サービス間同期（タスクにビジネスエンティティ／モデルが関係する場合に読みます）（内容はフックによって自動挿入されます。読む前に [Injected: ...] ヘッダーがあるか確認してください）

見積もり — 修正フィボナッチ数列：1（ごく簡単）→ 2（小規模）→ 3（中規模）→ 5（大規模）→ 8（非常に大規模）→ 13（エピック、分割を推奨）→ 21（分割が必須）。計画のフロントマターに story_points と complexity を出力します。複雑度は自動算出されます：1～2＝低、3～5＝中、8＝高、13以上＝重大。 修正レイヤーの責任 — クラッシュした箇所では絶対に修正しないでください。フロー全体をたどり、責任を持つレイヤーで修正してください。

AI のデフォルトの動作：場所 A でエラーを確認 → 場所 A を修正。これは誤りです。クラッシュ箇所は症状であり、原因ではありません。

修正を行う前に必ず実施すること：

1. データフロー全体をたどる — すべてのレイヤー（ストレージ → バックエンド → API → フロントエンド → UI）を通る、データの発生元からクラッシュ箇所までの完全な経路をマッピングします。不正な状態がクラッシュする箇所ではなく、どこで入り込むかを特定してください。
2. 不変条件の所有者を特定する — この値が有効であることを保証する契約を持つのは、どのレイヤーですか。そのレイヤーが責任を負います。不変条件を所有する最下層で修正してください。不変条件を利用する最上層ではありません。
3. 修正は1つ、保護は最大限に — 「ここで修正すれば、1回の変更ですべての下流の利用者を保護できるか」と確認します。防御チェックのために3つ以上のファイルを変更する必要があるなら、レイヤーを間違えています。さらに下層で修正してください。
4. 迂回経路がないことを検証する — すべてのデータフローが修正箇所を通ることを確認します。以下を確認してください：ファクトリーを介さない直接生成、再検証を伴わないクローン／スプレッド、ドメインモデルでラップされていない生データ、モデルレイヤー外での変更。

以下が完了するまで作業を進めないでください： - [ ] データフロー全体を追跡した（発生元 → クラッシュ） - [ ] 不変条件の所有者を file:line の根拠とともに特定した - [ ] すべてのアクセス箇所を監査した（grep 件数） - [ ] 修正レイヤーを正当化した（最も多くの利用者を保護する最下層）

アンチパターン（次の方法は却下してください）：

• 「クラッシュした箇所で修正する」— クラッシュ箇所 ≠ 原因箇所です。上流をたどってください。
• 「すべての利用箇所に防御チェックを追加する」— 防御を分散させるのはレイヤーの選択が誤っている証拠です。権威ある修正を1つ行うほうが、ガードを各所に分散させるより優れています。
• 「両方修正するほうが安全」— 権威あるレイヤーを1つ選んでください。複数のレイヤーに重複するチェックを置くと、不変条件の所有者について矛盾したメッセージになります。

スキルのバリアント： /fix のバリアントです。調査を最小限に抑えた迅速な修正を行います。

簡単な概要

目標： 調査にかかる時間を最小限に抑え、規模が小さく十分に理解されている問題を迅速に修正します。

ワークフロー：

1. 特定 — エラーメッセージから根本原因を迅速に分析します
2. 修正 — 対象を絞った修正を直接適用します
3. 検証 — 影響を受けるテストを実行して確認します

主なルール：

• デバッグの考え方：すべての主張に file:line の根拠が必要です
• 単純で独立したバグにのみ使用します。複雑な問題は /fix-hard にエスカレーションしてください
• 調査時間を最小限にします。数分以内に根本原因が明らかにならない場合は、エスカレーションしてください

根本原因のデバッグ — 推測や試行錯誤を避け、体系的に進めます。

1. 再現 — 根拠（エラーメッセージ、スタックトレース、スクリーンショット）を用いて問題の存在を確認します
2. 切り分け — 二分探索とグラフトレースを使い、対象のファイル／関数／行を絞り込みます
3. 追跡 — 入力から失敗箇所までデータフローをたどります。推測せず、実際のコードを読んでください。
4. 仮説を立てる — 確信度（％）を添えて仮説を立てます。それを裏付ける、または否定する根拠を示してください
5. 検証 — 対象を絞った grep／読み取りで仮説を検証します。一度に変更する変数は1つにしてください。
6. 修正 — 症状ではなく根本原因に対処します。グラフの connections を通じて呼び出し元が壊れていないことを検証してください

絶対に行わないこと： 根拠なしに推測する。原因ではなく症状を修正する。再現手順を省略する。

スキルカタログを分析し、作業中に必要なスキルを有効にしてください。

デバッグの考え方（必須）

懐疑的な姿勢を保ち、批判的思考と順序立てた思考を適用してください。すべての主張に追跡可能な証拠と確信度を示してください（Idea は80％を超える必要があります）。

• 最初の仮説が正しいと決めつけず、実際のコードをたどって検証してください
• 根本原因に関するすべての主張に file:line の根拠を含めてください
• コードをたどって根本原因を証明できない場合は、「仮説であり、未確認」と述べてください
• 前提を疑ってください：「本当にこれが原因か？」→ 実際の実行経路をたどってください
• 網羅性を検証してください：「ほかに要因はないか？」→ 関連するコードパスを確認してください
• 「修正されるはず」で済ませず、修正が追跡した根本原因に対処していることを検証してください

⚠️ 必須：信頼度と証拠のゲート

必須・重要・要注意： すべての主張について、証拠リストと file:line の根拠を添えて Confidence: X% を示してください。 95％以上なら自由に推奨 | **80～94％**なら留保事項を添える | **60～79％**なら不明点を列挙 | 60％未満なら停止して、さらに証拠を集める。

ミッション

これらの問題を分析して修正するため、深く考えてください： $ARGUMENTS

⚠️ 修正前の検証（必須）： 根本原因の分析後、必ず AskUserQuestion を使って調査結果と修正案をユーザーに提示し、コードを変更する前に明示的な承認を得てください。黙って修正してはいけません。

ワークフロー

1. ユーザーがスクリーンショットや動画を提供した場合は、ai-multimodal スキルを使って問題をできるだけ詳しく説明し、その説明から開発者が根本原因を容易に予測できるようにしてください。
2. debugger サブエージェントを使って問題の根本原因を特定し、メインエージェントに報告してください。 2.5. 根本原因の分析を .ai/workspace/analysis/{issue-name}.analysis.md に書き込みます。修正を実装する前に、もう一度読み直してください。
3. debug-investigate スキルと problem-solving スキルを有効にして、問題に取り組んでください。
4. 🛑 根本原因と修正案を提示 → AskUserQuestion → ユーザーの承認を待つ。
5. 報告と解決策に基づいて、修正の実装を開始してください。
6. tester エージェントを使って修正をテストし、動作することを確認してから、メインエージェントに報告してください。
7. 問題がある場合やテストに失敗した場合は、ステップ2から繰り返してください。
8. 完了後、変更内容の概要をユーザーに伝え、すべてを簡潔に説明し、利用開始の方法と次のステップを案内してください。

• 修正後は、必ず /prove-fix を実行してください — 変更ごとに信頼度スコア付きのコード証拠トレースを作成します。省略してはいけません。

---

次のステップ（単独実行時：必ずユーザーに AskUserQuestion で確認してください。ワークフロー内の場合は省略。）

必須・重要・要注意 — 例外なし： このスキルがワークフロー外で呼び出された場合、必ず AskUserQuestion を使って次の選択肢を提示してください。タスクが「簡単」または「明白」に思えても省略してはいけません。決めるのはユーザーです。

• 「完全なワークフローを続行（推奨）」 — ここから続けるのに最適なワークフローを検出します（修正は適用済み）。これにより、prove-fix、レビュー、テスト、ドキュメントの手順を省略せずに済みます。
• 「/prove-fix」 — コードトレースで修正の正しさを証明する
• 「/test」 — テストを実行して修正を検証する
• 「スキップして手動で続行」 — ユーザーが決定します

すでにワークフロー内にいる場合は省略してください。ワークフローが順序を管理します。

最後の注意事項

• 重要・要注意： 作業を始める前に TaskCreate を使って、作業を小さなタスクに分割してください。

• 重要・要注意： 新しいコードを作成する前に、コードベース内の類似パターンを3つ以上検索してください。

• 重要・要注意： すべての主張に file:line の証拠を引用してください（行動する場合は信頼度80％超）。

• 重要・要注意： 作業品質を検証する最終レビューのタスクを追加してください。

• 重要・要注意： 修正に3回失敗したら停止してください。結果を報告し、4回目に進む前にユーザーに確認してください。 必須・重要・要注意： 作業を始める前に、次のファイルを読み込んでください：

• 重要・要注意： 変更を加える前に、既存パターンを3つ以上検索してコードを読んでください。graph.db が存在する場合は、グラフトレースを実行してください。

• 重要・要注意： すべての主張に file:line の証拠を引用してください。信頼度80％超で行動し、60％未満の場合は推奨しないでください。

• 重要・要注意： 計画のフロントマターに story_points と complexity を含めてください。SP が8を超える場合は分割してください。

• 重要・要注意： データフロー全体をトレースし、クラッシュ箇所ではなく担当レイヤーで修正してください。?. を追加する前に、すべてのアクセス箇所を監査してください。