audit-context-building

Use it when:: You're starting an audit, threat model or architecture review on code you don't know yet.
It does:: Dispatches a workflow that analyzes each function in its own subagent and returns compact records, keeping the long analysis out of your context.
You get:: audit-context/DOSSIER.md plus one file per function under audit-context/functions/.
Doesn't:: Name vulnerabilities, suggest fixes, write proofs of concept or rate severity; that's the bug-hunting phase that follows.

Runs through its Claude Code plugin's /audit-context-building:audit-context command and function-analyzer agent, so install the plugin from the trailofbits/skills marketplace, not the skill alone.

TL;DR

Trail of Bits' first pass on an audit: build understanding, not verdicts. For a codebase it runs the plugin's audit-context command; for a single function, its function-analyzer agent. Each record lists what must always be true, with the line that shows it, what the function takes on faith and what establishes it, what it needs from each function it calls, and what is still unclear. The dossier adds rules that span several functions, who can reach what, and where complexity clusters. Its core rule is to follow the calls: read each called function and every path through it, cite a line for every claim, and write "nothing found" when nothing makes an assumption true. Those unenforced assumptions and the open questions are what it hands the bug-hunting phase. Where two records disagree, both are quoted rather than reconciled. The same format covers smart contracts, C and C++, decompiled firmware and web services.

Summarizes the skill at e4dd0bb.

npx skills add https://github.com/trailofbits/skills --skill audit-context-building

skills.sh page Source on GitHub All skills from trailofbits/skills

Total Downloads: 7,300 on skills.sh, Nov 9, 2026
Repo stars: 8,081 trailofbits/skills
First seen: Jan 19, 2026 on skills.sh

Weekly Downloads

280

+70% over the 8 weeks to Nov 9

Weekly values

Week to	Installs
Sep 21	165
Sep 28	156
Oct 5	137
Oct 12	195
Oct 19	231
Oct 26	262
Nov 2	282
Nov 9	280

Category	category:security category:software-engineering Compliance, guardrails, skill vetting and browser fingerprinting. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:workflow A multi-step process the agent follows: interview, debug, run a TDD loop, review.
Effect	effect:local Its own steps create or change files, git state or local tools.
Needs	needs:claude-code needs:subagents Uses Claude Code features such as hooks or background agents. Relies on the agent being able to spawn subagents.
Publisher	by:official A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates.
Topics	security architecture

SKILL.md

From trailofbits/skills at e4dd0bb. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: audit-context-building
description: Understand a codebase before looking for bugs in it - what each function assumes, what it guarantees, and what it depends on elsewhere. Use when starting an audit, threat model, or architecture review on unfamiliar code, and before any vulnerability-hunting pass.
allowed-tools: Workflow Task Read Grep Glob

Audit Context Building

Build understanding, not verdicts. This runs before anyone hunts for bugs, and feeds that work.

When to Use

At the start of an audit, a threat model, or an architecture review, when the code is unfamiliar. Also when an earlier pass produced findings nobody could judge, because no one had mapped out how the system fits together.

When NOT to Use

Do not name vulnerabilities, suggest fixes, write proofs-of-concept, or rate severity. Those belong to the hunting phase, which runs next and with the whole picture in hand. When the code counts on something and nothing checks it, record that plainly and move on — whether it matters is decided later.

Not worth the tokens on code you already understand.

Do not analyze in this context

The analysis is long, and this context needs to survive to use it. Dispatch it:

A codebase, or more than one function — run /audit-context-building:audit-context <path>. It orients, analyzes each function in its own subagent, and writes audit-context/DOSSIER.md plus one file per function under audit-context/functions/. Only compact records return here.
A single function — dispatch the audit-context-building:function-analyzer agent at it. It writes its prose to disk and returns a record.

Then work from what comes back: the index, the unenforced assumptions, the open questions. Read a function's file when you need its detail.

The workflow is what enforces this, not this text: a subagent bound to a return schema cannot return prose. Treat this section as routing, and route.

What comes back, and how to read it

Each record lists what must always be true (with the line that shows it), what the function takes on faith (with whatever establishes it), which functions it calls and what it needs from each, and anything still unclear. The dossier adds the rules that span several functions, who can reach what, and where the complicated parts cluster.

Two things matter more than the rest:

Assumptions marked nothing found. The code counts on something being true and nothing anywhere makes it true. This is the most useful thing to hand the hunting phase.
The open questions. An honest list of what is still unclear beats a confident answer that turns out to be wrong. Carry them forward instead of closing them out.

Where two records disagree, both are quoted rather than quietly reconciled. That is a fact about the code, not a flaw in the analysis.

The format

ANALYSIS_FORMAT.md defines it, and FUNCTION_MICRO_ANALYSIS_EXAMPLE.md works through examples in C and Solidity. Read them when extending this plugin or deciding whether a record can be trusted.

The format is the same whatever the target. What changes is what fills each slot, and what counts as a call you cannot see inside. DOMAIN_NOTES.md maps that across smart contracts, C and C++, decompiled firmware, and web services — read it when the target is not plain source code.

The rule that matters most: follow the calls. Whether a function is correct usually depends on something another function does, and you cannot see that from the caller alone. A limit looks enforced because the value came back from a function whose name suggests it was checked. So read the function being called, follow every path through it rather than only the one that succeeds, and say what makes each assumption true. When nothing does, use those words: nothing found. Every claim cites a line, or becomes an open question.