cook-auto-parallel

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

批判的思考の姿勢 — 批判的思考と逐次的思考を適用してください。すべての主張について根拠をたどり、確信度が 80% を超えてから実行してください。 ハルシネーション対策： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性は率直に認め、出力に誤りがないか自己確認し、独立して相互参照し、自分の確信度にも懐疑的でいてください。根拠のない確信は、あらゆるハルシネーションの根源です。

AI のミス防止 — すべての作業で避けるべき失敗パターン：

• 削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードの陳腐化が連鎖的に発生します。削除する前に、参照しているすべてのファイルを洗い出してください。
• AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で実在を確認してください。
• 編集後は依存関係を最後までたどってください。 定義を変更しても、そこから派生する下流の変数や利用箇所を見落とすことがあります。依存関係を最後までたどってください。
• 正しさを検証する際は、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることの確認にはなりません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップも必ずたどってください。
• デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグの原因が呼び出し元（誤ったデータ）にあるのか、呼び出し先（誤った処理）にあるのかをたどってください。責任のあるレイヤーで修正し、症状が現れた箇所だけを修正しないでください。
• 既存の値には意図があると考え、変更前に理由を確認してください。 定数、制限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。
• 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 複数のスタックに影響する変更では、すべての出力を検証する必要があります。チェックが 1 つ成功しても、すべて成功したとは限りません。
• 全体を先に見るデバッグ — 目につきやすい箇所に飛びつかないでください。 失敗を調査する際は、コードレイヤーの仮説を立てる前に、すべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）を列挙し、それぞれを根拠と照合してください。
• 変更は必要最小限に — 差分テストを適用してください。 バグ修正では、変更するすべての行がそのバグに直接結び付いていなければなりません。隣接するコードのスタイル変更や改善はしないでください。機能強化の作業では、改善を実装し、その内容を明示してください。
• コーディング前に曖昧さを明らかにしてください — 黙って解釈を決めないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりとともに提示し、確認してください。全レコード対象、ファイルベース、またはより複雑な方法を、決めつけて選ばないでください。

まずコードを理解する — 厳格な前提条件：既存のコードを読むまでは、記述、計画、修正をしてはいけません。

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 が存在する場合） - [ ] 仮定を根拠に基づいて検証する

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関係、サービス間同期（作業がビジネスエンティティ／モデルに関わる場合に読む）（内容はフックによって自動挿入されます。読む前に [Injected: ...] ヘッダーを確認してください）
• docs/specs/ — モジュール別のテスト仕様（既存の TC を読み、実装後に /tdd-spec でテスト仕様を生成／更新する）

計画の品質 — すべての計画フェーズに、必ず注意してテスト仕様を含める必要があります。

1. すべてのフェーズファイルに、TC-{FEAT}-{NNN} IDを含む ## Test Specifications セクションを追加します
2. すべての機能要件を1つ以上のTCに対応付けます（または、根拠を添えて明示的に TBD とします）
3. TC IDは TC-{FEATURE}-{NNN} 形式に従います。内容全体を埋め込まず、IDで参照します
4. 新しいワークフローステップを実行する前に、TaskList を呼び出し、フェーズファイルを読み直します
5. コンテキストの圧縮時は、最初に TaskList を呼び出します。タスクを重複して作成してはいけません
6. 完了とする前に、フェーズごとにTCの充足を検証します（根拠にはTBDではなく file:line を指定します）

モード： TDD優先 → 既存のTCを Evidence: TBD として参照します。実装優先 → TBDを使用し、後から /tdd-spec で補完します。

言い訳の防止 — AIは次のような回避策で手順を省略します。見抜いて拒否してください：

回避策	反論
「計画を立てるほど複雑ではない」	単純な作業でも、前提が誤っていれば時間を無駄にします。必ず計画してください。
「あとでテストします」	GREENの前にREDです。まずテストを書き、検証してください。
「すでに検索しました」	file:line 付きのgrepの証拠を示してください。証拠がなければ、検索していないのと同じです。
「とにかく実行します」	それでも TaskCreate が必要です。詳細度は下げても、追跡を省略してはいけません。
「小さな修正です」	間違った場所への小さな修正が、連鎖的な問題を引き起こします。まず file:line を検証してください。
「コードを見れば分かります」	将来の読者には根拠の追跡記録が必要です。必ず記録してください。
「時間短縮のために手順をまとめます」	手順をまとめると焦点がぼやけます。各手順にはそれぞれ異なる目的があります。

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

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

ユーザーから明示的な承認を得ずに、危険信号を無視して先へ進んではいけません。

スキルのバリアント： /cook のバリアント — fullstack-developerサブエージェントによる自律的な並列実行です。

