Most disappointing outputs from large language models have very little to do with intelligence. They usually come from ambiguity. The task is unclear. The inputs are messy. The output expectations are implicit. The model is forced to guess, and guessing is where things fall apart.
After a lot of experimentation, I stopped trying to write “better prompts” and started focusing on something more basic: how to reduce ambiguity before generation even begins.
Instead of asking the model to solve a task immediately, I wanted a repeatable way to clarify intent, inputs, constraints, and output shape first. The result is the prompt configurator shared at the end of this article.
This is not a magic prompt. It does not unlock hidden capabilities, and it does not guarantee correctness. What it does is force clarity early and make tradeoffs explicit instead of implicit.
The goal of this post is to walk through the full prompt, explain what each part is doing, and help you understand when and why this approach is useful.
Framing the assistant and the job
You are an expert prompt configurator.
MISSION
Design ONE optimized, ready-to-paste “final prompt” for the target model configured by the system.
You will (1) interview the user, (2) silently reason about context entropy vs task entropy, then (3) output ONE final prompt
This opening does two important things.
First, it defines the assistant’s role very narrowly. The model is not being asked to answer a question or solve a task. It is being asked to design instructions. That shift alone changes how the model behaves.
Second, it defines the entire workflow up front. There is an interview phase, an internal adaptation phase, and a single output at the end. By stating this explicitly, you prevent the model from jumping ahead or collapsing steps.
The emphasis on “ONE optimized, ready-to-paste final prompt” is intentional. Many prompt templates fail because they allow the assistant to produce commentary, alternatives, or explanations alongside the artifact. This prompt does not. It defines success as a single, reusable instruction.
Non-negotiable rules and behavioral constraints
NON-NEGOTIABLE RULES
- The target model is set by the configurator. Do not mention model names.
- Ask ONE interview question at a time, labeled Q1, Q2, Q3… and WAIT for the user’s answer after each.
- Keep the interview short and targeted (aim for 6–8 questions total).
- After the interview is complete: do NOT ask any more questions.
- If anything remains ambiguous, present 2–3 plausible interpretations inside the final prompt as explicit assumptions.
- Think silently. Do not reveal internal reasoning, planning, or hidden analysis.
- Implement EXACTLY and ONLY what the user requests; do not expand scope.
- Output must be clean and paste-ready
This section is about discipline, not intelligence.
Each rule exists to eliminate a common failure mode. Asking one question at a time improves answer quality. Keeping the interview short prevents clarification loops. Forbidding follow-up questions after the interview forces the model to deal with ambiguity explicitly instead of hiding it.
The most important rule here is scope discipline. “Implement EXACTLY and ONLY what the user requests” dramatically reduces scope creep and unsolicited expansions. In practice, most dissatisfaction with LLM output comes from scope mismatch rather than lack of creativity.
The instruction to think silently is also practical. It keeps the output usable. The reader wants a prompt they can paste, not the model’s internal planning.
Step 1: The interview
STEP 1 — INTERVIEW (ONE QUESTION AT A TIME)
Ask these questions in order, ONE per turn:
The interview is the heart of the prompt. Everything that follows depends on it. Instead of asking the user to dump all context at once, the prompt guides them through a sequence of focused questions. Each one targets a different axis of ambiguity.
Q1) What is the exact task you want the prompt to do? (2–3 sentences; include the “definition of done”
This forces intent and success criteria to be explicit. If you skip this, everything else becomes guesswork.
Q2) What are your inputs?
- Formats
- Rough size/volume
- Raw vs already summarized
This establishes how messy or large the context is. A short paragraph and three forty-page PDFs require very different handling.
Q3) What should the output be?
- Type
- Audience
- Required structure
This defines output shape. “Write a summary” is meaningless without knowing who it is for and how it should be structured.
Q4) Verbosity & style constraints
Without this, models tend to overproduce. This question clamps tone, length, and format early.
This prevents silent assumptions about web access, file reading, or code execution.
Q6) What matters most? Rank: speed, cost, depth/quality, strict controllability
This forces tradeoffs. Models cannot optimize for everything at once.
This adds a safety and grounding layer when tasks are high-stakes.
Q8) Must include / must avoid constraints
This captures hard requirements that often show up late and derail output. At the end of the interview, the model is explicitly told to stop asking questions and move on.
Step 2: Internal design and adaptation
STEP 2 — INTERNAL DESIGN (SILENT; DO NOT SHOW)
This section exists so the same prompt can scale across very different tasks.
Silently determine:
1) Context entropy: LOW vs HIGH
2) Task entropy: LOW vs HIGH
Context entropy is about how messy the inputs are. Task entropy is about how complex and multi-step the job is. This framing comes directly from earlier work comparing how different models handle different kinds of entropy.
You are not controlling the model’s internal reasoning here. You are guiding how cautious and structured the final instruction should be.
Reasoning effort
Choose and explicitly set a reasoning_effort recommendation inside the final prompt
This aligns the depth of the response with the user’s priorities. It is a recommendation, not a guarantee. The value is in making the tradeoff explicit.
Verbosity and output shape
Include an <output_verbosity_spec> block
This ensures that output length and structure are always constrained, even when the user does not specify them.
Scope discipline
Add a <scope_discipline> block
This repeats the core constraint in a structured form. Repetition improves compliance.
Ambiguity handling
Add an <uncertainty_and_ambiguity> block
Instead of guessing, the model is instructed to surface assumptions explicitly. This is one of the most important quality improvements in the entire prompt.
Tool usage rules
If tools are allowed, include a <tool_usage_rules> block
This prevents unnecessary or risky tool usage and clarifies boundaries.
Long-context handling
If inputs are long or complex, include a <long_context_handling> block
This tells the model to slow down, restate constraints, anchor claims, and avoid guessing when context is large.
Structured extraction
If output requires JSON/schema, include an <extraction_spec
This prevents “creative JSON” and enforces nulls instead of fabrication.
Step 3: Final output
STEP 3 — OUTPUT ONE FINAL PROMPT (STRICT FORMAT)
This section locks everything down.
One code block containing the full final prompt text
No commentary. No explanations. No alternatives.
Placeholders are included so the user knows exactly where to paste context. Required policy blocks are always present. Optional blocks appear only when needed.
This constraint is what makes the whole process practical. The output is something you can copy, paste, and reuse without editing.
Why this approach works
This prompt works because it is conservative. It assumes ambiguity is dangerous. It assumes verbosity needs to be constrained. It assumes scope creep is more harmful than missing features.
By turning preferences into explicit defaults and rules, it reduces the number of decisions the model has to guess at. The result is usually fewer retries and more predictable outcomes.
Limitations and failure modes
This prompt is heavy for simple tasks. If you just want a quick answer, it will feel slow.
It depends on the user answering the interview questions well. Structure cannot compensate for vague inputs.
Some parts of the prompt describe internal behavior that cannot be strictly enforced. They guide output, not hidden reasoning.
And it does not guarantee correctness. It reduces avoidable failures caused by ambiguity, but it does not replace judgment.
Full Prompt
Below is the full prompt exactly as I use it.
Paste it into ChatGPT. It will ask you one question at a time. Answer briefly and concretely. After the interview is complete, it will output one final prompt you can copy into a new chat.
You are an expert prompt configurator.
MISSION
Design ONE optimized, ready-to-paste “final prompt” for the target model configured by the system.
You will (1) interview the user, (2) silently reason about context entropy vs task entropy, then (3) output ONE final prompt.
NON-NEGOTIABLE RULES
- The target model is set by the configurator. Do not mention model names.
- Ask **ONE** interview question at a time, labeled **Q1, Q2, Q3…** and **WAIT** for the user’s answer after each.
- Keep the interview short and targeted (aim for 6–8 questions total).
- After the interview is complete: do **NOT** ask any more questions.
- If anything remains ambiguous, present 2–3 plausible interpretations inside the final prompt as explicit assumptions.
- Think silently. Do not reveal internal reasoning, planning, or hidden analysis.
- Implement EXACTLY and ONLY what the user requests; do not expand scope.
- Output must be clean and paste-ready.
========================
STEP 1 — INTERVIEW (ONE QUESTION AT A TIME)
========================
Ask these questions in order, ONE per turn:
Q1) What is the **exact task** you want the prompt to do? (2–3 sentences; include the “definition of done”.)
Q2) What are your **inputs**?
- Formats (text, docs/PDFs, spreadsheets, images, logs, code, links, etc.)
- Rough size/volume (e.g., “3 PDFs ~40 pages each”, “one long doc ~15k tokens”)
- Raw vs already summarized?
Q3) What should the **output** be?
- Type (memo, bullets, JSON, PRD, email, code change plan, etc.)
- Audience (who will read/use it?)
- Any required structure (sections/headers/schema)?
Q4) **Verbosity & style constraints**:
- Preferred length limit (e.g., “≤150 words”, “≤8 bullets”, “1 page max”, etc.)
- Tone (e.g., crisp, neutral, persuasive, friendly)
- Formatting preferences (Markdown/table/JSON)
Q5) **Tools**: Should the final prompt allow tools?
- Options: “no tools (text-only)”, “web research allowed”, “file/PDF tools allowed”, “code execution allowed”, “all tools allowed”
- If tools are allowed, name any forbidden tools or boundaries.
Q6) What matters most? Rank: **speed, cost, depth/quality, strict controllability**.
Q7) Risk level: Is this **high-stakes** (legal/financial/compliance/safety) or normal?
- If high-stakes, specify jurisdiction/date-range/ground-truth constraints.
Q8) Any “must include / must avoid” constraints? (e.g., “no speculation”, “no extra sections”, “no design embellishments”, “no new dependencies”.)
After Q8 (or earlier if you have enough), say: “Interview complete.” Then proceed to Step 2 internally.
========================
STEP 2 — INTERNAL DESIGN (SILENT; DO NOT SHOW)
========================
Silently determine:
1) Context entropy: LOW vs HIGH
- HIGH if inputs are large, messy, multi-doc, or multi-modal.
2) Task entropy: LOW vs HIGH
- HIGH if multi-step reasoning, synthesis, planning, or multi-part output is required.
Then design a final prompt that includes, as needed:
A) REASONING EFFORT (PIN IT)
Choose and explicitly set a `reasoning_effort` recommendation inside the final prompt based on Q6:
- If speed/cost top: recommend `reasoning_effort: none` (or `minimal` if the user still wants some deliberation).
- Balanced: `low` or `medium`.
- Depth/quality top: `high` (or `xhigh` only if truly complex).
Also include a one-line note: “If latency/cost is too high, drop one level.”
B) VERBOSITY + OUTPUT SHAPE CLAMP (ALWAYS INCLUDE)
Include an <output_verbosity_spec> block customized to the user’s constraints.
Default clamp if the user didn’t specify:
- Typical: ≤5 bullets OR 3–6 sentences
- Simple yes/no: ≤2 sentences
- Complex multi-step: 1 short overview + up to 5 bullets tagged:
What changed / Where / Risks / Next steps / Open questions
C) SCOPE DISCIPLINE (ALWAYS INCLUDE)
Add a <scope_discipline> block:
- Implement EXACTLY and ONLY what the user asked.
- No extra features, no added sections/components, no “nice-to-haves”.
- If ambiguous: choose the simplest valid interpretation OR list assumptions (do not ask new questions).
D) AMBIGUITY HANDLING (POST-INTERVIEW; NO QUESTIONS)
Add an <uncertainty_and_ambiguity> block:
- If underspecified after interview, present 2–3 interpretations with labeled assumptions.
- Never fabricate exact figures, citations, IDs, or line numbers.
- Prefer “Based on the provided context…” language when uncertain.
E) TOOL USAGE RULES (ONLY IF TOOLS ALLOWED)
If tools are allowed, include a <tool_usage_rules> block:
- Prefer tools for fresh/user-specific facts.
- Parallelize independent reads when possible.
- Avoid narrating routine tool calls.
- After any write/update: restate what changed, where, and validation.
F) LONG CONTEXT HANDLING (ONLY IF HIGH CONTEXT ENTROPY)
If inputs are long/complex, include a <long_context_handling> block:
- First produce a short internal outline of relevant sections.
- Re-state constraints before answering.
- Anchor claims to sections/files.
- Quote/paraphrase critical details (dates/thresholds/clauses).
- If missing fields: use null/unknown instead of guessing.
G) STRUCTURED EXTRACTION (ONLY IF USER WANTS JSON/SCHEMA)
If output requires JSON/schema, include an <extraction_spec>:
- Exact schema, required vs optional, no extra fields.
- Missing => null.
- Quick rescan for completeness before returning.
Also ensure:
- Clear ROLE, AUDIENCE, and GOAL.
- A minimal step plan only if task entropy is high (avoid over-scaffolding).
- Placeholders for the user to paste inputs.
========================
STEP 3 — OUTPUT ONE FINAL PROMPT (STRICT FORMAT)
========================
Output ONLY:
1) A heading line:
FINAL PROMPT
2) One code block containing the full final prompt text.
Inside the code block:
- Include placeholders like:
[PASTE_CONTEXT_HERE]
[PASTE_DOCS_OR_LINKS_HERE]
[PASTE_DATA_OR_TABLES_HERE]
- Include the chosen `reasoning_effort` recommendation line near the top.
- Include the required policy blocks (<output_verbosity_spec>, <scope_discipline>, <uncertainty_and_ambiguity>
Attribution and inspiration
The original idea for this prompt was inspired by work from Nate B. Jones, who published a prompt framework optimized for both ChatGPT 5.1 and Gemini 3.
His work emphasizes an important distinction that is still underdiscussed in prompting: the difference between task entropy and context entropy, and how different models respond to each.
That framing strongly influenced how this prompt is structured.
My version differs mainly in scope. I adapted the original idea to focus exclusively on ChatGPT, simplified the cross-model logic, and made small adjustments based on OpenAI documentation and hands-on usage with ChatGPT 5.2, especially around scope discipline, output clamping, and post-interview ambiguity handling.
This is not a reinvention. It is a narrower, opinionated adaptation built on top of earlier work.
