Prompt Engineering Taxonomy

Prompt Engineering Taxonomy

Prompt engineering is the craft of structuring input so a model reliably produces what you want. The techniques below are roughly the order you should reach for them: get the roles and instructions right first, add examples and reasoning if needed, then constrain the output and defend the boundary.

System vs user prompts

Most chat models separate system instructions (role, rules, persona, output contract — set by you, the developer) from user messages (the end-user’s input). Keep durable behavior in the system prompt and treat the user turn as data.

This separation is also your first security boundary: the model is trained to weight system instructions heavily, so put “never reveal X / always answer only from provided context” there. It is a strong prior, not a guarantee — see injection defense below.

Few-shot prompting

Zero-shot (just ask) is the baseline. Few-shot adds a handful of input→output examples in the prompt so the model infers the pattern and format — introduced at scale in the GPT-3 paper, “Language Models are Few-Shot Learners”.

• Use 2–5 diverse, correct examples that cover edge cases and the exact output shape.
• Examples teach format and style powerfully — often more reliably than describing them in prose.

Chain-of-thought

Chain-of-thought (CoT) prompting asks the model to reason step by step before answering, which improves accuracy on multi-step reasoning (math, logic, planning). Trigger it with explicit instruction (“think step by step, then give the answer”) or by showing worked reasoning in few-shot examples.

Tip

When you need both the reasoning and a clean machine-readable answer, have the model reason first in a designated section, then emit the final answer in a separate, clearly delimited block you can parse — don’t try to parse JSON out of the middle of free-form reasoning.

Structured output

For anything programmatic, make the model emit parseable output instead of prose:

• JSON mode / schema — most providers can constrain responses to valid JSON, ending “almost-JSON” parse failures. Note basic JSON mode guarantees syntactic validity, not conformance to your schema — supply a JSON Schema where supported, and still validate the result against it.
• Tool/function calling — the most reliable structured output on many models: define a function signature and the model returns validated arguments (see Agentic AI Patterns).
• Grammar-constrained decoding — local stacks (e.g. llama.cpp GBNF grammars) can force output to match a formal grammar token-by-token, guaranteeing well-formedness.

Always still validate what comes back; constraints reduce but don’t fully remove the need to handle malformed or out-of-spec output.

Prompt injection defense

Prompt injection is when untrusted content (a user message, a retrieved document, a tool result) contains instructions that hijack the model — the LLM-era analogue of injection attacks. It is the top entry in the OWASP Top 10 for LLM Applications, and there is no complete fix — only layered mitigation:

• Separate instructions from data. Never concatenate untrusted text into the instruction position; keep system rules in the system prompt and clearly delimit untrusted content as data the model should treat skeptically.
• Least privilege on tools. Assume the model can be tricked into calling a tool; gate destructive/sensitive actions behind validation and human confirmation.
• Don’t trust model output as a control signal for security decisions; validate server-side.
• Filter and constrain both inputs and outputs, and log for detection.

Treat it as an adversarial threat, not just a prompting nuance — model it the way you’d model any untrusted-input attack surface.

Related

• RAG Patterns — presenting retrieved context to the model
• Agentic AI Patterns — prompts that drive tool use and planning
• AI Prompting Guide — community prompting practices
• Threats Catalog — prompt injection as an adversarial technique