Core Techniques

A handful of techniques cover the large majority of real prompting work. Master these before reaching for anything exotic.

Anatomy of a prompt

A well-built prompt usually has distinct parts. Naming them helps you spot what’s missing when output is bad:

Not every prompt needs all six, but if output is wrong, a missing or vague section is usually why.

Be specific — the first-order fix

Most bad output is a vague prompt, not a weak model. The model can’t read your intent; everything must be stated.

Weak:    Summarize this.

Strong:  Summarize the support ticket below in 2-3 sentences for an
         engineer triaging it. State the core problem and any error
         message. Omit pleasantries and signatures.

State the audience, the length, what to include, what to exclude, and the tone. Specificity is the cheapest, highest-impact technique there is.

System prompts

The system prompt sets durable, request-independent behavior: the model’s role, rules, scope, and default format. The user message carries the task-specific input.

messages = [
    {"role": "system", "content":
        "You are a SQL assistant for a Postgres database. "
        "Only produce SELECT statements — never write or modify data. "
        "If a request needs a write, refuse and explain why."},
    {"role": "user", "content": "Show the 10 newest signups."},
]

Put guarantees and guardrails in the system prompt — it’s the most stable place to enforce them.

Zero-shot vs. few-shot

Zero-shot — instructions only, no examples. Modern models are strong zero-shot; always try it first, since it’s the cheapest.

Few-shot — include a few worked examples of input → output. Reach for it when:

• The output format is specific and easier to show than describe.
• The task has nuance — edge cases, a particular labeling style.
• Zero-shot results are inconsistent.

Classify the sentiment as positive, negative, or neutral.

Review: "Shipping was slow but the product is great."   Sentiment: positive
Review: "Exactly what I expected, nothing special."     Sentiment: neutral
Review: "Broke within a week. Very disappointed."        Sentiment: negative
Review: "The setup was confusing and support never replied."  Sentiment:

Make example outputs identical in format to what you want — the model copies the pattern, format flaws included. Cover your edge cases; pick diverse examples.

Chain-of-thought (CoT)

For reasoning, math, or multi-step logic, asking for the answer directly often fails — the model commits before it has “worked it out.” Chain-of-thought prompts it to reason first.

Work through this step by step, then give the final answer.

This genuinely improves accuracy on logic and math, because each generated reasoning token conditions the next — the model is computing, not just recalling.

CoT has a cost, and a caveat

Reasoning tokens are output tokens — CoT means more latency and more cost. And the stated reasoning is a plausible narrative, not a guaranteed faithful trace of the model’s internals — a correct answer can follow flawed-looking steps, and vice versa. Use CoT for genuinely multi-step problems; skip it for simple lookups and classification. Many current models reason internally by default, reducing the need to ask explicitly.

Give the model an out

If a task may be impossible — context lacks the answer, input is malformed — tell the model what to do then. Without an exit, it invents something.

If the context does not contain the answer, reply exactly: "NOT_FOUND".
Do not guess.

Key takeaways

Build prompts from clear parts and treat specificity as the primary tool — most bad output is a vague instruction. Put durable rules in the system prompt. Try zero-shot first; add few-shot examples when format or nuance demands it, keeping example outputs format-identical. Use chain-of-thought for genuine multi-step reasoning, accepting its cost. Always give the model an explicit exit for impossible cases.