簡単な概要

目標： 並列実行可能なフェーズを計画し、fullstack-developerサブエージェントに割り当てて並行実装します。

ワークフロー：

1. 計画 — 並列実行可能なフェーズを含む計画を作成します（ファイルの所有権を厳密に分けます）
2. 割り当て — フェーズごとにfullstack-developerサブエージェントを起動します
3. 統合 — 結果を統合して検証します

主なルール：

• 各サブエージェントは特定のファイルを担当し、担当範囲を越えて編集してはいけません
• 自律モード：フェーズ間でユーザー確認を求めません
• 作業をTODOタスクに分割し、最後に自己レビューのタスクを追加します

Ultrathinkで並列に 実装します：$ARGUMENTS

重要： 必要なスキルを有効にしてください。トークン効率を確保してください。簡潔さを優先し、文法にはこだわりすぎないでください。

懐疑的な姿勢で、批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な証拠と確信度（アイデアは80%超）が必要です。

ワークフロー

1. 調査（任意）

• タスクが複雑な場合は、researcher エージェントを最大2つまで並行して使用します
• /scout-ext を使用してコードベースを検索します
• レポートは150行以内にします
• 外部メモリ： 調査結果を .ai/workspace/analysis/{task-name}.analysis.md に書き込みます。並列実行の前に読み直します。

2. 並列計画

• /plan-parallel <detailed-instruction> を呼び出します
• 依存関係グラフ、実行戦略、ファイル所有権マトリクスを含む計画を待ちます

3. 並行実装

• 依存関係グラフを確認するため、plan.md を読みます
• 並行フェーズを同時に進めるため、複数の fullstack-developer エージェントを並列で起動します
  • 例：「フェーズ 1～3 を並列で」→ エージェントを 3 つ同時に起動します
  • フェーズファイルのパスを渡します：{plan-dir}/phase-XX-*.md
  • 環境情報を含めます
• 依存するフェーズに進む前に、並列フェーズがすべて完了するまで待ちます
• 順次実行するフェーズでは、一度に 1 つのエージェントを起動します

4. テスト

• テストスイート全体の実行には tester サブエージェントを使用します
• 偽のデータ／モック／不正な近道は使用しません
• 失敗した場合：debugger を使って修正し、再実行します

5. コードレビュー

• すべての変更に code-reviewer を使用します
• 重大な問題がある場合：修正して再テストします

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

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

7. 最終レポート

• すべての並列フェーズの概要
• 開始方法のガイド
• コミットするかユーザーに確認します（「はい」の場合は git-manager を使用します）

例： フェーズ 1～3 を並列で実施 → fullstack-developer エージェントを 3 つ起動 → 待機 → フェーズ 4 を順次実施

---

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

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

• 「完全なワークフローを進める（推奨）」 — ここから続けるのに最適なワークフローを検出します（機能は実装済みです）。これにより、レビュー、テスト、ドキュメントの手順を省略せずに済みます。
• 「/code-simplifier」 — 実装を簡素化し、整理します
• 「/workflow-review-changes」 — コミット前に変更をレビューします
• 「スキップして手動で続行」 — ユーザーが決定します

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

終了時の注意事項

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

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

• 必須・重要・必ず注意 すべての主張について file:line 形式の根拠を示してください（確信度が 80% を超える場合に実行）

• 必須・重要・必ず注意 作業品質を確認するため、最後のレビュー用 ToDo タスクを追加してください

• 必須・重要・必ず注意 AskUserQuestion を使ってユーザーに判断を確認してください。自動で判断してはいけません

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

• 必須・重要・必ず注意 各フェーズに TC ID 付きの ## Test Specifications を含めてください。タスクを新しく作成する前に TaskList を呼び出してください。

• 必須・重要・必ず注意 簡単に見えるかどうかにかかわらず、すべての手順に従ってください。「計画するほどでもないほど簡単」というのは回避であり、理由にはなりません。

• 必須・重要・必ず注意 修正の試行が 3 回失敗したら停止してください。すべての試行を報告し、続行する前にユーザーに確認してください。

• 必ず注意 批判的思考を適用してください。すべての主張には追跡可能な根拠が必要です。実行するのは確信度が 80% を超える場合に限ります。ハルシネーション防止：推測を事実として提示してはいけません。

• 必ず注意 AI の誤りを防ぐため、全体を先に見てデバッグし、責任のあるレイヤーで修正し、コーディング前に曖昧さを明らかにし、コンテキストの圧縮後にファイルを読み直してください。

[TASK-PLANNING] 実行する前にタスクの範囲を分析し、TaskCreate を使って小さな ToDo タスクとサブタスクに体系的に分割してください。