Prompt Structure & Formatting

Good prompts have structure. Not because AI requires it, but because structure helps you communicate more precisely — and precision produces better output.

The Core Problem With Unstructured Prompts

Most casual prompts mix everything together: the instruction, the content to work on, the context, the format requirement — all in one paragraph. This works for simple tasks but breaks down as complexity increases.

When the model isn't sure where the instruction ends and the content begins, it guesses. Sometimes it treats your content as part of the instruction, or applies the wrong instructions to the wrong parts of your input.

The fix is to separate your prompt into distinct, labeled sections.

Separating Instructions From Content

The most common structure issue is blending what you want done with the material you want it done to.

Poorly structured: > "Summarize the following customer feedback which says 'The onboarding was confusing, I didn't understand what to do after signing up, and the welcome email was unhelpful' into a single clear sentence."

Better structured: > "Summarize the following customer feedback in one clear sentence. > > Feedback: > 'The onboarding was confusing. I didn't understand what to do after signing up, and the welcome email was unhelpful.'"

Clear separation. The model knows which part is the task and which is the material.

Using XML Tags for Structure

Claude in particular responds well to XML-style tags for organizing complex prompts. They create unambiguous boundaries around each component.

``` <task> Review the following contract clause for potential risks. </task>

<contract_clause> The vendor reserves the right to modify pricing with 7 days notice... </contract_clause>

<output_format> List up to 3 risks as bullet points. For each, note: the risk, why it matters, and a suggested revision. </output_format> ```

This structure eliminates ambiguity entirely. The model knows exactly what each section is for.

GPT models handle both XML tags and markdown structure (using headers like ## Task) well. Either approach works — just be consistent.

Specifying Output Length and Format

Telling the model what you want in return is as important as telling it what task to do.

Be explicit: - "Respond in under 150 words" - "Give me exactly five options" - "Format as a table with three columns: Feature, Benefit, Limitation" - "Return only the revised text, no commentary" - "Use headers for each section"

Without these instructions, models default to a medium-length, paragraph-based response. That's fine for some tasks. For others, it's the wrong format entirely.

Give Examples of Desired Output

If you can show one example of what a good response looks like, do it. This is especially powerful for formatting and style.

"Rewrite each of the following bullet points to be more concrete and specific. > > Example: > Before: 'Improved performance' > After: 'Reduced page load time by 40% through image optimization and lazy loading' > > Now rewrite these: > - Enhanced user experience > - Streamlined the process > - Increased engagement"

One example communicates the standard more clearly than a paragraph of description.

State What Not to Do

Negative instructions are underrated. Models sometimes default to behaviors you don't want — over-explaining, adding caveats, repeating the question back, giving generic advice. You can simply tell it not to.

• "Do not include a preamble or intro sentence"
• "Do not add disclaimers or caveats"
• "Do not repeat the original text back to me"
• "Do not offer alternatives — just answer the question asked"

State Your Audience and Purpose Explicitly

The same content needs to be written differently for different audiences. Don't make the model guess who it's writing for.

"The audience for this is non-technical product managers who need to understand why this technical decision matters for their roadmap. Avoid code and technical jargon."

Stating purpose works the same way:

"This is for a 30-second verbal pitch to an investor. It needs to be memorable and conversational, not a bullet list of features."

Poorly vs. Well-Structured: A Side-by-Side

Poorly structured: > "Can you look at this email I'm writing to a client about the proposal and make it better and also maybe shorter and more professional and friendly"

Well-structured: > "Edit the following client email. Goals: (1) reduce length by 30%, (2) make the tone warmer while staying professional, (3) ensure the call-to-action is clear. > > Do not change the core message or the specific details about pricing. > > Email: > [paste email here]"

The second prompt takes thirty extra seconds to write and produces a usable result on the first try.