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