cook-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 の充足を検証します（証拠には file:line を使い、TBD は使いません）

モード： 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 サブエージェントを使って同時に実装します。

ワークフロー：

1. 計画 — 並列フェーズと厳格なファイル所有権を含む計画を作成します
2. ディスパッチ — 各フェーズに fullstack-developer サブエージェントを起動します
3. マージ — すべての変更を統合して検証します
4. レビュー — code-simplifier を実行し、変更をレビューします

主なルール：

• 各フェーズのファイル所有権が重複しないようにします
• サブエージェントをディスパッチする前に、ユーザーの承認が必要です
• 作業を todo タスクに分割し、最後に自己レビューのタスクを追加します

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

効率を最大化するため、次のタスクを並行して実行してください： $ARGUMENTS

モード： PARALLEL — 複数のサブエージェントが同時に作業します。

ワークフロー

1. タスクの分解

• タスクの独立性を分析します
• 並列化できる作業単位にまとめます
• 作業単位間の依存関係を特定します
• 依存関係グラフを作成します
• 外部メモリ： タスクの分析を .ai/workspace/analysis/{task-name}.analysis.md に書き込みます。並列ディスパッチの前に再度読み込みます。

2. 並列調査（必要な場合）

researcher サブエージェントを複数同時に起動します。

Task A research ──┐
Task B research ──┼──► Synthesis
Task C research ──┘

3. 並列計画

• 統合した調査結果を使い、planner サブエージェントを利用します
• 並列実行に安全なフェーズを含む計画を作成します
• ファイル所有権の境界を明示し、競合を防ぎます

4. 並列実装

複数の fullstack-developer サブエージェントを起動します。

Phase 1 (Backend API) ──┐
Phase 2 (Frontend UI) ──┼──► Integration
Phase 3 (Tests)       ──┘

重要： 各サブエージェントは、割り当てられたファイル所有権の境界内で作業してください。

5. 統合とテスト

• 並行して出力された内容を統合します
• 統合テストには tester サブエージェントを使用します
• 統合上の問題が見つかった場合は debugger を使用します

6. レビューと報告

• 最終レビューには code-reviewer を使用します
• すべての変更をまとめます
• ユーザーに報告します

並列化のルール

ルール	説明
ファイルの担当	各サブエージェントが特定のファイルを担当し、重複しません
依存関係の順序	依存関係グラフに従います
最大同時実行数	競合を防ぐため、サブエージェントは最大3つです
同期ポイント	フェーズ間に統合チェックポイントを設けます

使用する場面

• 複数のコンポーネントにまたがる機能（バックエンド + フロントエンド）
• 独立したモジュールにまたがる大規模なリファクタリング
• テストの並行作成
• コードと並行して行うドキュメントの更新

タスク分割の例

"Add user authentication with login UI"
├── Backend API (subagent 1)
│   ├── auth-controller.ts
│   └── auth-service.ts
├── Frontend UI (subagent 2)
│   ├── login-page.component.ts
│   └── login-form.component.ts
└── Tests (subagent 3)
    ├── auth.spec.ts
    └── login.e2e.ts

トレードオフ

項目	並列	順次
速度	約2～3倍高速	基準
調整	より複雑	シンプル
競合	マージの問題が発生するリスク	なし
コンテキスト	エージェント間で分割	統一

---

次のステップ（単独実行時：必ずユーザーに 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 タスクとサブタスクに体系的に分割します。