The "Illuminate → Solve → Refine" pattern: a minimalist loop that beats most fancy prompting
TL;DR
Three prompts in sequence — one to surface what the model needs to know, one to do the work, one to tighten the output — outperform elaborate chain-of-thought templates on real tasks because they fix the actual failure mode: the model solving the wrong problem.
Key takeaways
- The Illuminate step is not optional padding — it’s the prompt that gets the model to surface its assumptions before committing to an answer, catching scope mismatches before they cost you a full generation.
- Send Illuminate and Solve as separate messages, not a combined mega-prompt. Combined prompts let the model skip the assumption-surfacing step; separate turns enforce it.
- Refine is not “make it better” — give it a specific constraint: tighter, more formal, remove hedging, add one concrete example. Vague refinement instructions produce vague revisions.
- This loop works across all major frontier models (GPT-4o, Claude 3.5/3.7, Gemini 1.5 Pro) because it compensates for a universal failure mode, not a model-specific quirk.
- When a task needs more than three loops to converge, the Illuminate step was incomplete — restart it with a narrower scope rather than iterating endlessly on a flawed Solve.
Most prompting advice solves the wrong problem
The prompting discourse is obsessed with structure. Chain-of-thought. Tree-of-thought. ReAct. Skeleton-of-thought. COSTAR. Role-persona-task-format frameworks with four-part preambles. I’ve tried most of them. Across extensive Claude Max usage on real work tasks, the elaborate frameworks rarely beat a simple three-step loop.
The reason is that most prompting frameworks are trying to coax better reasoning out of a model that’s already reasoning fine. The actual failure mode in practice is different: the model solves the problem you wrote instead of the problem you meant. It answers confidently, completely, and wrongly scoped.
The Illuminate → Solve → Refine pattern addresses that failure mode directly. It’s not clever. It doesn’t require a 500-word system prompt. It’s three turns that enforce a discipline the fancier frameworks mostly skip.
What the three steps actually do
Illuminate is a prompt that asks the model to surface its understanding of the task before attempting it. Not “do you understand?” — that gets a confident yes every time. Specifically: “Before answering, state what you’re being asked to do, what assumptions you’re making, and what information would change your approach.”
This does three things. It externalises the model’s problem framing so you can catch scope mismatches early. It forces the model to identify missing context, which it will often flag accurately if you ask explicitly. And it prevents the common failure mode where the model pattern-matches to a superficially similar task type and runs with it.
A concrete example: consider someone drafting a scope-of-work for a data pipeline project. Without Illuminate, the model produces a detailed, confident SOW for a batch ETL system. With Illuminate first, it flags that it isn’t sure whether the pipeline is real-time or batch, and that this distinction would completely change the architecture section. That one flag saves a full rewrite.
Solve is then exactly what it sounds like: do the work. But because Illuminate has already locked in the scope, the Solve prompt can be short. Often it’s just “Now write it.” The model has already staged the thinking; the Solve turn executes it.
Refine is a targeted revision instruction with a specific constraint. Not “can you improve this?” — which produces marginal cosmetic edits. Something like: “Tighten this by 30%, cut all hedging language, and add one concrete example to the third paragraph.” Specific constraints produce specific improvements.
Illuminate → Solve → Refine
Why this beats chain-of-thought and template frameworks
Chain-of-thought prompting (“think step by step”) improves reasoning on tasks where the model’s reasoning process is the bottleneck — multi-step maths, logic puzzles, structured deduction. On reasoning-capable frontier models, this is less often the bottleneck than it was in 2022. GPT-4o, Claude 3.7 Sonnet, and Gemini 1.5 Pro already do structured reasoning without being told to. What they don’t do automatically is question their own problem framing.
Role-and-persona frameworks (“Act as a senior backend engineer with 15 years’ experience…”) address a different thing: tone and domain register. They’re sometimes useful for output style but they do nothing to fix scope mismatch. A model playing a senior engineer will still confidently answer the wrong question if you didn’t clarify the question first.
COSTAR, RTF, and similar template frameworks front-load all context into a single structured prompt. This is better than nothing, but it has a structural flaw: the model ingests all the context and then generates an answer in one pass. There’s no forced pause between understanding and execution. Illuminate → Solve forces that pause by making it a separate turn.
The separate-turn architecture is the key mechanism. When Illuminate and Solve are combined into one prompt (“First explain your understanding, then answer”), models frequently compress the illumination step — a sentence or two of boilerplate, then straight to the answer. Separate turns enforce the full stop. The model cannot shortcut past Illuminate because Illuminate is its entire response obligation for that turn.
Prompting Approaches Compared
| Criteria | ISR Loop | Chain-of-Thought | Template Frameworks |
|---|---|---|---|
| Catches scope mismatch | Yes | No | Partial |
| No long system prompt | Yes | Yes | No |
| Forces pause | Yes | No | No |
| Handles ambiguity | Strong | Partial | Partial |
When three turns is too many
The Illuminate → Solve → Refine loop has a real cost: it’s three turns where one prompt would have worked fine.
For well-specified, low-stakes tasks — “write a regex that matches ISO 8601 dates”, “summarise this paragraph in one sentence”, “convert this JSON to CSV” — the loop is overhead. The problem is unambiguous and the model’s scope interpretation doesn’t matter. Single-shot prompting is correct here.
The loop earns its cost when: the task has hidden assumptions (architecture decisions, audience-dependent writing, anything involving “business context”), the output will be used directly without review, or a bad Solve costs meaningful time to fix. Roughly: any task where you’d spend more than five minutes reviewing the output should probably go through the loop.
There’s also a context window consideration. Three turns consumes more context than one. For tasks inside long multi-turn sessions with heavy context, collapsing to a well-specified single prompt is sometimes the right call — you’re trading scope-checking for context headroom. In Claude’s 200k context or GPT-4o’s 128k context, this matters less than it did two years ago, but it’s not irrelevant.
The real reason simple patterns win
Elaborate prompting frameworks are often optimised for benchmark performance on clean, well-specified tasks — the kind with ground truth answers that can be scored automatically. Real work tasks don’t look like that. They’re ambiguous, under-specified, and the “correct” output depends on unstated context that neither you nor the model have fully articulated.
The Illuminate step is a forcing function for that articulation. It’s not about making the model smarter. It’s about surfacing what you haven’t said yet before the model commits to an answer.
After tracking prompting patterns across a range of real tasks, the single highest-leverage habit was not any framework — it was consistently sending Illuminate as a separate turn before asking for the actual output. The tasks that went wrong almost always skipped it.
LLMs, prompting, and getting useful output