These systems are trained to be agreeable. Ask one whether the work is any good and the default answer is yes, in fluent prose, with three supporting reasons. That is not evaluation. It is a mirror with good manners, and it will make you more certain of weaker work. Every pattern here exists to remove the reward for agreement.
Independent and personal
This document is my own work and my own opinion, written in my own time. It is not issued by, endorsed by, reviewed by, or connected to my employer. It does not describe, quote, or draw on any firm's internal practice, and nothing in it should be read as representing HOK, its practices, or its clients. Everything on this site is written the same way.
Five rules, before any of the prompts
01
Start a new conversation.
If the model has spent twenty messages helping you develop the scheme, it has already committed to it. Praise earlier in a thread contaminates every judgment after it. Critique gets a clean context, always.
02
Never say which option is yours.
Tell it you prefer scheme B and you will get an excellent case for scheme B. Present the options unlabeled, in an order you did not choose. Otherwise you are not testing the design. You are testing whether it can read your preference.
03
Give it the actual requirement text.
Your summary of the brief already contains your interpretation, which is the thing you want checked. Paste the client's words, not yours.
04
Give it what it can actually read.
These systems are unreliable on raw drawing sets. They will describe a plan they have not understood, fluently, and nothing in the answer will mark the difference. Supply the brief, the schedules, the room data, and a written description of the scheme. Where you do supply drawings, treat every spatial claim that comes back as something to check rather than something found. The patterns below that ask for plans assume you have read those plans yourself first.
05
Ask for the objection before you ask for the fix.
A model asked to solve will solve, and in solving will quietly accept the framing. Separate the two steps and the framing gets examined.
P1
The Adversarial Review
The general-purpose one. Use it when a scheme feels settled and you suspect it settled too early.
Prompt
You are reviewing a design proposal. Your job is not to be balanced.
Find the strongest case against this scheme: the three objections most likely to be raised by someone who has to approve it, pay for it, or work in it every day.
For each objection, give me:
1. The objection in one sentence.
2. The specific evidence in the material below that supports it.
3. What it would take to answer it.
Do not list strengths. Do not soften. If you cannot find three real objections, say so plainly and tell me what would have to be true for the scheme to be this sound.
Supply
A written description of the scheme plus the brief. Drawings as support, with the caveat in rule four. No commentary from you on what you think works.
A good answer
Objections tied to something specific in the material, with the evidence quoted back. One of the three should be uncomfortable.
How it fails
Generic architectural criticism that could apply to any project of the type. If you could have written the objection without reading the material, it is noise. Re-run it with more of the actual brief.
P2
The Missing-Requirement Sweep
Before any milestone. This is the one that finds the requirement that quietly stopped being true in July.
Prompt
Below is the project brief and a description of the current scheme.
Go through the requirements one at a time. For each, mark it:
MET / PARTLY MET / NOT MET / CANNOT TELL FROM WHAT I HAVE GIVEN YOU
For each requirement, quote the specific requirement text and the specific part of the scheme you are judging it against. Do not infer intent. Do not mark anything MET unless the material states it.
List every CANNOT TELL item first, before anything else.
Supply
The brief verbatim, and the current scheme in whatever form you have it.
A good answer
A long CANNOT TELL list at the top. That list is the actual output: it tells you what your own documentation does not say.
How it fails
Everything comes back MET. That means you gave it your summary rather than the client's text, or the scheme description is doing the requirement's job for it.
P3
The Opportunity Sweep
Mid-schematic, when the scheme works and you suspect it is not yet earning what the site or the program could give it.
Prompt
Here is the scheme. Tell me what it is not yet exploiting.
Rules for your answer:
- Every item must name a specific element of this project. "Improve the daylighting" is not an answer. "The north third of the floor plate, at this depth and with this core position, is leaving its perimeter under-programmed" is an answer.
- Give me five.
- Rank them by how much of the current scheme would have to change, cheapest first.
- For each, say what it would cost to take and what it would cost to keep ignoring.
Supply
The program, the site constraints, and a written description of the plan and section. Drawings as support rather than as the source. The more constraint you give it, the more specific the answer.
A good answer
At least one item you had noticed and set aside, which tells you the read is accurate, and at least one you had not.
How it fails
A list of sustainable design generalities. The specificity rule is doing the work here, so if the answer is generic, the input was too thin.
P4
The Unasked Question
Early, and again just before you commit. The highest-value pattern on this list.
Prompt
Based on the brief and the scheme below, what should we have asked the client and did not?
List only questions whose answers would change the design. Skip questions that would merely confirm it.
For each question, tell me which decision it would change, and whether the answer gets more expensive to act on the longer we wait.
Supply
The brief and the current scheme.
A good answer
Two or three questions you can actually put in an email this week. Most of what turns out to be good in a project was never in the brief; it was discovered by asking.
How it fails
Questions about preference rather than constraint. Preference questions produce meetings; constraint questions produce decisions.
P5
The Reviewer Panel
Before an external submission. Cheap, fast, and it catches the thing your team has stopped seeing.
Prompt
Read this as three different people, one at a time, and keep them completely separate. Do not blend them.
1. A plan reviewer at seven in the morning with forty submittals in the queue.
2. The contractor pricing this.
3. The person who will work in this building every day for ten years.
For each one give me: their first reaction in one sentence, the single thing they would object to, and the first question they would ask.
Do not make them polite.
Supply
Whatever is actually going out the door, plus a written summary of what the drawings show. Rule four applies most sharply here, because a submission is exactly where a confident misreading is expensive.
A good answer
Three genuinely different readings. The daily-occupant voice is usually the one that finds something nobody in the room has raised.
How it fails
Three variations on the same note. Run them as three separate prompts instead of one.
P6
The Cost-of-Change Sort
After any review that produced more findings than you can act on.
Prompt
Here are the findings from a design review.
Sort them by when they become expensive to fix, not by how serious they are. Use three buckets:
- Cheap to change now
- Expensive after [name the milestone]
- Effectively permanent after [name the milestone]
For each finding, say which bucket and why. I need to know what to spend this week on, not what matters most in the abstract.
Supply
Your own list of findings, from any source. This pattern operates on a list, not on a design.
A good answer
A short cheap-now bucket you can clear in a day, and a clear-eyed permanent list you can take to the client while it is still a conversation rather than a change order.
How it fails
Severity ranking wearing a different label. If the buckets track importance rather than timing, restate the milestones concretely with dates.
P7
The Refusal Test
Any time you are about to trust an answer. Run it as a preamble to another prompt.
Prompt
Before you answer, do two things.
First, list everything you would need to know in order to answer this well, and do not have.
Then answer only the parts you can support from the material I have given you. Mark clearly anything you are inferring rather than reading.
If the honest answer is that you cannot assess this from what I have provided, say that instead of answering.
Supply
Nothing extra. Put it at the top of any other prompt on this page.
A good answer
A short list of genuine gaps. This is the single most useful habit on the page, because a model that has named what it is missing is much less likely to invent it.
How it fails
It lists gaps and then answers confidently anyway. Split it into two messages: ask for the gaps, read them, then ask for the answer.
P8
The Steelman Then Kill
When you are attached to something and you know it.
Prompt
I am going to give you a design decision I have already made.
First, make the strongest possible case FOR it. Be genuinely persuasive. Use the material to support it.
Then, without hedging, make the strongest possible case AGAINST it.
Then tell me which case is better supported by the evidence in front of you, and what single piece of information would settle it.
Supply
The decision, stated flatly, with no explanation of why you like it.
A good answer
A verdict you did not want. The value of this pattern is entirely in the third step, so do not stop after the two cases.
How it fails
It picks your side. Usually because the way you described the decision revealed your attachment. Restate it as a neutral proposition and run it again.
Version 1.0 · Updated August 2026
None of this makes the machine a critic. It makes it stop performing agreement long enough to be useful, which is a lower bar and still worth clearing. The judgment about what to do with the answer stays where it always was.
Free to adapt. If one of these earns its keep, or fails in a way I have not described, tell me at hello@frankcauthen.com. The argument underneath all of this is in The Tighter Loop.