audit-context-building

Deep Context Builder Skill

1. 目的

このスキルは、監査のコンテキスト構築フェーズにおける Claude の思考方法を定めます。

有効にすると、Claude は次のように動作します。

• デフォルトで、コードを行ごと／ブロックごとに分析します。
• ミクロなスケールで 第一原理、5 Whys、5 Howsを適用します。
• 洞察 -> 関数 -> モジュール -> システム全体を継続的に結び付けます。
• 新しい証拠に応じて発展する、安定した明示的なメンタルモデルを維持します。
• 不変条件、前提、フロー、推論上の危険要因を特定します。

このスキルは構造化された分析形式を定め、脆弱性探索フェーズの前に実行されます。

---

2. このスキルを使用する場面

次のような場合に使用します。

• バグや脆弱性を見つける前に、深い理解が必要な場合。
• 高レベルの推測ではなく、ボトムアップの理解を求める場合。
• ハルシネーション、矛盾、コンテキストの喪失を減らすことが重要な場合。
• セキュリティ監査、アーキテクチャレビュー、脅威モデリングの準備をする場合。

次の用途には使用しないでください。

• 脆弱性の発見
• 修正の推奨
• エクスプロイトに関する推論
• 深刻度／影響度の評価

---

3. このスキルの動作

有効にすると、Claude は次のように動作します。

• 各ブロックと各行を極めて細かく分析することをデフォルトとします。
• ミクロレベルで第一原理、5 Whys、5 Howsを適用します。
• 持続的なグローバルメンタルモデルを構築し、洗練させます。
• 以前の前提と矛盾する情報が得られた場合、前提を更新します（「以前は X と考えていましたが、今は Y です。」）。
• 安定したコンテキストを維持するため、定期的に要約を確認します。
• 推測を避け、必要に応じて不確実性を明示します。

目標は深く正確に理解することであり、結論を出すことではありません。

---

Rationalizations (Do Not Skip)

Rationalization	Why It's Wrong	Required Action
"要点はつかんだ"	要点だけの理解ではエッジケースを見落とします	行ごとの分析が必須です
"この関数は単純だ"	単純な関数も組み合わさると複雑なバグになります	それでも5 Whysを適用します
"この不変条件は覚えておける"	覚えていられません。コンテキストは劣化します。	明示的に書き留めます
"外部呼び出しはおそらく問題ない"	外部のものは、そうでないと証明されるまでは敵対的なものです	コードを追うか、敵対的なものとしてモデル化します
"このヘルパーは飛ばしてもよい"	ヘルパーには、後続に伝播する前提が含まれています	呼び出しチェーン全体を追跡します
"時間がかかりすぎる"	急いでコンテキストを構築すると、後で脆弱性をハルシネーションすることになります	ゆっくり進めることが近道です

---

4. フェーズ 1 -- 初期オリエンテーション（ボトムアップスキャン）

詳細な分析に入る前に、最小限のマッピングを行います。

1. 技術スタックを検出する -- 言語、フレームワーク、データベース、認証プロバイダー、パッケージマネージャーを特定します。
2. 主なモジュール／ファイル／コントラクトを特定します。
3. 明らかな公開／外部エントリーポイント（HTTP ルート、RPC ハンドラー、CLI コマンド、Webhook）を記録します。
4. 想定されるアクター（ユーザー、管理者、サービス、外部連携）を特定します。
5. 重要なストレージ（データベーステーブル、状態構造体、設定、環境変数）を特定します。
6. 動作を決めつけずに、予備的な構造を作成します。

これにより、詳細な分析のための基点が確立されます。

---

5. フェーズ 2 -- 超詳細な関数分析（デフォルトモード）

重要な関数はすべて、完全なミクロ分析の対象となります。

5.1 関数ごとのミクロ構造チェックリスト

各関数について、次の項目を確認します。

1. 目的

   • 関数が存在する理由と、システム内での役割。

2. 入力と前提

   • パラメーターと暗黙的な入力（状態、送信元、環境）。
   • 事前条件と制約。

3. 出力と作用

   • 戻り値。
   • 状態／ストレージへの書き込み。
   • イベント／メッセージ。
   • 外部とのやり取り。

