# The AI Code-Audit Prompt Pack

The exact prompts I run to point AI at my own site and find the bugs that
look fine. Built for Claude Code, but they work in any coding agent that can
read your whole repo.

The order matters. Recon first so the model has the map. Then the hunt. Then
make it argue against its own findings before you trust a single one. That
last step is the difference between a real audit and a pile of false alarms.

From mattkeddie.com. Free. Steal it.

---

## 1. Recon (build the map first)

```
You are auditing this repository. Do not change anything yet.

Read the project structure end to end: routes, pages, API endpoints, the
auth flow, the data layer (which database client is used where), any
scheduled jobs, and any place that takes user input.

Give me back a short, dense brief:
- every route and what it does
- where writes happen and what guards them
- the external surfaces (webhooks, cron, email, third-party scripts)
- the 3 riskiest areas to look at first, and why

Cite real files and line numbers. Do not guess.
```

## 2. Hunt for the bugs that look fine

```
Now audit for defects that would look FINE if I clicked around the live
site. I care most about "success that lies":

- an error that gets swallowed so a failure reads as success
- a write that changes 0 rows but still reports "saved" / "published"
- an empty state that is indistinguishable from a broken feature
- a form that says "done" when nothing was sent
- an image or asset that loads fine but quietly tanks page speed

Also flag: security holes in the auth flow, features that cannot work as
coded, and dead code paths.

For each finding give me: the file and line, the exact failure scenario
(what input or state triggers it), and how severe it really is. No style
nitpicks. No hypotheticals without a concrete trigger.
```

## 3. Make it argue against itself (triage)

```
Take each finding from the last step and try to REFUTE it. For each one:

- Read the cited code again. Is the behavior really what you claimed?
- Can the failure actually happen in this deployed app, or does it need
  impossible state?
- Reconstruct the minimal concrete trigger. If you cannot, mark it refuted.

Default to "refuted" when you are not sure. Return only the findings that
survive, ranked by real severity.
```

## 4. Fix and verify

```
Fix the confirmed findings. After each fix, tell me exactly how to verify
it worked (the input to try, the state to check). Then run the build and
the linter and confirm both pass. Do not mark anything done you have not
verified.
```

---

## A note on which model to use

Some heavy security-hardening prompts trip the newest model's caution and it
stalls. When that happens, run the security pass on a slightly older model
(for me that is Claude Opus 4.8), then cross-check the two. Keeping two
models in the toolbox is part of the workflow, not a workaround.

## If you do not write code

You can still run this. Open Claude Code, point it at your project, and paste
these prompts in order. When it hands you a fix, make it explain what changed
and how to check it before you ship. The prompts do the reading. You make the
call.