How to Write Better AI Prompts: A Beginner's Checklist
Before you send that prompt, run it through five questions. Most disappointing AI output traces back to one of these being skipped, not to the model being incapable.
If an AI tool keeps giving you vague, wrong, or unusable answers, the fix is almost never "try a different AI" — it's almost always one of five things missing from the prompt. Run any prompt through this checklist before sending it.
The five-question checklist
- Have I given enough context? The model only knows what's in front of it — your codebase's conventions, your business rules, your actual constraints — unless you state them. "Write a login function" and "write a login function for our ASP.NET Core API using our existing IUserRepository, matching the error-handling pattern in AuthController.cs" produce very different quality output.
- Is the task a single, unambiguous thing? "Improve this code" could mean performance, readability, security, or all three — and the model will guess, possibly wrong. "Reduce this function's time complexity from O(n²) to O(n log n) without changing its return value" can't be misread.
- Have I stated the constraints? What must be true of the output — language/framework, style, things to avoid, security requirements. This is the single most commonly skipped component, and skipping it is why generated code often technically answers the question while missing what actually mattered.
- Do I need to show an example? If the output format or style isn't obvious from the task description alone, one worked example (few-shot) fixes format drift far more reliably than describing the format in words.
- Have I specified the output format? If you need the response to be parseable, or to follow an exact shape, say so explicitly — "return only the JSON, no explanation" or "one function, no surrounding prose." Without this, output format tends to drift between attempts.
Take a prompt that gave you a disappointing result. Read it back and ask: which of the five questions above would I have answered "no" to? That gap is almost always where the fix is — not in the model's underlying capability.
Before / after
"Write a function to validate an email." Produces a plausible regex with no indication of what happens on invalid input, which language/runtime, or how strict the validation should be.
Context: TypeScript/Node.js backend, server-side validation after client-side checks already happened.
Task: Write isValidEmail(input: string): boolean.
Constraints: Must not throw on any input. Pragmatic check (not full RFC 5322) — reject only clearly malformed input. Pure function, no dependencies.
Output format: A single TypeScript function, no surrounding explanation.Common mistakes even after using the checklist
| Mistake | Fix |
|---|---|
| Describing context instead of pasting it | Paste the actual code/error/data — descriptions lose the details that matter, especially for debugging |
| Constraints that are too soft ("try to keep it simple") | State constraints as hard requirements the model must satisfy, not preferences it can weigh against other goals |
| One giant prompt for a multi-step task | Break it into an explicit plan first, then execute one step per turn |
| Accepting the first answer without verification | Compile it, test it, or ask for a self-review pass before trusting generated code |
This checklist is the compressed version of the five-part prompt anatomy the Foundations program teaches in full, with worked examples across coding, testing, documentation, and everyday non-technical tasks — the checklist is what to run through fast once the underlying model of *why* each part matters has actually stuck.