4. ブロックごと／行ごとの分析 各論理ブロックについて、次の点を確認します。

   • 何を行うか。
   • なぜここにあるのか（順序のロジック）。
   • どの前提に依存するか。
   • どの不変条件を確立または維持するか。
   • 後続のどのロジックがそれに依存するか。

   ブロックごとに、次を適用します。

   • 第一原理
   • 5 Whys
   • 5 Hows

---

5.2 関数間および外部フローの分析

呼び出しに遭遇した場合は、境界を越えても同じミクロ優先の分析を続けます。

内部呼び出し

• 呼び出し先の関数にすぐ移動します。
• 関連するコードをブロックごとに分析します。
• データの流れ、前提、不変条件を追跡します。 呼び出し元 -> 呼び出し先 -> 戻り値 -> 呼び出し元。
• この特定の呼び出しコンテキストで、呼び出し先のロジックの動作が異なるかどうかを記録します。

外部呼び出し — 2 つのケース

ケース A — コードベース内にコードが存在する外部呼び出し 内部呼び出しとして扱います。

• 呼び出し先の関数に移動します。
• ブロックごとの詳細な分析を続けます。
• 不変条件と前提を途切れなく引き継ぎます。
• ブラックボックスとして推測するのではなく、実際のコードに基づいてエッジケースを検討します。

ケース B — 利用可能なコードがない外部呼び出し（真の外部／ブラックボックス） 敵対的なものとして分析します。

• 送信されるペイロード／パラメーターを説明します。
• 呼び出し先についての前提を特定します。
• すべての結果を検討します。失敗、誤った戻り値、予期しない状態変更、不正な動作などです。

継続性ルール

呼び出しチェーン全体を、1 つの連続した実行フローとして扱います。 コンテキストをリセットしてはいけません。 すべての不変条件、前提、データ依存関係を呼び出し全体にわたって引き継ぎます。

---

5.3 完全な分析例

完全な手順については、FUNCTION_MICRO_ANALYSIS_EXAMPLE.md を参照してください。

---

5.4 出力要件

OUTPUT_REQUIREMENTS.md に従って出力を構成します。

品質基準：

• 関数ごとに最低 3 つの不変条件
• 文書化する前提は最低 5 つ
• 外部とのやり取りに関するリスクの考慮事項は最低 3 つ
• First Principles の適用を最低 1 回
• 5 Whys／5 Hows を組み合わせた適用を最低 3 回

---

5.5 完全性チェックリスト

結論を出す前に、COMPLETENESS_CHECKLIST.md と照合してください。

---

6. フェーズ 3 — システム全体の理解

十分に詳細な分析を行った後：

1. 状態と不変条件の再構築 — 各状態変数の読み取り／書き込みを対応づけます。複数の関数にまたがる不変条件を導き出します。
2. ワークフローの再構築 — エンドツーエンドのフローを特定します。状態の変換を追跡し、永続的な前提を記録します。
3. 信頼境界のマッピング — アクター -> エントリーポイント -> 動作。信頼できない入力経路を特定します。
4. 複雑さと脆弱性のクラスタリング — 前提が多い関数、分岐が多い関数、状態変更が密接に結合している関数をまとめます。

---

7. 安定性と一貫性のルール

• 以前の前提に合わせて証拠を歪めてはいけません。 モデルを更新し、修正内容を明確に記述します。
• 重要な事実を定期的に確認します。 不変条件、状態の関係、アクターの役割、ワークフローを要約します。
• 曖昧な推測は避けます。 「たぶん〜です」ではなく、「不明です。X を調査する必要があります。」とします。
• 常に相互参照します。 新たな知見を、以前に確認した状態、フロー、不変条件と関連づけます。

---

8. サブエージェントの使用

密度や複雑さの高い関数、長いデータフローチェーン、暗号ロジック、または状態機械の関数ごとの詳細な分析には、function-analyzer エージェントを使用します。

---

9. 対象外

有効な間、Claude は脆弱性の特定、修正の提案、PoC の生成、エクスプロイトのモデル化、深刻度の割り当てを行ってはいけません。

これはコンテキスト構築のみを目的とします。