> Canonical: https://drkishanrees.com/learn/prompting-primer/ # How do I write prompts that land first time? *The first brief gets you going; this is the craft around it. Two fields most people skip, a way to size a task before you write a word, and knowing when a quick ask is secretly a big one. None of it needs clever wording.* Prompts & Workflows. 4 min read. First published 7 August 2026 They range enormously, from dropping a line of new text into a page that already exists, to building a whole new component from scratch. Naming which one you are really asking for, before you write the brief, is what stops a small request quietly turning into an expensive rebuild. The size is the first thing to get right, not the wording. You have met the six-field brief already: the goal, what to reuse, the scope, what to preserve, how to verify, and what to hand back. That is enough to start, and it is most of the battle. This session is the craft that sits around it, the handful of habits that turn a decent brief into one that lands first time. None of it is clever wording. All of it is knowing what to say, and how big the job is, before you say it. ## Which parts of a brief matter most? Two fields do more work than the rest, and they are the two people skip. The first is **what to reuse**. Point the model at the thing that already works: "reuse the photo layout that is already on this page" beats "add a photo", because it says reuse, not invent. A model told to invent will invent, and you will spend the next hour explaining why the new thing does not match everything around it. A model pointed at a pattern that is already proven copies what works. The second is **what to preserve**. Say plainly what this task must not touch: the pages that already work, the wording you have approved, the thing that is easy to break by accident. If your project keeps a rules file, the rules that matter for this task get said again in the prompt anyway, because a rule repeated at the point of use is a rule that cannot be quietly lost. Get those two right and the model builds on what exists and leaves alone what it should. Most poor first versions come from skipping them. ## How do I size a task before I write the brief? Before you fill in a single field, name the bucket. Every change is one of four, and they are not the same size of job: 1. **New content in a template that already exists.** The cheapest: you are pouring words or an image into a shape that is already built. 2. **A new variant of something that exists.** A little dearer: the same component, a new flavour of it. 3. **Reusing an existing thing in a new place.** Dearer again: moving a proven piece somewhere it has not been before. 4. **Building a new component from scratch.** The dearest, and the one to be sure about before you start. Naming the bucket out loud catches the most expensive mistake there is: asking for bucket one and accidentally commissioning bucket four. Some tasks are secretly bigger than they look, a small wording change that quietly needs a new component underneath it. When one is, say so before you build, not after. ## Do I always need the full six-field brief? No, and knowing when not to is part of the skill. Run two weights of prompt. The **full brief** is for substantial work: the six fields, proposed and agreed before anything is built. The **follow-up** is for everything after that in the same piece of work, and it can be much lighter, three lines: **Orientation** (where we are, and what to reuse), **Task** (the one change), **Outcome** (what a good result looks like). A follow-up can be short because it inherits the scope, the preserve and the verify from the brief you already set. You frame the work once, then move fast inside the frame. One valve governs the two. When a quick follow-up secretly grows, when it widens the scope, changes a design you had agreed, adds something new to depend on, is hard to undo, or touches anything already live, it is not a follow-up any more. It goes back to the full brief and gets agreed before anyone builds. The number of files is not the trigger; the risk is. A safe, mechanical change can touch fifty files and stay a follow-up. One sentence that changes how the thing is built is a full brief, however small it looks. ## So, how do I write prompts that land first time? Say what you want plainly, and spend your care on the two things the blank box will not prompt you for: point at what to reuse, and name what not to disturb. Before you write a word, name how big the job really is, so a small ask does not turn into a rebuild. Use the full brief when the work is substantial and a three-line follow-up when it is not, and treat any follow-up that grows teeth as a full brief again. The wording was never the hard part. Knowing what to say, and how big the job is, is the craft, and it is one you can start practising on your very first prompt. ## Questions and answers ### What matters most in a prompt? Structure and clarity, not clever wording. Beyond naming the change and how you will check it, the two things most people skip are pointing at the source of truth (reuse this existing thing, do not invent) and restating the hard rules this task must not break. Those two do most of the work. ### How do I size a task before I prompt it? Name the bucket first, cheapest to dearest: new content in an existing template; a new variant of an existing component; reuse of an existing component in a new place; or extracting repeated markup into a new component. Naming the size before you build stops a small ask quietly turning into an expensive rebuild. ### Do I always need a full six-field brief? No. Use the full brief for substantial work, agreed before building. For quick tweaks a three-line follow-up is enough (Orientation, Task, Outcome), because it inherits the frame you already set. The one rule: if a quick ask secretly expands scope, changes a design, or is hard to undo, it is not quick any more, and it goes back to the full brief. ## Related resources - Vibe coding with veracity: the discipline behind the brief: https://drkishanrees.com/ideas/vibe-coding-with-veracity/ - How do I hand a prompt to another AI?: https://drkishanrees.com/learn/hand-a-prompt-to-another-ai/ Cite as: Rees, Kishan. 'How do I write prompts that land first time?'. drkishanrees.com, first published 7 August 2026. https://drkishanrees.com/learn/prompting-primer/