Prompting

Principles and techniques for writing clear, effective LLM prompts that produce consistent, high-quality output.

Core Principles

• Be clear and specific — Treat the model as a skilled worker with zero context. Spell out the task, audience, purpose, and what success looks like. Replace vague quantifiers ("keep it short") with concrete ones ("2-3 sentences").

• Say what TO do, not what NOT to do — Positive instructions ("respond in formal tone") outperform negative ones ("don't be casual").

• Structure the prompt — Use sections, headers, or delimiters to separate role, instructions, context, examples, and output format.

• Set a role — A specific persona improves accuracy, tone, and depth. Be precise: "You are a senior backend engineer reviewing a pull request" beats "You are a developer."

• Specify the output format — Never assume defaults. Define: format (bullets, JSON, prose), length, tone, structure.

• Provide examples — 3-5 diverse examples dramatically improve output quality. Examples should be relevant, varied, and clearly delimited.

• Give context — Who is the audience, what is the purpose, where does this fit in a larger workflow.

• Let it think — For complex tasks, instruct step-by-step reasoning. Don't suppress the thinking.

• Permit uncertainty — Let the model say "I don't know" rather than fabricate answers.

Prompt Structure Template

Role and Objective

[Who the model is and what it should accomplish]

Instructions

[Numbered steps for the task]

Context

[Background information, audience, purpose]

Output Format

[Exact format, length, tone specifications]

Examples (optional)

[3-5 input/output pairs wrapped in delimiters]

Formatting Rules

• Use markdown headers (## ) to separate sections

• Use XML tags (<context> , <example> , <output> ) when nesting is needed

• Use numbered lists for sequential steps

• Use bullet points for parallel items

• Keep the prompt scannable — a human should be able to skim and understand the structure

Common Mistakes to Avoid

• Vague instructions ("make it good") → be concrete about quality criteria

• Missing context → always state audience, purpose, constraints

• No output format → always specify format, length, tone

• Mixing instructions with data → use delimiters to separate

• Over-engineering → start simple, add complexity only when needed

Quality Checklist

Apply before outputting the final prompt:

• Has a clear role or persona

• Instructions use action verbs (Write, Classify, Summarize, Analyze)

• Output format is explicitly defined

• Audience and purpose are stated

• Examples are included if the task involves specific formatting

• No vague quantifiers remain

• No negative instructions where positive ones would work