cook-fast

[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 のバリアントです。

概要

目標： 調査を最小限に抑え、計画を簡素化して機能をすばやく実装します。

ワークフロー：

1. 調査 — コードベースをすばやく確認し、パターンを把握します
2. 計画 — 簡潔な実装計画を立てます
3. 実装 — コード簡素化レビューを行いながら実行します

主なルール：

• 詳細な調査は省略し、コードベースのパターンを参考にします
• 実装前にユーザーの承認を得る必要があります
• 作業を 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

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

計画を最小限に抑え、これらのタスクにすぐ着手してください： $ARGUMENTS

モード： 高速 — 調査を省略し、計画を最小限にして、自分の知識を信頼します。

ワークフロー

1. 迅速な計画（調査フェーズをスキップ）
   • タスクの要件を直接分析します
   • TaskCreate で最小限の ToDo リストを作成します
   • リサーチャーのサブエージェントやスカウトコマンドは使用しません
   • 複雑なタスクの場合は、実装前に .ai/workspace/analysis/{task-name}.analysis.md に簡潔な分析を書きます。

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

厳格な必須条件： 調査を完了する前に、主要なファイルに対して少なくとも 1 つのグラフコマンドを必ず実行します。

手順： Grep でファイルを見つける → trace --direction both でシステム全体のフローを明らかにする → Grep で詳細を確認する

タスク	最低限必要なグラフ操作
調査／スカウト	エントリーファイル 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 倍削減）。次に、詳細を確認するため --node-mode function を使います。

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

グラフトレースのクイックチェック

グラフ DB を利用できる場合は、実装前に簡単な下流トレースを実行します。

• python .claude/scripts/code_graph trace <file-to-modify> --direction downstream --json — 下流への影響をすばやく確認します

2. 迅速な実装

   • タスクには /code を直接使います
   • 複数段階の計画ドキュメントはスキップします
   • ドキュメントよりも動作するコードを優先します

3. 簡易検証

   • 型チェックとコンパイルを実行します
   • テストスイート全体ではなく、手動で要所を確認します
   • code-reviewer サブエージェントはスキップします

4. コミット（任意）

   • AskUserQuestion で、コミットの準備ができているかユーザーに確認します
   • 準備ができていれば、/commit を使います

使用する場面

• 要件が明確なシンプルな機能
• 解決方法が分かっているバグ修正
• リファクタリングタスク
• ユーザーが「そのまま実行して」と言った場合

トレードオフ

項目	高速モード	フルモード
調査	スキップ	複数のエージェント
計画	最小限	完全な計画ドキュメント
テスト	簡易チェック	テストスイート全体
レビュー	スキップ	Code-reviewer
速度	約 2 倍高速	徹底的

---

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

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

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

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

最後の確認事項

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

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

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

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

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

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

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

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

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

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

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

• 注意必須 批判的思考を働かせてください。すべての主張には追跡可能な根拠が必要であり、実行する際の確信度は80%超としてください。幻覚防止：推測を事実として提示してはいけません。

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

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