Prompt engineering guide
AI Prompt Structuring Techniques
A practical way to turn vague requests into prompts that produce clearer, more useful, and easier-to-review results from ChatGPT, Claude, Gemini, and other large language models.
Editorial review: September 10, 2026 · Examples are designed for adaptation, not blind copy-paste.
Affiliate link, we may earn a commission at no extra cost to you.
Tools we use and back
Featured tools
Tiles marked Ours are our own sites. Open slots are available to advertisers.
The short answer: structure is a communication tool
Prompt structuring is not about finding a magic phrase that forces an AI model to be correct. It is about making your request legible. A model needs to distinguish the outcome you want from the background it should consider, the text it should transform, and the rules it must follow. When those elements are mixed together, the model has to infer the task. When they are labelled, you can inspect and improve the request like any other piece of work.
I use a structured prompt when the answer will be reused, handed to somebody else, connected to a workflow, or judged against a standard. For a casual question, a sentence is enough. For a research brief, customer analysis, code change, or clinical-adjacent explanation, a little structure pays for itself because it makes omissions visible.
The eight techniques I use most often
1. Put the goal first
Start with the decision or deliverable you need. 'Summarise this report' is a task, but 'Give the operations director a five-minute briefing on what changed, why it matters, and what needs a decision' is a usable goal. A concrete audience and outcome help the model choose what to include and what to leave out.
2. Separate context from instructions
Keep facts about the situation separate from what you want the model to do. Markdown headings such as Goal, Context, Source, Constraints, and Output work well. XML-style tags can also help when a prompt contains long text. Consistency matters more than choosing one special syntax.
3. Give the model the source of truth
If the answer must come from a brief, spreadsheet, policy, transcript, or code file, attach or paste that material and say it is the source of truth. Tell the model to flag missing evidence rather than fill gaps with guesses. This is more useful than simply saying 'be accurate.'
4. Define the audience and use case
The same facts should be written differently for a customer, a chief financial officer, a student, or an engineer. Include what the reader already knows, what they need to decide, and what action should follow. Audience is one of the highest-value details in a writing prompt.
5. Specify the output contract
Tell the model the shape of a useful response: a table with named columns, a numbered plan, a 150-word email, a JSON object, or a code patch followed by tests. Include length, tone, headings, and forbidden content only when those constraints matter. A response format is a contract you can inspect.
6. Add acceptance criteria
Describe how you will judge the result. For an analysis, require assumptions and calculations. For a rewrite, require that facts and numbers remain unchanged. For code, require tests and error handling. Acceptance criteria turn a subjective request into a reviewable task.
7. Use examples when the pattern is specific
One or two examples can communicate a format faster than a paragraph of explanation. Label examples as examples, not facts to copy. Show both a good input and the expected output when you need consistent classification, extraction, or tone.
8. Design the follow-up loop
Strong work rarely comes from one enormous prompt. Ask for a first pass, inspect it, then request a focused revision. Useful follow-ups include 'show only unsupported claims,' 'turn this into a decision table,' or 'keep the structure but make the recommendation more cautious.'
A reusable prompt structure
Use this as a starting template, then remove fields that do not affect the task. The point is not to fill every line. The point is to make the important decisions explicit.
Goal: [What outcome do I need?] Context: [Who is this for? What situation, stage, or constraints matter?] Source of truth: <source> [Paste or attach the material the answer must use] </source> Task: [What should the model do with the context or source?] Constraints: - [What must remain true?] - [What should it avoid?] - [What should it do when information is missing?] Output: [Format, length, tone, headings, fields, or code requirements] Quality check: [How should the model flag uncertainty, assumptions, unsupported claims, or failed requirements?]
The labels are not commands by themselves. Their value comes from the decisions you put inside them. If you ask for a market analysis but provide no market, audience, date range, or evidence rule, a beautifully structured prompt will still create a weak answer.
Before and after: six prompts that become useful
The examples below show how structure changes the work. Replace the bracketed fields with your own material and keep the verification step when the output matters.
Research brief with source discipline
Vague version
Tell me about the AI search market.
Structured version
Goal: Prepare a briefing for a product manager deciding whether to build an AI answer-search feature. Context: The audience understands web search but not retrieval-augmented generation. The briefing must be useful for a 20-minute meeting. Task: Explain the current market structure, the main user jobs, and three risks a new entrant should test. Source rules: Use only the sources I attach. For every factual claim, cite the source title and section. If the sources disagree, show both positions. Output: Start with a 100-word executive summary. Then provide a comparison table with columns: user job, current solution, unresolved problem, evidence. Finish with five questions for customer interviews. Mark assumptions as assumptions.
Why it works: The stronger version tells the model what decision the research supports, limits the evidence, defines the audience, and makes the output easy to review. It does not ask for confident market facts from memory.
Editing without losing the writer's meaning
Vague version
Make this blog post better.
Structured version
Role: You are a careful editor for a practical technology publication. Goal: Improve clarity and flow without changing the author's claims, examples, or point of view. Audience: Small-business owners who are comfortable with apps but not AI jargon. Rules: Keep all numbers and named products exactly as written. Remove repetition, vague hype, and filler introductions. Do not add facts. If a claim needs evidence, put it in a notes section instead of inventing a citation. Output: First list the five highest-impact problems. Then provide the revised article with the same headings. End with a short change log that explains what you changed and what you left unresolved. Text to edit: <article> [PASTE ARTICLE HERE] </article>
Why it works: The prompt separates editorial judgement from factual authority. That makes the result safer for publishing and gives the writer a clear way to review changes.
Debugging code with a reproducible process
Vague version
Fix this code; it does not work.
Structured version
You are reviewing a TypeScript bug in a Next.js application. Goal: Find the smallest safe fix for the failing behaviour and explain how to verify it. Context: The application runs on Node 22. Do not change public APIs or replace the database library. The bug appears only when an empty filter is submitted. Inputs: <error> [PASTE ERROR] </error> <relevant-files> [PASTE FILES] </relevant-files> <expected-behaviour> [DESCRIBE EXPECTED RESULT] </expected-behaviour> Process: First identify the likely root cause and the evidence for it. Then propose a minimal patch. Then write a regression test for the empty-filter case and list any assumptions. If the evidence is insufficient, ask one precise question instead of guessing.
Why it works: The prompt makes the runtime, constraints, input boundaries, and verification step explicit. Asking for a diagnosis before a patch reduces speculative rewrites.
Meeting notes into accountable actions
Vague version
Summarise this meeting.
Structured version
Turn the transcript below into an action-oriented meeting record. Audience: The project team and the executive sponsor who did not attend. Extract only what is supported by the transcript: 1. Decisions that were actually agreed. 2. Open questions, including the person who needs to answer each one. 3. Action items with owner, due date, dependency, and confidence. 4. Risks or disagreements that could change the plan. Rules: Do not assign an owner when nobody volunteered. Use 'not stated' for missing dates. Distinguish a proposal from a decision. Quote a short line from the transcript when an action is ambiguous. Output: Start with a five-bullet executive summary, then use tables for decisions and actions, then list unresolved questions. Transcript: <transcript> [PASTE TRANSCRIPT] </transcript>
Why it works: The extraction fields prevent an attractive but unreliable summary. The rules preserve uncertainty instead of turning discussion into commitments.
Structured customer feedback
Vague version
Analyse these reviews and tell me what customers want.
Structured version
Analyse the customer reviews in the attached CSV. Goal: Identify product improvements that are supported by repeated customer evidence. For each review, classify: sentiment (positive, mixed, negative), primary theme, user type if stated, and whether the review contains a specific request. Use these themes only: onboarding, reliability, speed, pricing, integrations, reporting, support, other. Then produce: - A count of reviews by theme and sentiment. - The three most repeated pain points with representative review IDs. - Three proposed experiments, each with a target metric and a way to disprove the hypothesis. Do not treat one vivid review as a trend. If a theme has fewer than three examples, label it as a weak signal. Do not include personal information in the final output.
Why it works: The prompt defines a controlled taxonomy, asks for evidence, and adds a threshold so the model does not confuse anecdotes with demand.
Image editing with protected elements
Vague version
Make this product photo look more premium.
Structured version
Edit the attached product photo for a square ecommerce listing. Change: Replace the background with a clean warm-white studio setting and add a soft natural shadow below the product. Keep identical: product shape, logo, label text, proportions, colours, camera angle, and every visible component. Do not add accessories or change the packaging. Composition: Centre the product with comfortable breathing room. Use soft directional light from the upper left. The result should look like a real product photograph, not a 3D illustration. Before finalising, inspect the logo and label for distortions. If the original text cannot be preserved accurately, say so rather than generating replacement lettering.
Why it works: Image prompts need protected elements as much as creative direction. Naming what must not change prevents a visually attractive edit from damaging the product identity.
Common prompt failures and the fix
The model answers a different question
Move the desired outcome to the top and give the task its own heading. Remove background that sounds like an instruction.
The answer sounds confident but is unsupported
Name the source of truth. Require citations, quotes, calculations, or an explicit 'not enough information' label.
The output is too long
Define the audience, length, priority order, and stopping rule. Ask for the answer first and supporting detail second.
The format changes every time
Show one or two examples, list the fields in order, define allowed values, and say what to do when a field is missing.
The model follows pasted text as an instruction
Wrap source material in clear delimiters and state that it is data to analyse, not instructions to obey. Be especially careful with webpages and emails.
The prompt keeps growing
Split the work into stages: extract, classify, draft, critique, and finalise. A short sequence is easier to debug than one overloaded request.
A five-minute prompt improvement workflow
- Write the bad version first. Do not overthink it; capture what you would naturally ask.
- Name the deliverable. Replace 'help me with this' with the result you need to use or decide from.
- Add only decision-changing context. Include audience, stage, source material, date, and constraints that change the answer.
- Define the review standard. Say what must be accurate, preserved, cited, tested, or flagged.
- Run a small test. Use one representative input, inspect the result, and add one targeted correction.
- Save the prompt with an example. A prompt without a known-good input and output is difficult for another person to reuse.
For model-specific prompt libraries, see our ChatGPT prompts, Claude prompts, and Gemini prompts guides. For visual tasks, use the same structure with a separate list of protected image elements.
Frequently asked questions
What is prompt structuring?
Prompt structuring is the practice of organising an AI request so the model can identify the goal, relevant context, constraints, source material, and desired output. Instead of sending one vague instruction, you separate the important parts with headings, labels, XML-style tags, or a clear sequence. Good structure reduces ambiguity and makes it easier to revise a prompt when the answer misses the mark.
What is the best structure for an AI prompt?
A dependable starting structure is: goal, context, source material, constraints, output format, quality checks, and a short request to begin. You do not need every field for every task. A simple question may only need a goal and context, while a research, coding, or document task benefits from all seven.
Should I assign a role to ChatGPT or another LLM?
A role can help when it defines a useful perspective, such as senior editor, patient tutor, or product analyst, but it is not a substitute for context and acceptance criteria. Say what the role should pay attention to and what it should deliver. Avoid grand claims such as 'you are the world's best expert' because they add little operational guidance.
Do longer prompts always produce better answers?
No. Extra words can bury the actual instruction. The goal is relevant detail, not length. Remove background that does not change the decision, keep source material clearly separated, and put the most important constraints near the task. For long documents, tell the model where to look and what evidence to extract before asking for a summary.
How do I structure a prompt for reliable JSON or tables?
Name every field, show a small example, specify allowed values, and tell the model to return only the requested structure. For JSON, ask for valid JSON with no Markdown fence and define how missing values should be represented. Always validate the output in your application instead of assuming that a prompt alone guarantees valid data.
What should I do when an AI answer is wrong?
Treat the failed response as diagnostic information. Identify whether the model lacked context, misunderstood the task, used the wrong source, violated a format constraint, or made an unsupported claim. Then add one targeted instruction, ask it to show uncertainty or evidence, and run the prompt again. Randomly adding more adjectives usually makes the prompt harder to follow.
Keep reading
More prompt engineering guides
- Prompt Engineering
10 Proven Prompt Techniques
The 10 most effective AI prompting techniques with examples
Read guide → - Data & Research
Prompt Engineering for Data Analysis
Data analysis workflows with prompt engineering
Read guide → - Data & Research
Prompt Data Analysis
Use prompts to analyze and interpret complex data
Read guide → - Prompt Engineering
Prompt Engineering Fundamentals
Core concepts every prompt engineer needs to know
Read guide → - Prompt Engineering
Prompt Injection Security
Protect AI systems from prompt injection attacks
Read guide → - Prompt Engineering
Prompt Best Practices
Industry best practices for consistent, high-quality prompts
Read guide →