cook-hard

[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 で補完します。

スキルのバリエーション： /cook のバリエーションです。徹底的な実装と最大限の検証を行います。

クイックサマリー

目標： 詳細な調査、包括的な計画、最大限の品質検証を通じて機能を実装します。

ワークフロー：

1. 調査 — 複数のリサーチャーサブエージェントを使った詳細な調査
2. 計画 — /plan-hard による詳細な計画。ユーザーの承認が必要です
3. 実装 — 完全なコードレビューと SRE レビューを伴って実行します
4. 検証 — すべてのテストを実行し、変更をレビューして、ドキュメントを更新します

主なルール：

• 徹底的に進めます。調査 → 計画 → 実装 → レビュー → テスト → ドキュメント
• 計画段階でユーザーの承認が必要です
• 作業を ToDo タスクに分割し、最後にセルフレビューのタスクを追加します

フロントエンド／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%を超える必要があります）。

$ARGUMENTS

モード： HARD — 追加調査、詳細な計画、必須レビュー。

ワークフロー

1. 詳細な調査フェーズ

• researcher サブエージェントを2～3個並列で起動し、以下を調査します。
  • 技術的アプローチの妥当性
  • エッジケースと障害モード
  • セキュリティへの影響
  • パフォーマンスに関する考慮事項
• 包括的なコードベース分析には /scout-ext を使用します。
• 調査レポートを作成します（各レポートは最大150行）。
• 外部メモリ：調査内容をすべて .ai/workspace/analysis/{task-name}.analysis.md に書き込みます。計画を立てる前に、ファイル全体を読み直します。

グラフを活用した調査 — .code-graph/graph.db が存在する場合は必須です。

厳格なゲート： 調査を終える前に、重要なファイルに対して少なくとも1つのグラフコマンドを必ず実行します。

手順： Grep でファイルを特定 → trace --direction both でシステム全体のフローを把握 → Grep で詳細を確認

タスク	最低限のグラフ操作
調査／Scout	2～3個のエントリーファイルに対して trace --direction both を実行
修正／デバッグ	バグのある関数に対して callers_of と tests_for を実行
機能／機能強化	変更対象のファイルに対して connections を実行
コードレビュー	変更した関数に対して tests_for を実行
影響範囲	trace --direction downstream を実行

CLI： python .claude/scripts/code_graph {command} --json。まず --node-mode file を使用してノイズを10～30分の1に抑え、その後、詳細を確認するために --node-mode function を使用します。

実装後、変更したファイルに対して python .claude/scripts/code_graph connections <file> --json を実行し、関連ファイルに更新が必要ないか確認します。

実装前のグラフトレース

グラフ DB を利用できる場合は、コードを書く前にトレースを実行して影響範囲を把握します。

• python .claude/scripts/code_graph trace <file-to-modify> --direction both --json — このコードを呼び出すものと、このコードが呼び出すものを確認します
• python .claude/scripts/code_graph trace <file-to-modify> --direction downstream --json — 下流のすべての利用側を確認します
• これにより、暗黙の依存関係（バスメッセージの利用側、イベントハンドラーなど）の破損を防ぎます

2. 包括的な計画

• すべての調査レポートを渡して、planner サブエージェントを使用します
• 以下を含む完全な計画ディレクトリを作成します。
  • plan.md — リスク評価を含む概要
  • phase-XX-*.md — フェーズごとの詳細ファイル
  • 各フェーズの成功基準
  • ロールバック戦略

3. 検証済みの実装

• 一度に1つのフェーズを実装します
• 各フェーズの後に以下を実行します。
  • 型チェックとコンパイルを実行
  • 関連するテストを実行
  • 次に進む前にセルフレビューを実施

バッチチェックポイント（大規模な計画）

10個以上のタスクがある計画では、人間によるレビューを挟みながらバッチ単位で実行します。

1. バッチを実行 — 次の3つのタスク（またはユーザー指定のバッチサイズ）を完了します
2. 報告 — 実装内容、検証結果、懸念事項があれば提示します
3. 待機 — 「フィードバックをお待ちしています」と伝えて停止します。自動的に続行してはいけません。
4. フィードバックを反映 — 変更を反映してから、次のバッチを実行します
5. すべてのタスクが完了するまで繰り返します

10個以上のタスクがある計画では、チェックポイントを設けずにすべてのタスクを連続して実行してはいけません。 人間によるレビューのため、各バッチの後に停止します。これにより、初期の誤りが後続のタスクに連鎖して広がる事態を防ぎます。

4. 必須テスト

• テストを網羅的に実施するために、tester サブエージェントを使用します
• 以下のテストを作成します。
  • 正常系のシナリオ
  • 調査で判明したエッジケース
  • エラー処理の経路
• モックや偽データは使用禁止です
• すべてのテストが合格するまで繰り返します

5. 必須コードレビュー

• code-reviewer サブエージェントを使用します
• 重大および重要な指摘にすべて対応します
• 修正後にテストを再実行します
• 承認されるまで繰り返します

6. ドキュメントの更新

• docs-manager を使用して関連ドキュメントを更新します
• project-manager を使用してプロジェクトのステータスを更新します
• アーキテクチャ上の決定事項を記録します

7. 最終レポート

• すべての変更の概要
• テストカバレッジの指標
• 対応したセキュリティ上の考慮事項
• 未解決の質問（あれば）
• ユーザーにレビューと承認を依頼します

使用する場面

• 本番環境の重要な機能
• セキュリティ上重要な変更
• パブリック API の変更
• データベーススキーマの変更
• サービス間の連携

品質ゲート

ゲート	基準
調査	研究者レポート 2 件以上
計画	計画ディレクトリが完備している
テスト	すべて合格し、モックがない
レビュー	重大または重要な指摘が 0 件
ドキュメント	必要に応じて更新済み

---

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

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

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

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

終了時のリマインダー

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

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

• 必須・重要・要注意 あらゆる主張について file:line 形式の根拠を示してください（実行する判断の確信度は 80% 超）

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

• 必須・重要・要注意 AskUserQuestion で判断をユーザーに確認してください。自動で決めてはいけません 必須・重要・要注意 作業を始める前に、以下のファイルを必ず読んでください。

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

• 必須・重要・要注意 各フェーズに TC ID を付けた ## テスト仕様 を含めてください。新しいタスクを作成する前に TaskList を呼び出してください。

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

• 必須・重要・要注意 graph.db が存在する場合は、重要なファイルに対してグラフコマンドを少なくとも 1 つ実行してください。手順：grep → グラフトレース → grep で検証。

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

• 要注意 AI の誤りを防止してください。まず全体的な観点でデバッグし、責任のあるレイヤーで修正し、コーディング前に曖昧さを明らかにし、コンパクション後にファイルを読み直してください。

[TASK-PLANNING] 作業に取りかかる前に、タスクの範囲を分析し、TaskCreate を使って小さな todo タスクとサブタスクに体系的に分割してください。