depth-check

depth-check

「目の前の作業に必要なレベルまで」を実践します。タスクを受け取り、実際に必要なレベルを見極め、さらにユーザーがすでに知っていることを差し引きます。出力するのは、コードベース全体についての講義ではなく、短く率直な準備リストです。

タスクのすべての部分を深く理解する必要はありません。ロジックを変更するなら実用的な理解が必要で、インターフェースを呼び出すならその契約を把握し、周辺コードについては存在を認識していれば十分です。必要な深さを見極めることが、このスキルの核となる役割です。深さを求めすぎるのも、求めなさすぎるのも、同じように失敗です。

手順

1. タスクを明確にする

実際に何を変更するのかを確認します。ユーザーの説明が曖昧なら、まずコードを見て具体化します（「同期のバグを直す」→どの同期経路で、どのモジュールがおおよそ関係するのか）。

2. 影響範囲を把握する

タスクの規模に応じて、以下を調べます。

• 変更が直接関わるファイル／モジュール
• それらの利用側 — 何がこれを呼び出し、何がその動作に依存しているか
• 関連する不変条件：周辺コードが前提としていること、プロトコル／順序に関する制約、コメントやアサーションで警告されていること
• 該当箇所をカバーするテスト（テストの有無と内容から、どの動作が重要かが分かります）

3. 各領域に必要な深さを判定する

影響範囲の各部分について、作業に必要なレベルを割り当てます。

• 実用的な理解 — そのロジックを変更する場合：エッジケースでの動作を予測できる必要があります
• 契約 — そのコードを呼び出す、または依存する場合：インターフェース、保証、失敗時の動作を知る必要があります
• 認識 — 近接している場合：そのコードの存在と、どんなときに関係するのかを知る必要があります

4. ユーザーがすでに知っていることを差し引く

信頼性の高い順に、次の情報を確認します。

• このパックのセッションループを実行している場合は、ユーザーのドシエとジャーナルを確認します。これらを信頼しつつ、最近のコミットによって古くなっている可能性のある項目には注意を促します。
• 該当箇所におけるユーザー自身のコミット履歴を確認します：git log --author=<user email from git config> --oneline -- <path>。ユーザーが書いたコードや最近変更したコードは理解している可能性が高く、触れたことのないコードは理解していない可能性が高いです。
• どちらの情報でも判断できない場合は、直接尋ねます。「リトライ層を扱ったことはありますか？」のような短い確認質問のほうが、誤った思い込みよりも適切です。

5. 準備リストを出力する

短いリストを2つ作成します。

• すでに把握していること — ユーザーの既知のレベルが必要なレベルに達している領域。これらについては事前学習は不要です。
• 先に確認すること — 各項目は、勉強すべきトピックではなく、コーディング前に答えるべき具体的な質問にします。「書き込み経路を理解する」よりも「ここでは書き込みの順序がどのように保証されていますか？」のほうが適切です。それぞれの答えを最短で得る方法も示します。具体的なファイルを読む、テストを実行する、why で意思決定の経緯を調べる、といった方法です。

リストが空なら、その旨を一行で伝えて、余計なことはしません。既知の領域内のタスクに、形式ばった準備は必要ありません。

セッションループを使うユーザーの場合、準備後も未解決のまま残った質問は、次回に再確認できるようジャーナルに一行記録する価値があります。それ以外のユーザーには、この手順を省略します。

ガードレール

• 準備リストは数分から1時間程度で答えられる内容にします。読み込みが必要な項目が約5件を超えるなら、タスクが大きすぎる可能性が高いため、その旨を伝えます。
• どちらの方向にも正直に判定します。タスクで呼び出すだけのコードに実用的な理解を求めず、ロジックの変更を契約レベルの知識だけで済ませないでください。
• 読み取り専用です。このスキルは調査して報告するだけで、対象プロジェクトには何も変更を加えません。