The Pressure-Test Prompt Finds What Your Business File Can't Stop
The first prompt in module 4 interviews you and builds your business file. The second one attacks it.
The instruction is explicit: "Do not rewrite the file. Do not tell me it looks good." That sentence is doing work. The natural move for a language model is to find what's strong and build on it. We needed this prompt to do the opposite: find the gaps, name the failure modes, show proof.
Five Checks Before You Trust the File
The pressure-test runs five checks in order.
Vague rules. Every instruction that two people could follow in two different ways. The prompt quotes the line and shows both readings. "Sound professional" is a vague rule. "Use complete sentences and avoid contractions in customer-facing output" is not. Vague rules in a business file are worse than no rules, because they give you the feeling of coverage without the protection.
Rules that are descriptions. Facts written as statements when they should have been written as instructions. "Our voice is direct and plain-spoken" is a description. "When you draft customer-facing copy, read it back in the voice of a farmer standing in a shop at 6am. If it sounds like a brochure, rewrite it" is an instruction. The model won't use a description as a constraint. It needs an instruction.
Missing guardrails. Based on what the business does, what mistakes can Claude plausibly make that nothing in the file stops? Not categories of mistakes. Specific ones. An ag retailer's file that doesn't address delivery dates is a file waiting to produce an invented delivery date. The prompt pushes for specifics, not a taxonomy of risk.
Contradictions. Two lines pulling opposite directions. If the rules section says "never state a price without source material" and the voice section says "be direct and specific, give the grower numbers," those two instructions will collide in a real session. The conflict needs to get caught in a test, not in a live customer message.
Dead weight. Lines that would not change a single output the model produces. These belong in a company handbook, not a business file. A long file with dead weight is harder to maintain than a short one that works. It also trains you to treat the file as a completed artifact rather than a working tool.
The Proof Section
After the five checks, the prompt requires proof: pick the two weakest rules and write a short output that technically obeys each rule but is still wrong.
This is the part most review prompts skip. It is easier to list potential problems than to demonstrate them. The demonstration forces the model to commit. Here is the specific output this gap would allow. That output either reads as a real problem or it doesn't. If it doesn't, maybe the rule is fine.
Findings come ordered by damage potential: quote the line, say what goes wrong, give the replacement text to paste in. Then one final line: the single most valuable addition the file is missing.
Why This Runs After the Build, Not Before
You could run this attack prompt on a blank page and get generic AI-configuration advice. That list is not useful.
The pressure-test is useful when it has a real file to attack. The specifics of your guardrails, your voice section, your rules are what gives the model something concrete to probe. The findings land in the right sections. The contradictions refer to the actual lines. The replacement text can be pasted directly over the original.
The file you started with is not the file you end with. That's the point of running prompt two at all.
We build a lot of these configuration layers for clients, and the pressure-test step is the one most people want to skip. The file looks done. It covers the obvious things. Running an attack on it before you trust it is the difference between a file that holds up and a file that passes the smell test until the first time it matters.