Lesson 21 of 25

The Master's Review

Before you act on an answer - or before you even send a long prompt - you ask the model to review the work: to find the ambiguities in your instruction, the contradictions you did not notice, and the weak spots in its own draft. It works because judging a piece of writing against a stated set of criteria is an easier task than producing it, so a fresh pass with a critical brief often catches what the first pass missed.

Reach for it whenWhen a prompt is long enough or important enough that you would rather find its flaws before you get a thousand words of the wrong thing - or when an answer looks polished and you need to know where it is actually thin.

Put the thing being reviewed in its own tag - <prompt_under_review> or <draft> - and the reviewing instruction last. That separation matters more here than in most chapters, because without it the model tends to start carrying out the prompt it was supposed to criticise. Claude also responds well to being asked to reason before it concludes, so ask for the list of problems first and the verdict after, and tell it explicitly what to do when it is unsure rather than letting it guess.

Worth knowingClaude critiques structure, ambiguity and internal contradiction well, and will often volunteer that an instruction conflicts with another. What it cannot do - and no model can - is audit its own facts. A self-review of its own output will tidy the argument and leave a wrong figure standing, because the review draws on exactly the same understanding that produced the error. There is a second, subtler failure: asked to critique its own work it tends toward agreeable self-deprecation, producing plausible-sounding criticisms of the wrong things. Giving it specific criteria to judge against is what prevents that.
  • Put the draft in a tag, the review instruction last.
  • Say "do not carry out this prompt" explicitly.
  • Give named criteria, or it invents soft criticisms.
  • Ask for problems first, verdict after.
  • Self-review cannot check facts - verify those elsewhere.
Example 1: Catching a Costly Ambiguity

Instead of

Summarize the meeting notes. I want to know what the key takeaways were for the marketing and sales teams.

Perplexity version

<prompt_under_review>
Summarize the meeting notes. I want to know what the key takeaways were for the marketing and sales teams.
</prompt_under_review>

<role>
A prompt reviewer. You are not carrying this prompt out.
</role>

<task>
Review the prompt above. Do not summarise anything - there are no notes attached yet, and that is deliberate.
</task>

<criteria>
Judge it against these, in order, and say something specific about each:
1. Ambiguity - how many different outputs could legitimately satisfy this instruction? I count at least three readings of "takeaways for the marketing and sales teams": one combined list, two separate lists, or only the items affecting both.
2. Hidden difference - marketing probably wants strategic insight and sales probably wants assigned tasks. My prompt uses one word for two different output shapes. Is that the real flaw here?
3. Missing specification - length, format, whether to name owners, what to do with items that were discussed but not decided.
4. Failure mode - what would you most likely have produced, and how would I have known it was the wrong reading?
</criteria>

<how_to_handle_uncertainty>
If you are unsure whether something is a real flaw or just a choice I have made, say which and move on. Do not manufacture problems to seem thorough, and do not soften a real one. If the prompt is adequate as written, say that.
</how_to_handle_uncertainty>

<output_format>
Problems first, as a list, each with the specific consequence. Then the rewritten prompt you would rather have received. Then one line: the single change that matters most.
</output_format>

---

And this is the fixed prompt the review should produce - the shape, not the wording, is the lesson:

<notes>
[Paste the meeting notes here]
</notes>

<task>
Two sections from the notes above.
</task>

<format>
## Key Takeaways for the Marketing Team
Strategic points, audience insight, positioning decisions. Insight, not tasks.

## Action Items Assigned to the Sales Team
Numbered. Task, owner, deadline. Write "owner not named" or "no deadline given" rather than inferring either.

## Raised but Unresolved
Anything discussed without a decision. This section exists so that open questions are not written up as conclusions.
</format>

<constraints>
Only what the notes contain. If a section would be empty, say it is empty.
</constraints>
Open Perplexity 2,360 characters
Example 2: Refining for a Stronger Command

Instead of

Write a short blog post about why our new software is good.

Perplexity version

