Outcome
What decision, artifact or transformation must exist when the work is done?
A research-grounded field guide to the transferable science—and model-specific craft—of prompting major generative AI systems.
Across providers, strong prompts answer seven questions. Persona is optional; evidence, constraints and an output contract usually matter more.
What decision, artifact or transformation must exist when the work is done?
What background, audience, definitions and source material change the answer?
Which sources may be used, how current must they be, and what must be cited?
Scope, exclusions, length, language, risk boundaries, tools and budget.
What may the model decide autonomously? When should it ask, verify or stop?
Required sections, schema, units, ordering, tone and acceptance criteria.
How will correctness, completeness, groundedness and usefulness be tested?
These are interaction tendencies and documented affordances, not immutable rankings. Product and API behavior can differ even when they use related models.
| Ecosystem | High-leverage move | Useful structure | Reasoning guidance | Long context / retrieval | Frequent mistake |
|---|---|---|---|---|---|
| OpenAI GPT | State the goal, constraints, evidence and “done” condition | Developer/system policy + concise task; Markdown/XML delimiters | For reasoning models, ask for outcome and verification—not hidden steps | Stable material first; changing task later; use tools for freshness | Over-engineering with repeated instructions and “think step by step” |
| Anthropic Claude | Make implicit expectations explicit; supply 3–5 representative examples | Semantic XML tags are especially natural | Ask for criteria and checks; configure thinking separately when available | Clearly fence documents; put queries after large evidence blocks | Negative-only rules, vague “be concise,” or examples that contradict prose |
| Google Gemini | Direct instruction + multimodal context + explicit output shape | Headings/tags; instructions after very large context | Current reasoning models prefer concise, direct prompts | Anchor: “Based on the preceding information…” | Placing the real question far before a huge document set |
| xAI Grok | Specify whether current web/X evidence or pure reasoning is required | Goal, search scope, evidence standard, format | Focus on result and source criteria | Distinguish model knowledge from live search and attached-file tools | Assuming “real-time” without enabling or requesting the relevant tool |
| Meta Llama | Use the exact chat template for the deployed checkpoint | Correct system/user/assistant tokens via the tokenizer | Benchmark per checkpoint and quantization | Context limits and behavior depend on host/configuration | Hand-writing prompt tokens or assuming all Llama hosts behave alike |
| Mistral | Put durable behavior in system; show the desired format | Clear system role + instruction + demonstrations | Use direct decomposition where measured useful | Choose model and endpoint for task; validate language adherence | Expecting persona text alone to enforce production guardrails |
| DeepSeek | Match prompt and API mode: thinking, tool use or JSON | Explicit system task; JSON example when using JSON mode | Do not mix hidden-reasoning transport with ordinary text handling | Preserve required reasoning/tool state across API turns | Requesting JSON without the API flag, the word “json,” example and token headroom |
| Microsoft Copilot | Goal + context + source + expectations | Reference the active file, meeting, mail or app artifact | Ask for assumptions and verification where decisions matter | Grounding depends on tenant permissions and selected Microsoft 365 context | Writing an abstract prompt while failing to name the available work source |
| Perplexity | Write a retrieval query, not merely a conversational request | Question + definitions + date/domain/source constraints | Ask for synthesis, disagreements and uncertainty | Use search parameters for filters; request primary evidence | Few-shot prose that pollutes search, or asking it to fabricate URLs in text |
Interpretation rule: a platform feature such as browsing, connectors or memory is not a property of the base model. Always identify the surface you are using.
Filter the profiles, then copy and adapt the worked prompt. The “archetypes” are mnemonic shorthand only.
The improvement does not come from ornamental wording. It comes from reducing ambiguity and making quality observable.
A prompt that “worked once” is an anecdote. A production prompt is a versioned hypothesis tested against representative cases.
Create a rubric and a small set of real, difficult, edge and adversarial inputs before polishing the prompt.
Run the simplest direct prompt first. Record model snapshot, parameters, tools, latency, cost and failures.
Add context, examples, structure or reasoning effort separately so you know what produced the change.
Where stakes justify it, hide model and prompt identity from human evaluators; use deterministic checks for schemas.
Test ambiguity, missing data, long context, prompt injection, multilingual input and distribution shift.
Pin model versions where possible. Re-run the evaluation set when a model, tool, retrieval layer or system prompt changes.
This local builder assembles a portable prompt. It is a starting hypothesis, not proof of quality.
Use a five-part rubric. Fluency without groundedness can make a weak answer look deceptively strong.
Claims, calculations and interpretations withstand checking.
Evidence supports the adjacent claim; uncertainty is visible.
All required criteria and edge cases are addressed.
Format, scope, policy and tool boundaries are followed.
The output enables the intended decision or action.
Provider documentation is authoritative for current product behavior; peer-reviewed and preprint research supports general techniques. Neither substitutes for evaluations on your own tasks.