PATH COMPLETION0 / 45 STEPS (0%)
BACK TO LEARNING PATHTRACK 02: Prompting and Skills
Step 5 of 7 in this track · 8 min

Prompt patterns that work

These are shapes rather than magic words. Each solves a specific failure.

Plan first, then act

> Before changing anything, list the files you will edit and what you will change in each. Wait for my confirmation.

Use when the task touches more than two or three files. The plan is cheap to read and cheap to correct. A wrong plan costs you thirty seconds; a wrong implementation costs you a review.

This also surfaces misunderstandings while they are still free to fix.

Constrain the output shape

> Reply with only the corrected function. No explanation, no surrounding code.

Use when you are going to paste the result somewhere. Without this you get a preamble, the code, and a summary, and you spend your time deleting two thirds of it.

Give it an out

> If the existing tests do not make the expected behaviour clear, stop and ask rather than guessing.

Use whenever a wrong guess is expensive. Models default to producing an answer. Explicit permission to stop is one of the few reliable ways to get a question instead of a confident invention.

Point at the reference

> Follow the pattern in src/services/billing.ts. Match its error handling and its test layout.

Use for anything where consistency matters more than cleverness. This is the single highest value sentence in most prompts, because it replaces paragraphs of description with something the model can read directly.

Ask for the failure mode

> After the change, tell me what could break that the tests would not catch.

Use before merging anything you did not write yourself. The answer is often more useful than the change, because it tells you where to look.

Two things that do not help

Politeness and threats. Please, urgent, and "this is critical for my job" do not measurably improve output on current models. They just add tokens.

Repeating yourself. Saying the same instruction three ways makes the prompt longer without making it clearer. If it was ignored once, rewrite it rather than repeating it.

Combining them

For a real task you would often use several:

> Follow the pattern in src/services/billing.ts. Before changing anything, > list the files you will edit. If the expected behaviour is unclear from the > tests, stop and ask.

Each sentence is doing one job. That is the point.

Save the ones that work

When a prompt works twice, it belongs in a file, not in your head. That is what the templates section is for, and it is the moment a prompt is ready to become a skill.