fix-parallel

[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以上＝重大。

危険信号による停止条件 — 以下の場合は作業を停止し、AskUserQuestion を通じてユーザーにエスカレーションしてください。

1. 重要な判断で確信度が60%未満になった
2. 変更の影響が20ファイルを超える（影響範囲が大きすぎる）
3. サービス境界をまたぐ
4. セキュリティ上重要なコード（認証、暗号化、PII の取り扱い）
5. 破壊的変更が検出された（インターフェース、API コントラクト、DB スキーマ）
6. 変更後にテストカバレッジが低下する
7. プロジェクトに存在しない技術／パターンが必要になる

ユーザーの明示的な承認なしに、危険信号を無視して作業を続行してはいけません。

スキルのバリエーション： /fix のバリエーション — サブエージェントを使用した、複数の課題の並列解決。

クイックサマリー

目標： 複数の独立した問題を、並列のフルスタック開発サブエージェントを使って同時に修正します。

ワークフロー：

1. トリアージ — 問題を分類し、独立していることを確認します（共有ファイルがないこと）
2. 割り当て — 厳密なファイル所有権を設定して、並列サブエージェントに問題を割り当てます
3. 実行 — サブエージェントがそれぞれ独立して問題を修正します
4. マージ — すべての修正をレビューして統合します

重要なルール：

• デバッグの基本姿勢：すべての主張に file:line の根拠が必要です
• 問題は必ず独立していなければなりません（変更対象のファイルが重複しないこと）
• 各サブエージェントは特定のファイルを担当し、担当範囲を越えて編集してはいけません

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

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

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

フロントエンド／UI のコンテキスト（該当する場合）

このタスクでフロントエンドまたは UI の変更が必要な場合、

UI システムのコンテキスト — .ts、.html、.scss、.css ファイルに触れるすべてのタスクで：

実装前に必ず確認してください：

1. docs/project-reference/frontend-patterns-reference.md — コンポーネントの基底クラス、ストア、フォーム
2. docs/project-reference/scss-styling-guide.md — BEM の方法論、SCSS 変数、ミックスイン、レスポンシブ対応
3. docs/project-reference/design-system/README.md — デザイントークン、コンポーネント一覧、アイコン

プロジェクト固有のパスは docs/project-config.json を参照してください。

• コンポーネントのパターン：docs/project-reference/frontend-patterns-reference.md
• スタイリング／BEM ガイド：docs/project-reference/scss-styling-guide.md
• デザインシステムのトークン：docs/project-reference/design-system/README.md

デバッグの基本姿勢（必須）

懐疑的になり、批判的かつ順序立てて考えてください。すべての主張に追跡可能な証拠と確信度（仮説は80％超）が必要です。

• 最初の仮説が正しいと思い込まず、実際のコードをたどって検証してください
• 根本原因についてのすべての主張に file:line の根拠を含めてください
• コードを追跡して根本原因を証明できない場合は、「仮説であり、未確認」と明記してください
• 前提を問い直してください。「本当にこれが原因か？」→ 実際の実行経路を追跡します
• 完全性を確かめてください。「ほかに要因はないか？」→ 関連するコード経路を確認します
• 「これで直るはず」で終わらせず、修正が追跡して特定した根本原因に対処していることを検証してください

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

すべての主張について、証拠の一覧と file:line の証明を添えて、必ず Confidence: X% を明記してください。 95％以上なら自由に推奨できます。**80～94％**なら但し書きを添えます。**60～79％**なら不明点を列挙します。60％未満なら中断し、証拠をさらに集めます。

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

修正に向けて超並列で思考：$ARGUMENTS

重要： 必要なスキルを有効にしてください。トークン効率を意識してください。簡潔さを優先し、文法は犠牲にしてかまいません。

ワークフロー

1. 問題の分析

• 根本原因の分析には debugger サブエージェントを使います
• 関連ファイルの特定には /scout-ext を使います
• 問題をスコープや領域（フロントエンド、バックエンド、認証、決済など）ごとに分類します
• 問題間の依存関係を特定します
• 外部メモリ：並列エージェントはそれぞれ、調査結果を .ai/workspace/analysis/{issue-name}-{agent}.analysis.md に記録します。修正の調整前に、メインエージェントがすべての記録を読み直します。

2. 並列修正計画

• /plan-parallel <detailed-fix-instructions> を実行し、並列実行可能な修正計画を作成します
• 依存関係グラフ、実行戦略、ファイル所有権マトリックスを含む計画を待ちます
• 独立した修正をグループ化して並列実行します
• 依存する問題の修正は順番に実行します
• 🛑 エージェントを起動する前に、根本原因と修正計画を提示 → AskUserQuestion → ユーザーの承認を待ちます。

3. 並列修正の実装

• plan.md で依存関係グラフを確認します
• 独立した修正には、複数の fullstack-developer エージェントを並列で起動します
  • 例：「認証の修正 + 決済の修正 + UI の修正」→ 3 つのエージェントを同時に起動します
  • フェーズのファイルパスを渡します：{plan-dir}/phase-XX-*.md
  • 環境情報を含めます
• 依存する修正を開始する前に、並列修正がすべて完了するのを待ちます
• 順次修正の場合は、エージェントを 1 つずつ起動します

サブエージェントのコンテキスト管理：

• タスクの全文を提示する — タスク内容をサブエージェントへのプロンプトに貼り付けます。サブエージェントに計画ファイルを読ませないでください
• 「開始前に質問する」 — サブエージェントは、実装前に不明点を提示する必要があります
• 報告前にセルフレビューする — サブエージェントは結果を返す前に、完全性、品質、YAGNI を確認します

4. テスト

• テストスイート全体には tester サブエージェントを使用します
• 偽のデータ／モック／不正な回避策は禁止です
• すべての問題が解決したことを確認します
• 失敗した場合は、debugger を使用して修正し、再度テストします

5. コードレビュー

2 段階のタスクレビュー — タスク完了とする前に、両方の段階を必ず完了してください。

ステージ 1：セルフレビュー — 実装直後に実施します。

• 要件を満たしているか？ リグレッションはないか？ コードの品質に問題はないか？

ステージ 2：クロスレビュー — code-reviewer サブエージェントを通じて実施します。

• 見落とし、規約からの逸脱、考慮漏れのエッジケースを検出します

ステージ 2 を省略しないでください。 セルフレビューだけでは、40％以上の問題を見逃します。

1. 最初に、`spec-compliance-reviewer` を割り当てて、各修正が仕様に適合していることを確認します
2. 仕様に適合した後にのみ、品質レビューのため `code-reviewer` を割り当てます

• 修正によってリグレッションが発生していないことを確認します
• 重大な問題がある場合は、修正して再テストします

6. プロジェクト管理とドキュメント

• 承認された場合は、project-manager と docs-manager を並列で使用します
• 計画ファイル、ドキュメント、ロードマップを更新します
• 承認されなかった場合は、修正して再度実施します

7. 修正の証明

• 必須： 並列で行った修正ごとに /prove-fix を実行します
• 変更ごとに、信頼度スコア付きのコード証明トレースを作成します
• 変更のいずれかのスコアが 80％未満の場合は、その修正のデバッグに戻ります

8. 最終レポート

• 並列フェーズで行ったすべての修正の概要
• 問題ごとの検証状況（prove-fix の信頼度スコアを含む）
• コミットするか尋ねます（はいの場合は git-manager を使用）

例： 修正 1（認証）+ 修正 2（決済）+ 修正 3（UI）→ 3 つの fullstack-developer エージェントを起動 → 完了を待つ → 各修正を証明 → 修正 4（統合）を順次実施

---

次のステップ（単独で実行する場合：必ず AskUserQuestion でユーザーに尋ねます。ワークフロー内の場合はスキップします。）

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

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

すでにワークフロー内の場合はスキップしてください。手順の順序はワークフローが管理します。

最後のリマインダー

• 必ず、重要、厳守 作業を始める前に、TaskCreate を使って作業を小さな TODO タスクに分割してください

• 必ず、重要、厳守 新しいコードを作成する前に、コードベース内で類似パターンを 3 つ以上検索してください

• 必ず、重要、厳守 あらゆる主張に file:line の根拠を示してください（信頼度が 80％ を超える場合に対応してください）

• 必ず、重要、厳守 作業の品質を確認するため、最後のレビュー TODO タスクを追加してください

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

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

• 必ず、重要、厳守 あらゆる主張に file:line の根拠を示してください。対応するには信頼度が 80％ を超えている必要があり、60％ 未満の場合は推奨しないでください。

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

• 必ず、重要、厳守 修正に 3 回失敗したら中止してください。すべての試行結果を報告し、続行する前にユーザーに確認してください。

• 必ず、重要、厳守 UI を変更する前に、frontend-patterns-reference、scss-styling-guide、design-system/README を読んでください。