<brief_under_review>
Write a short blog post about why our new software is good.
</brief_under_review>

<role>
A demanding editor reviewing a brief. Not a writer. Write no part of the post.
</role>

<task>
Tell me why this brief will produce something unreadable, and what it is missing.
</task>

<criteria>
1. The word "good" - what does a post organised around it look like, and why does it fail?
2. Who is reading this, and what do they do at the end of it? Neither is specified.
3. What the software actually does and whose problem it solves - absent entirely.
4. The five questions you need answered to brief this properly. Five that change the output, not a form to fill in.
</criteria>

<how_to_handle_uncertainty>
If a gap might be deliberate, ask rather than assume. If the brief is weaker in a way I have not listed, that is the more useful finding - lead with it.
</how_to_handle_uncertainty>

---

Then the strong version, once you have answered those questions:

<role>
A persuasive tech blogger.
</role>

<task>
A 500-word post titled "3 Ways Our New Software Will Revolutionize Your Workflow". Energetic, benefits-focused.
</task>

<structure>
For each of the three ways: the specific pain point the reader has today, what it costs them in time or money, then exactly how the software removes it. Pain first, product second.
</structure>

<self_review>
After the draft, a section headed "Where this is weak". Be specific rather than modest:
- Which of the three sections is thinnest and what would fix it.
- Every factual claim I would need to verify before publishing - any number, any comparison, any "faster than". List them individually.
- Anything you asserted about the software that I did not give you. Mark it as invented. Do not leave an invention sitting in the prose where it reads as fact.

Be clear about the limit of this review: you can tell me the argument is thin and you cannot tell me whether a figure is right. Sort your findings into "I can see this from the text" and "you need to check this outside this conversation", and put every factual claim in the second group.
</self_review>
Open Perplexity 2,120 characters
Example 3: Spotting a Contradiction

Instead of

Generate a list of 10 creative ideas for a new viral video. The ideas should be very unconventional and shocking. Make sure they are appropriate for a family-friendly brand.

Perplexity version

<prompt_under_audit>
Generate a list of 10 creative ideas for a new viral video. The ideas should be very unconventional and shocking. Make sure they are appropriate for a family-friendly brand.
</prompt_under_audit>

<task>
Do not generate any ideas. Audit the prompt above for internal contradiction.
</task>

<criteria>
1. Two instructions here cannot both be satisfied. Name them exactly.
2. Which one would you have followed, and which would you have quietly dropped? This is the part I want most. A contradiction gets resolved silently and the user never learns which half was discarded.
3. Is the conflict real, or is it a wrong word? I suspect I mean "memorable and surprising" and have written "shocking". Tell me if you read it differently.
4. Rewrite it so both constraints genuinely hold.
</criteria>

<how_to_handle_uncertainty>
Do not resolve the contradiction on my behalf and carry on. Stopping to name it is the whole task.
</how_to_handle_uncertainty>

---

The resolved prompt:

<task>
10 highly creative, unconventional ideas for a viral video.
</task>

<constraints>
- Clever, surprising, heartwarming. Memorable because unexpected, not because provocative.
- Completely appropriate for a family-friendly brand. No shock tactics, no controversy, nothing that needs discomfort to be shareable.
- These two constraints do not conflict. If you find one idea where they do, say so instead of bending either.
</constraints>

<format>
Per idea: one-line concept, why it gets shared, who shares it.
</format>

<self_audit>
Then audit your own list against the brief you were just given:
- The three most conventional ideas, despite the instruction. "Unconventional" is the constraint most quietly ignored and several of these are probably variants of things that have already circulated. Name them.
- Anything sitting closer to the brand line than I would want. Flag it; do not remove it. That is my judgement to make.
- Any idea that resembles a campaign that already exists - and here state plainly that you are working from recollection and cannot confirm it. This is the boundary of self-review: you can audit your list against my brief, you cannot audit it against the world. Give me the ones worth checking and I will check them.
</self_audit>
Open Perplexity 2,263 characters