Most people write a prompt, add “double-check your work” at the end, and call it reviewed. A builder on r/PromptEngineering found that this barely changes anything, and that a separate reviewer step does far better.
u/Nothing_123_ spent weeks building a five-step chain that turns a one-line app idea into a full spec-style prompt for tools like Lovable and Claude Code. The steps are Analyze, Ask, Question check, Write, Check. The lessons from it apply to any multi-step chain you build, whether you are drafting specs, emails, reports, or support replies.
The key idea: one job per step
The writer is bad at reviewing itself. Same model, different job. When a model has just produced a piece of text, it reads that text with the same assumptions that produced it. A “double-check” line at the end mostly gets you a polite confirmation. A step that only hunts for gaps has no draft to defend and no momentum to protect. It reads the output cold, and that is why it found real problems the writer missed. The poster also found that a stronger model was most valuable as the reviewer, not the writer. That is a useful budget tip: a cheaper model can draft, and you spend the expensive calls where judgment matters most.
Old way vs. new way
The old way: One big prompt. It writes the spec, then politely checks itself. Guesses are buried in the text, so you only find them when something breaks in the built app. Technical questions go to users who can’t answer them, so they shrug or pick a random option. The output format is “mostly JSON, usually,” which works in a demo and fails on the tenth run.
The new way: Small steps with narrow jobs. Each one hands clean, structured output to the next. Guesses are visible, so a human or a later step can challenge them. Questions match what the user actually knows, so the answers are real. When something goes wrong, you can tell which step caused it, because each step has one job and one output you can inspect.
That is the contrast. The chain is not smarter. It is more honest about who does what.
Practical steps you can copy 🛠️
- Split writing from reviewing. Make the review step its own prompt with one task: find gaps. Give it the draft and the original request, and tell it not to rewrite anything. Its output should be a list of problems, nothing else. If you can, put your stronger model there.
- Mark assumptions inline. Skip the separate assumptions list. Write “(assumed)” right where the value is used, like “Customers can cancel up to 24 hours before (assumed).” You see what was guessed, and so does the next model in the chain. A separate list gets skimmed and forgotten, while a marker sitting inside the sentence is hard to miss. You can even search the final text for “(assumed)” to see how much was guessed.
- Check that every safeguard can fire. The poster’s trading bot prompt had a daily loss limit that could never trigger, because the bot only sold at a profit. The rule defeated its own goal. Have your reviewer ask for each safeguard: under the other rules, can this ever actually happen? The same trick works for refund limits, rate limits, approval steps, and timeouts. If a rule only matters in a situation the other rules forbid, it is decoration.
- Use structured output for every step. Every model tested, small and large, sometimes wrote text after the JSON. In a chain, that breaks the next step. The poster’s tests ran in normal chat, where format can’t be enforced. Their live app uses the API’s structured output, which prevents it. If you are testing in chat, expect a bit of stray text and judge format failures with that in mind. In production, enforce the schema instead of asking nicely.
- Ask about decisions, not technology. A non-technical user can’t answer “which database?” They can answer “can customers cancel, and until when?” Technical choices become marked assumptions. A good habit is to rewrite each technical question as a plain-language scenario before it reaches the user, then map the answer back to the technical choice yourself.
What about the review step itself?
The poster asked what others use for review: same model, different model, or rules-based checks. One commenter, u/AuroraAOS, said their setup runs all three and that the ordering matters more than the choice, with rules-based checks going first wherever possible. That makes sense to me. Cheap, deterministic checks should catch the obvious stuff before you spend a model call on the subtle stuff. Think of things like “is the JSON valid,” “are all required fields present,” or “does any number appear without a unit.” Those take milliseconds and never get tired. Save the model reviewer for questions that need judgment, like whether two rules contradict each other.
Your turn
Pick one chain you already run. Take the “double-check” line out of the writer prompt. Add a separate reviewer that only looks for gaps and contradictions. Then compare what it finds against what the writer caught alone. Keep a short note of the issues only the reviewer found, because that list tells you exactly which checks deserve to become permanent rules.
The project behind this post is CueBlu, currently a free beta, if you want to see the chain in action. What do you use for review steps? Drop it in the comments, because I’m curious whether rules-first holds up for you too!
Frequently Asked Questions
Q: Should the review step be rules-based, a model, or both?
Start with rules-based checks wherever the property is mechanical, since a deterministic check can’t be talked into a pass and it catches things that are simply missing. Then use a model for the judgment work, like spotting gaps, contradictions, and assumptions nobody marked. One commenter runs all three in that order and says the order matters more than which one you pick.
Q: Does the reviewer need to see the writer’s reasoning?
One commenter found that context mattered more than which model did the reviewing. A reviewer who gets the author’s summary tends to review the summary. A reviewer who gets only the artifact, cold, with a hunting brief, catches the real problems, because reasoning is advocacy and reading it pulls the reviewer toward grading the argument instead of the work.
Q: How do I make sure a rules check can actually fail?
A check that only counts matching files can pass while the real defect sits in files nobody listed. One commenter’s rule is that a check passes only when its failure set has been enumerated and is empty. List everything that could go wrong, including what is absent, and confirm the check tests that full list.
Q: Is it worth tracking where each claim came from?
A commenter suggested marking provenance for each claim, not just each assumption, so you know which step produced a line and what input it used. When the reviewer finds a gap, you can then see which step tends to hallucinate and under what conditions. That turns review from quality control into a way to see where your chain breaks.
What I learned building a 5-step prompt pipeline that writes prompts for AI builders
by u/Nothing_123_ in PromptEngineering