/audit-context-building

name: audit-context-building
description: Enables ultra-granular, line-by-line code analysis to build deep architectural context before vulnerability or bug finding.
risk: safe
source: community

Deep Context Builder Skill (Ultra-Granular Pure Context Mode)

1. Purpose

This skill governs **how Claude thinks** during the context-building phase of an audit.

When active, Claude will:

• Perform **line-by-line / block-by-block** code analysis by default.
• Apply **First Principles**, **5 Whys**, and **5 Hows** at micro scale.
• Continuously link insights → functions → modules → entire system.
• Maintain a stable, explicit mental model that evolves with new evidence.
• Identify invariants, assumptions, flows, and reasoning hazards.

This skill defines a structured analysis format (see Example: Function Micro-Analysis below) and runs **before** the vulnerability-hunting phase.

---

When to Use

Use when:

• Deep comprehension is needed before bug or vulnerability discovery.
• You want bottom-up understanding instead of high-level guessing.
• Reducing hallucinations, contradictions, and context loss is critical.
• Preparing for security auditing, architecture review, or threat modeling.

Do **not** use for:

• Vulnerability findings
• Fix recommendations
• Exploit reasoning
• Severity/impact rating

---

2. How This Skill Behaves

When active, Claude will:

• Default to **ultra-granular analysis** of each block and line.
• Apply micro-level First Principles, 5 Whys, and 5 Hows.
• Build and refine a persistent global mental model.
• Update earlier assumptions when contradicted ("Earlier I thought X; now Y.").
• Periodically anchor summaries to maintain stable context.
• Avoid speculation; express uncertainty explicitly when needed.

Goal: **deep, accurate understanding**, not conclusions.

---

Rationalizations (Do Not Skip)

| Rationalization | Why It's Wrong | Required Action | |-----------------|----------------|-----------------| | "I get the gist" | Gist-level understanding misses edge cases | Line-by-line analysis required | | "This function is simple" | Simple functions compose into complex bugs | Apply 5 Whys anyway | | "I'll remember this invariant" | You won't. Context degrades. | Write it down explicitly | | "External call is probably fine" | External = adversarial until proven otherwise | Jump into code or model as hostile | | "I can skip this helper" | Helpers contain assumptions that propagate | Trace the full call chain | | "This is taking too long" | Rushed context = hallucinated vulnerabilities later | Slow is fast |

---

3. Phase 1 — Initial Orientation (Bottom-Up Scan)

Before deep analysis, Claude performs a minimal mapping:

1. Identify major modules/files/contracts. 2. Note obvious public/external entrypoints. 3. Identify likely actors (users, owners, relayers, oracles, other contracts). 4. Identify important storage variables, dicts, state structs, or cells. 5. Build a preliminary structure without assuming behavior.

This establishes anchors for detailed analysis.

---

4. Phase 2 — Ultra-Granular Function Analysis (Default Mode)

Every non-trivial function receives full micro analysis.

5.1 Per-Function Microstructure Checklist

For each function:

1. **Purpose**

• Why the function exists and its role in the system.

2. **Inputs & Assumptions**

• Parameters and implicit inputs (state, sender, env).
• Preconditions and constraints.

3. **Outputs & Effects**

• Return values.
• State/storage writes.
• Events/messages.
• External interactions.

4. **Block-by-Block / Line-by-Line Analysis** For each logical block:

• What it does.
• Why it appears here (ordering logic).
• What assumptions it relies on.
• What invariants it establishes or maintains.
• What later logic depends on it.

Apply per-block:

• **First Principles**
• **5 Whys**
• **5 Hows**

---

5.2 Cross-Function & External Flow Analysis

*(Full Integration of Jump-Into-External-Code Rule)*

When encountering calls, **continue the same micro-first analysis across boundaries.**

Internal Calls

• Jump into the callee immediately.
• Perform block-by-block analysis of relevant code.
• Track flow of data, assumptions, and invariants:

caller → callee → return → caller.

• Note if callee logic behaves differently in this specific call context.

External Calls — Two Cases

**Case A — External Call to a Contract Whose Code Exists in the Codebase** Treat as an internal call:

• Jump into the target contract/function.
• Continue block-by-block micro-analysis.
• Propagate invariants and assumptions seamlessly.
• Consider edge cases based on the *actual* code, not a black-box guess.

**Case B — External Call Without Available Code (True External / Black Box)** Analyze as adversarial:

• Describe payload/value/gas or parameters sent.
• Identify assumptions about the target.
• Consider all outcomes:
• revert
• incorrect/strange return values
• unexpected state changes
• misbehavior
• reentrancy (if applicable)

Continuity Rule

Treat the entire call chain as **one continuous execution flow**. Never reset context. All invariants, assumptions, and data dependencies must propagate across calls.

---

5.3 Complete Analysis Example

See FUNCTION_MICRO_ANALYSIS_EXAMPLE.md for a complete walkthrough demonstrating:

• Full micro-analysis of a DEX swap function
• Application of First Principles, 5 Whys, and 5 Hows
• Block-by-block analysis with invariants and assumptions
• Cross-function dependency mapping
• Risk analysis for external interactions

This example demonstrates the level of depth and structure required for all analyzed functions.

---

5.4 Output Requirements

When performing ultra-granular analysis, Claude MUST structure output following the format defined in OUTPUT_REQUIREMENTS.md.

Key requirements:

• **Purpose** (2-3 sentences minimum)
• **Inputs & Assumptions** (all parameters, preconditions, trust assumptions)