Audit Context Building

Understand a codebase before you go looking for bugs in it.

Author: Omar Inuwa

What it does

It reads the code function by function and writes up three things about each one: what it assumes is already true, what it promises to whatever calls it, and what it depends on elsewhere. Those write-ups go into files. You get back a short summary and a list of the spots worth a closer look.

It does not report vulnerabilities. That is the next job, and it goes much better once this one is done.

Why this exists

Claude can already read a function and explain it well. This plugin is not here to teach it that. It is here for three things Claude cannot do for itself:

You don't have to remember it exists. A workflow only runs when someone types its name. This skill notices the situation instead — you are starting an audit, or opening a codebase nobody on the team knows — and starts the right one for you.

It splits the work up. One helper runs per function, all at the same time, each writing its notes straight to a file. Ask Claude to do the same job directly and it works through the functions one at a time, filling its working memory with the notes until there is no room left to actually use them.

Every write-up comes out the same shape. That matters most in one specific case: when the code counts on something being true and nothing anywhere checks it. That always gets recorded the same way, with the words nothing found. So you can search a whole codebase for that one phrase and get every such spot in a list. Claude finds those spots on its own just fine — but describes each one differently, and forty differently worded notes do not add up to a list.

If you are changing this plugin, keep that order in mind. The guidance in SKILL.md and resources/ is sound practice and worth keeping, but it is not what makes the plugin useful. The value is in the workflow, the fixed write-up format, and the fact that it starts itself.

When to use it

At the start of an audit, a threat model, or an architecture review — any time the code is unfamiliar and somebody is about to go looking for problems in it.

Also useful when an earlier review turned up issues nobody could judge, because no one had mapped out how the system fits together.

How to run it

/audit-context-building:audit-context <path> [--focus <module>]

That runs the workflow, in three steps:

1. Get oriented. Map out the pieces of the system, the ways in from outside, who can reach them, and the data that sticks around between calls. Then pick the functions that carry the most weight.
2. Analyze. One helper per function. Each writes its full notes to audit-context/functions/ and hands back only a short record.
3. Pull it together. Work out the rules that span several functions — the ones no single write-up could state on its own — and save the result to audit-context/DOSSIER.md.

For a single function, you can run the audit-context-building:function-analyzer helper on its own. Either way the reading happens in a helper, not in your own session.