Prompt Patterns Worth Memorising
Ten reusable shapes — from 'explain before you change' to 'give me three options' — each one copyable.
Worth reading first: Writing Prompts That Work
Once you have written a few hundred prompts, you notice you are writing the same ten shapes over and over. Here they are, ready to copy. Learn the reasoning behind each and you will stop needing the list.
The ten patterns
1. Explain before you change
Use when: You are about to touch code you do not fully understand.
Before changing anything, explain what this file does and howit is used elsewhere in the project. Then wait — do not edit yet.Why it works: Splits comprehension from modification. If the explanation is wrong, you have caught it before any code moved.
2. Give me three options
Use when: There is more than one reasonable approach and you do not know the tradeoffs.
Give me three ways to solve this, with the tradeoff for each.Do not write code yet. Recommend one and say why.Why it works: The first idea a model produces is the most common one, not the best one. Asking for three surfaces the alternatives it would otherwise skip.
3. Constrain the blast radius
Use when: Always, on any codebase you care about.
Change only src/components/Cart.tsx. Do not add dependencies,do not modify tests, and do not reformat code you are nototherwise changing.Why it works: Unbounded requests produce unbounded diffs. Stating the boundary makes an over-reaching change obvious instead of invisible.
4. Show me the diff first
Use when: The change spans multiple files.
Describe exactly what you plan to change, file by file,before making any edits. I will confirm.Why it works: Reviewing a plan takes thirty seconds. Reviewing eleven files of applied changes takes twenty minutes.
5. Reproduce, then fix
Use when: Fixing a bug.
First write a failing test that reproduces this bug.Show me the test failing. Only then fix it.Why it works: Proves the bug is understood before it is patched, and leaves behind a test that stops it returning.
6. Match what exists
Use when: Adding to an established codebase.
Find an existing component that does something similar andfollow its conventions — naming, file layout, error handling,styling approach. Tell me which one you used as the model.Why it works: Prevents the AI from importing patterns from its training data that clash with everything around them.
7. Name the failure modes
Use when: The code handles user input, money, or anything external.
List the ways this could fail — empty input, network error,concurrent access, malformed data — then handle the ones thatare realistic here.Why it works: Happy-path code is the default output. Edge cases only appear when you ask for them by name.
8. Rubber duck it back
Use when: You are not sure the AI understood the request.
Restate what I am asking for in your own words, includinganything you think is ambiguous. Do not start yet.Why it works: A misunderstanding costs one message to catch here, or an hour to catch after the code is written.
9. Set the stopping condition
Use when: Handing off a longer task.
Work until npm run check passes with no errors. If you getstuck twice on the same problem, stop and tell me ratherthan trying another approach.Why it works: Gives an objective finish line and prevents the flailing loop where each 'fix' creates the next problem.
10. Ask what it is unsure about
Use when: Right before you accept anything substantial.
What in this change are you least confident about,and what should I check by hand?Why it works: Models are poorly calibrated but not uncalibrated. This reliably surfaces the weakest part of the diff.
The thread running through them
Read the ten together and one idea repeats: separate thinking from doing. Explain before changing. Plan before editing. Reproduce before fixing. Restate before starting.
That is not a trick specific to language models. It is how you would brief a capable colleague who is fast, widely read, and has never seen your codebase — which is very close to what you are actually working with.
Building your own
When you catch yourself typing the same clarification for the third time, that is a pattern forming. Two options: keep it in a notes file you paste from, or — better — put it in a rules file so it applies automatically to every prompt without you typing anything. That is the next part of the course.
Key takeaways
- Separate thinking from doing. Almost every good pattern is some version of that.
- Ask for options before implementations when the approach is open.
- State the boundary explicitly, or the diff will decide its own size.
- “What are you least confident about?” is the cheapest review you can run.
- A clarification you have typed three times belongs in a rules file, not in your fingers.