How to write better prompts

Q: Why is being specific in a prompt important?

LLMs answer based on the words you give them. Clear, specific instructions narrow the answer space, so you get relevant output instead of a generic guess.

Q: What if the model ignores my instructions?

Try breaking the request into steps, giving an example of the format you want, or asking it to work through the problem before answering.

Getting a great answer from an LLM isn't luck – it's a skill. The model is a next-word predictor, but it's also a mirror: vague prompt in, vague answer out. Here's how to get what you actually want, every time – with patterns that survive contact with real models.

Source note: patterns below are model-agnostic prompting fundamentals that work on frontier APIs and local models alike; local-specific notes (temperature, context budgets) are lab-tested on 7B–35B open models – see lab benchmarks. For what these models are under the hood, start with what is an LLM.

1. Be specific, not polite

You don't need to say "please" or "could you". The model doesn't have feelings. What it needs is detail. Compare:

❌ "Explain how DNS works."
✅ "Explain how DNS works. Assume I know what IP addresses are but nothing
   about nameservers or TTLs. Use plain English and keep it under 4 paragraphs."

The second prompt constrains the answer – format, audience, length. The model will hit all three because it was told to.

2. Give it a role

Dropping the model into a persona immediately changes the quality of the output:

"You are a senior Python developer reviewing a junior's code. Look at the
function below and point out any bugs, style issues, or performance problems."

The role tells the model which "part" of its training data to draw from. "Senior developer" pulls from the code-review patterns it learned, not the generic-conversation ones.

Make roles concrete, not grandiose: “senior Python developer who enforces type hints and rejects bare excepts” beats “world-class genius”. On small local models keep one role per prompt – stacked personas (“lawyer-poet-chef”) dilute the signal that a 7B needs crisp. Pair the role with output shape (“list issues by severity, then the fixed function”) and the persona stops being flavor and starts being specification.

3. Provide examples (few-shot prompting)

One of the most reliable techniques is showing the model exactly what you want:

"Convert these sentences into a formal tone:

  Informal: 'Hey, can you fix this bug?'
  Formal: 'Please address the identified issue at your earliest convenience.'

  Informal: 'This code is slow.'
  Formal:"

The model sees the pattern and continues it. You've effectively written the first half of the answer yourself.

4. Chain of thought: ask it to think step by step

For reasoning-heavy tasks, add five words that dramatically improve accuracy:

"Think step by step before answering."

This forces the model to do its reasoning in the open, which reduces errors. It's especially effective for math, logic, and planning questions.

Why it works: the model's "reasoning" happens in the tokens it generates. If you make it write intermediate steps, those steps become part of the context for the final answer – and the next-token prediction is better informed.

5. Break it down

Complex requests get better results when split into steps. Instead of one giant prompt, have a short conversation:

You: "I want to write a blog post about Docker. Give me 5 topic ideas."
Model: [lists ideas]
You: "I like idea #3. Write an outline for it."
Model: [outline]
You: "Now write the introduction based on that outline."

Each step's output feeds into the next, and the model has a focused task at every stage. The result is much better than a single "Write a full blog post about Docker."

6. Tell it what NOT to do

Negative constraints are just as important as positive ones:

"Explain REST APIs to a beginner. Do not use any jargon. Do not mention
HTTP methods unless you define them first. Keep it under 200 words."

The model will actively avoid the things you listed, which is often more effective than hoping it stays on track.

7. Iterate and refine

Rarely does the first output nail it. Treat the conversation like a collaboration:

"Make it shorter." – the model will condense.
"Rewrite this in a more casual tone." – adjusts style.
"Add a concrete example." – fills in gaps.
"What did I miss?" – the model will often spot gaps.

Each iteration gives you a better result, and you never have to start from scratch.

Iteration example that works: first ask for the outline (“5 bullets, no prose”), approve or fix the bullets, then ask for prose from the approved outline – two short turns beat one giant “write the article” because each turn has a focused job and a checkable output. Keep turns short on local models especially: a 200-word instruction plus 2K of prior output fits any 8K window with room to generate, while a 5K-word mega-prompt plus chat history silently truncates the very constraints you care about. Short, sequential, checkable – that is the whole method.

