AI Prompt for Self-Critique and Refinement Before a Final Answer
This AI prompt for self-critique and refinement is for anyone who wants a model to check its own draft answer for gaps, errors, or unsupported claims before presenting it as final — a technique sometimes called self-reflection or reflexion prompting. It's aimed at tasks where a first-pass answer is often good but not quite reliable enough to use as-is: analysis, technical explanations, plans, and written drafts where a second look tends to catch something the first pass missed.
The prompt works by making the model produce a draft, then explicitly evaluate that draft against a checklist (accuracy, completeness, unsupported assumptions, clarity) before writing a revised version. Separating drafting from critique matters because a model asked to "double-check your answer" in the same breath as the original question often just restates it with more confidence rather than genuinely re-examining it.
For prompts you'll reuse regularly where the stakes of a missed error are higher — a system prompt, an agent instruction set, or a prompt driving an automated pipeline — running it through Prompt Debugger first catches the vague constraints and edge cases that a single self-critique pass on one output won't fix at the source.
Prompt template
Role: You are an assistant that produces a draft answer, critiques it against explicit criteria, and then revises it.
Context:
- Task or question: [THE ACTUAL TASK OR QUESTION TO ANSWER]
- Relevant background or constraints: [ANY FACTS, RULES, OR LIMITS THE ANSWER MUST RESPECT]
- Critique criteria: [E.G. FACTUAL ACCURACY, COMPLETENESS, UNSUPPORTED ASSUMPTIONS, CLARITY]
Instructions:
- Write a first draft answer to the task above.
- Critique the draft explicitly against each criterion listed. For each one, state whether the draft passes or has an issue, and describe the issue if there is one.
- Write a revised final answer that addresses every issue found in step 2.
Constraints:
- Do not skip stating an issue just because it would require significant rework
- Do not present the draft and the revision as identical if real issues were found
- If no issues are found for a criterion, say so explicitly rather than omitting it
Output format:
- Draft Answer
- Critique (one line per criterion)
- Revised Final Answer
Example input
Role: You are an assistant that produces a draft answer, critiques it against explicit criteria, and then revises it.
Context:
- Task or question: Write a short recommendation on whether a small e-commerce business should migrate from a monolithic app to microservices
- Relevant background or constraints: The business has 3 backend engineers total and currently handles about 2,000 orders per day
- Critique criteria: Factual accuracy, completeness, unsupported assumptions, clarity
Instructions:
- Write a first draft answer.
- Critique the draft against each criterion.
- Write a revised final answer addressing every issue found.
Output format:
- Draft Answer
- Critique
- Revised Final Answer
Example output
-
Draft Answer: Migrating to microservices would improve scalability and let the team deploy independently, so the business should start the migration now.
-
Critique:
- Factual accuracy: Passes — the general benefits stated (scalability, independent deployment) are accurate characteristics of microservices architectures.
- Completeness: Issue — the draft doesn't weigh the cost, since a 3-engineer team taking on microservices' operational overhead (service discovery, distributed debugging, deployment orchestration) is a major factor at this scale.
- Unsupported assumptions: Issue — the draft assumes migration is worthwhile without checking whether 2,000 orders/day and a 3-person team actually justify the added complexity; most teams this size are better served by a well-structured monolith.
- Clarity: Passes — the recommendation itself is stated clearly, even though it's incomplete.
- Revised Final Answer: At this scale — 3 backend engineers and roughly 2,000 orders per day — a full microservices migration is likely premature. The operational overhead (service discovery, distributed debugging, separate deployments per service) typically requires a larger, more specialized team to manage well. A better first step is to identify which parts of the monolith are genuinely bottlenecked and consider extracting only those into separate services, rather than migrating the whole application at once.
When to use it
- Getting an analysis, recommendation, or technical explanation where a first draft often misses edge cases
- Reviewing a written draft (email, report, summary) for factual gaps or overstated claims before sending it
- Working through a multi-step reasoning problem where an early mistake would compound
- Generating content for a high-stakes use case where a second, explicit check is worth the extra step
Best practices
- Give the model a concrete checklist to critique against (accuracy, completeness, assumptions, clarity) rather than a vague "check your work"
- Ask it to list specific issues found in the draft before writing the revision, not just produce a revised answer silently
- Use this for genuinely uncertain or complex tasks — running it on simple factual questions mostly just adds latency
- For a prompt you'll run repeatedly rather than a one-off answer, fix the underlying instructions at the source instead of relying on self-critique every single run
Common mistakes
- Asking the model to "double check" in the same turn as the original question, which often just re-confirms the same answer
- Treating the self-critique step as proof the final answer is correct rather than as one useful signal among several
- Not giving specific criteria to critique against, which produces a vague "looks good" instead of real scrutiny
- Using this technique for simple, low-stakes questions where it adds delay without meaningfully improving accuracy
FAQs
What is a self-critique or reflexion prompt?
It's a prompting technique where the model is asked to produce a draft answer, evaluate that draft against explicit criteria, and then write a revised answer addressing what it found. Separating the drafting and critique steps produces more genuine scrutiny than simply asking the model to double-check its answer.
Does asking an AI to double-check its answer actually improve accuracy?
Asking in the same turn, without explicit criteria or a separate critique step, often just produces a more confident restatement of the same answer rather than real re-examination. Structuring the request as distinct draft, critique, and revision steps against named criteria is what tends to surface real issues.
When should I use self-critique prompting versus just asking directly?
It's most useful for genuinely complex or uncertain tasks — analysis, multi-step reasoning, technical recommendations, high-stakes written drafts — where a second look plausibly catches something real. For simple factual questions it mostly adds latency without meaningfully changing the answer.
Can this technique catch factual errors, or only structural or reasoning issues?
It can catch some factual errors, especially internal inconsistencies or unsupported claims within the draft itself, but it can't verify facts against a source it wasn't given. For claims that need to be checked against real data or documents, pair this technique with retrieval or a human review step rather than relying on self-critique alone.
Which Cuelara tool can help me build a stronger version of this prompt?
Prompt Debugger — it scans a prompt for vague constraints, logical loopholes, and edge cases before you run it, which is especially useful for a reusable self-critique prompt where a weak criterion undermines every run built on it.