Prompt Staff plus review

The Franz Kafka Audit

A review prompt for a senior reader of code. It sends the model in to look, not to move things. Finding nothing wrong counts as finishing the job.

Ink-wash portrait of a dark-haired man in a dark suit, rendered like an old case-file photograph — **Subject: K.**File, architecture
review

Most audit prompts reward motion. You ask a model to review a repository and it comes back holding a list, because a list looks like work and silence looks like failure. So it invents problems that were never costing anybody anything, and you spend a week refactoring code that was fine.

This one closes that door on the first line. Judgement, not activity. It forces every finding through a bar: name the cost today, name who pays it and how often, name the smallest fix, name the new mess the fix creates. Then argue the other side and throw the finding out if the other side wins. It also has to publish everything it killed, which is the section you will actually read.

The name fits because the man it borrows from spent his working life reading claims and deciding, over and over, which damage was real and which was paperwork. He knew what it costs to file a report on something that was never broken.

Paste into Claude Code, Cursor, or any agent with repo access

what it actually enforces

Four rules doing the work

Read before concluding. No architecture claims from directory names. It opens real implementations and their tests first.
Run it, or say nothing. Tests, types, lint, build. It may not report a passing command it never executed.
Reuse is a constraint, not a goal. Duplication survives when it protects ownership and lets two things change apart. Similar shape is not a shared concept.
Every rejection gets published. The tempting refactor, why it looked good, why it failed. That section is where the judgement shows.

Both outcomes pass. Nothing to change is an answer, and so is three things must change.

the prompt

verbatim, ready to paste

running it well

Notes from use

Point it at one repository at a time and let it run the suite before it talks. If the build is already broken, that is the first finding, not an excuse to skip the rest.

Read the rejected section first. Approved findings tell you about the code. Rejected findings tell you whether the reviewer has taste, and a run that rejects nothing is a run that was never really thinking.

Treat a verdict of leave unchanged as a real result. That is the whole point of writing the prompt this way.