The sessions / Prompts & Workflows

How do I write a good first prompt?

A good prompt is not a secret form of words, it is a clear brief: what you want, what to reuse, what not to touch, and how you will check it. Six short fields, and none of them needs a clever phrase.

3 min read

Read as: HTML Markdown

A quick check, before we start

A longer, more detailed prompt is always a better prompt.

Reveal the answer

False.

What makes a prompt work is clarity, not length. A short, clear brief that says what you want and how you will check it beats a long, vague one every time. The craft is habits, not word count.

The blank box is the scary part. People imagine there is a secret form of words that makes the model behave, and that they simply do not know it. There is not. A good prompt is not an incantation, it is a clear brief. The set-up this site teaches puts it plainly: none of it needs the tools, all of it needs the habits.

You can also ask a model, in a separate window, to help you craft a prompt for an idea that is still unstructured. Read what it gives back, learn how your model likes prompts to be written, and settle on your own process from there. As I have gone further and the project has grown, I have found it useful to have a second model, Codex, review a start-up prompt I am about to give Claude, on the occasions when I notice Claude drifting off topic or losing the thread. The move is the same each time: describe the problem, ask for suggestions, review the proposed prompt, give it to the model, and read the output.

What makes a prompt good?

Clarity, and a way to check the result. A good first prompt tells the model the one thing you want changed, where to look for how it should be done, and how you will know it worked. That is a brief, and a brief you can write in plain language on your first day. The cleverness of the phrasing barely matters; being clear and being specific is almost the whole of it.

What goes in the brief?

Six short fields, the skeleton the primer hands you:

  • Goal: the one behaviour to change.
  • Reuse this: the existing thing to copy from, so the model builds on what works instead of inventing.
  • Scope: only touch these files; restyle nothing else.
  • Preserve: what this task must not disturb.
  • Verify: how the result will be checked, proportional to the change.
  • Output: which files changed and why, in a short list.

You will not fill all six perfectly on day one, and you do not need to. Even a rough version of this beats “make me a website”, because it tells the model what done looks like.

This site runs on that six-field brief as its main structure. I have even built a “prompt warehouse”, a project folder in Claude where I drop rough ideas and ask it to turn each one into this format. For quick tweaks and amends I use a shorter version, OTO:

  • Orientation: where on the site the change should be made.
  • Task: what I want the model to do, such as change some text or replace an image.
  • Outcome: what the finished result should look like.

Where can I see it on this site?

The prompting primer is the whole of it: the six-field skeleton above, and the four buckets it uses to size a task before the brief is even written. This very site was built with that set-up, so you can check the primer’s claims against the pages around it.

So, how do I write a good first prompt?

Write a brief, not a spell. Name the one thing to change, point at what to reuse, say what to leave alone, and say how you will check it. Keep it clear, keep it specific, and keep it short. The words do not need to be clever. The thinking behind them does, and that is a habit you can start on day one.

Something sparked your interest? Let's talk!