Builder briefs before prompts
An AI coding tool writes and edits with you. Cursor is one brand. Claude Code is another. This chapter is how you brief those tools so they stop guessing.
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:
- Role — who should the model act as for this task?
- Task — what exact job should it do?
- Context — what does it need to know before answering?
- Format — what shape should the output take?
- Examples — what does good look like?
For agentic coding tools and AI project workspaces, add a sixth:
- 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.