Quick reference

Technique               When to use
─────────────────────────────────────────────────
Be specific             Always. Give format, length, audience.
Role prompt             Code reviews, domain-specific advice.
Examples                When output format is unusual.
Chain of thought        Math, logic, planning, analysis.
Break it down           Complex or multi-step requests.
Negative constraints    When the model goes off-track.
Iterate                 Always. The first answer is the rough draft.

The best prompters don't write perfect prompts – they write effective ones and then refine. Start with any of the patterns above, see what you get, and tweak from there. Save what works – your personal template file compounds faster than any single perfect prompt.

Prompting small local models (what changes)

Everything above works locally – with three adjustments. First, structure beats cleverness: a 7B–14B model follows explicit numbered steps and delimiters far better than implied intent, so write “Step 1… Step 2… Output format: …” instead of_hinting. Second, mind the context budget: pasting a 50-page doc into a 8K window silently truncates your instructions – keep prompts plus inputs inside your model's window (check VRAM/context math) or summarize-then-ask in two passes. Third, set temperature by task: 0–0.3 for code/facts, 0.7 for chat, 1+ only for brainstorming you will curate – small models wander faster at high temperature than flagships do.

When a local answer disappoints, debug in order: (1) shorten and structure the prompt, (2) lower temperature, (3) shrink context, (4) try one size up – in that order. Most “local models are dumb” reports are really “frontier prompt pasted into a 7B at temperature 1.2 with 100K context” – fix the prompt before blaming the weights.

Prompting agents (2026 reality check)

Frontier agents (Astra, Opus 5.5) take goals, not just questions – and the prompt becomes a spec: state the deliverable, the tools allowed, the constraints (files, budget, time), and the verification (“run the tests, paste failing output, fix until green”). Never grant an agent irreversible actions in the first prompt – read-only recon first, then scoped writes, then wider access as it earns trust. Our Astra and Opus 5.5 explainers show what autonomy costs per task – prompt it like spending money, because metered agents literally are.

Three copy-paste templates

EXPLAIN (any model):
"Explain [topic]. Assume I know [X] but not [Y]. Plain language, under [N] paragraphs,
one concrete example, no jargon without definition."

CODE REVIEW (local or cloud):
"You are a senior [language] developer. Review the function below for bugs, style, and
performance. List issues by severity, then show the fixed function. Temperature 0.2."

SUMMARIZE DOC (mind context):
"Summarize the pasted text in 5 bullets + one-sentence verdict. If the text exceeds your
context, say so first instead of guessing. Do not invent numbers not present."

Keep these in a notes file and adapt the bracketed parts – templates beat inspiration for daily work, and they transfer unchanged between ChatGPT, Claude, Ollama, and any local chat UI.

Failure patterns (stop doing these)

Contradictory instructions: “be brief but comprehensive” – pick one, or define brief (e.g. “under 150 words”).
Buried lead: the real question in paragraph four – models weight early instructions; put the task first, context after.
Unbounded scope: “write about Docker” – versus “5 topic ideas for beginners, one line each”. Scope is kindness.
Trust without verify: pasting model output into production/docs unreviewed – run code, open cited pages, recompute one row (see why LLMs hallucinate).

FAQ

Why is being specific in a prompt important?

LLMs generate from your words – specific format, audience, and length narrow the answer space from generic guess to relevant output.

What if the model ignores my instructions?

Break into steps, show an example format, or ask it to reason before answering. Then lower temperature for factual tasks.

Do these patterns work on small local models?

Yes – better, relatively: structure, examples, and low temperature help 7B–14B models most. Keep prompts inside the context window.

How do I prompt an agent without runaway bills?

Spec the deliverable, tools, constraints, and verification; start read-only, scope writes; draft cheap, escalate failing tasks to flagships.