promptdojo_

Builder briefs before prompts — step 1 of 1

Builder briefs before prompts

Prompting has a reputation problem: half the internet treats it like incantation — magic words that unlock the machine. It isn't. A prompt is a brief for a tool, the same builder brief you met in chapter zero, sharpened here for serious work.

The five knobs are still the foundation:

  1. Role — who should the model act as for this task?
  2. Task — what exact job should it do?
  3. Context — what does it need to know before answering?
  4. Format — what shape should the output take?
  5. Examples — what does good look like?

For agentic coding tools and AI project workspaces, add a sixth:

  1. Constraints — what must it use, avoid, preserve, test, or not touch?

Bad prompt:

make this better

Builder brief:

Role: product editor for beginner AI education
Task: rewrite this lesson intro so it is less scary for people new to AI
Context: the learner has never used an agentic coding tool seriously
Format: 3 short paragraphs and 4 bullet points
Examples: use "tool" not "helper"; code is "moving parts"
Constraints: do not mention Python in the first paragraph; do not change file paths

The brief isn't better because it's longer — length is not a virtue. It's better because it removes the guessing. Most failed AI sessions are missing one of the knobs: the model guesses, you dislike the guess, and suddenly the chat is a negotiation with a mistake you created upstream. (You'll lose that negotiation politely, one turn at a time.)

Builders don't argue with vague outputs. They improve the brief.