Field Notes
The first bad prompt usually sounds reasonable.
It is just missing the job.
That is the part people keep skipping.
They open an AI tool and type something like:
"Write the follow-up email."
Or:
"Analyze this report."
Or:
"Make this better."
Then the model gives them something polished that still misses the point. The tone is off. The context is thin. The source is wrong. The answer skips the real risk.
Then people say, "AI is inconsistent."
Often, the prompt never told the model what job it was being hired to do.
That is how I think about prompt engineering now.
Prompt engineering is job design.
It is the act of making the work visible before the model starts producing.
The System Around the Model was about the loop around the model. Prompt engineering is the first layer. Before context, tools, memory, and loops, there is a basic question:
What exactly are you asking this intelligence to do?
That sounds obvious until you watch how people actually use AI.
They give it a task name instead of a job.
"Write copy."
"Summarize this."
"Make a plan."
"Create a strategy."
Those are labels. They are not instructions.
A real job has a purpose, audience, quality bar, source material, constraints, edge cases, and stopping point.
If you hired a person and said, "Handle sales follow-up," you would expect questions.
Who is the prospect?
What did they already say?
What are we offering?
What should we avoid promising?
What tone fits the relationship?
What should happen if they ask about price?
What needs approval before it goes out?
We often give AI less direction than we would give a new assistant on their first day.
The model is not reading your mind. It is completing the job from the clues you gave it. If the clues are vague, the answer may sound confident while the work is built on fog.
That is why agents are closer to employees than people think.
In What Is an Agent, Actually?, I described an agent as more than a chatbot. It has a job, context, tools, and rules for what it can do.
You do not hire an assistant and say, "Good luck. Figure out our policies, tone, tools, approval rules, and customer expectations from scratch."
You train them.
You explain the job, show examples, give them company policies, and tell them when to ask for approval.
AI skills work the same way.
A lot of people know the word "skills" from Claude. Plain English: a skill is a well-structured prompt or job description codified for a model or agent.
When you find the instruction that gets the output right, snapshot it. That snapshot becomes the skill.
It is an SOP, a Standard Operating Procedure, for the agent.
That is the bridge from The New Software Stack to here. The new software stack is reusable work. A prompt becomes a skill. A skill becomes part of a workflow.
It also ties back to Don't Marry Claude. The platform matters, but the durable asset is the work you codify: instruction, source rules, examples, stop sign, review gate.
That is why prompt engineering matters.
The point is not to find magic words.
The point is to transfer judgment into the instruction.
What do you know that the model does not know yet?
What would a good employee ask before doing this work? What failure would make the output dangerous? What does done mean? Where should the system stop and bring the work back to you?
Playbook
Here is the practical version.
Before you ask AI to do important work, write the prompt like a job description.
Use this structure.
1. Name the job
Start with the real job, not the generic task.
Weak:
"Write a follow-up email."
Stronger:
"Draft a follow-up email to a paid Bootcamp student after the final session. The goal is to recap what they learned, give them the next steps, and make sure nothing is sent externally until I review it."
That version gives the model a role in a workflow. It knows the audience, the timing, the purpose, and the stop sign.
2. Define the outcome
Tell the model what should come back: a draft email, ranked list, table, decision memo, checklist, or revised prompt.
Output format shapes how the model thinks. For decisions, ask for a memo. For options, ask for tradeoffs. For a draft, ask for the assumptions underneath it.
3. Give the source rules
Many mistakes begin here.
Tell the model what it should use, what it should ignore, and what source wins when two sources conflict.
For a customer reply, source rules might be:
- use the latest email thread,
- check prior support history,
- use the current refund policy,
- do not invent dates, prices, promises, or technical fixes,
- ask for review if the answer depends on missing information.
Without source rules, the model may fill the gap with something reasonable. Reasonable is not the same as true.
4. Name the risks
Every real workflow has danger zones: billing, legal language, customer expectations, pricing, refunds, personal information, brand voice, and public claims.
If those risks matter, put them in the prompt.
"Watch for anything that could overpromise, misstate pricing, expose private information, or imply that a message has been sent."
That one sentence changes the work. It tells the model where to slow down.
5. Add examples
Models learn a lot from examples.
Give one good example and one bad example when the work has taste, style, or judgment baked into it.
"Good: clear, warm, specific, no fake certainty."
"Bad: generic apology, steps they already tried, promises we cannot verify."
Examples are how you stop the model from copying the average internet version of the task.
6. Define done
Do not leave "finished" to vibes.
Say what a completed answer includes.
For a report, that might mean summary, source notes, risks, recommendation, open questions, and next action.
For an email, that might mean subject line, body, links or placeholders, assumptions, and items needing human review.
The model should know when the job is complete. So should you.
7. Snapshot the job into a skill
When the prompt starts working, stop treating it like a one-off.
Save it. Name it.
Give it a clear trigger: "Use this for post-call client follow-up" or "Use this before any pricing recommendation leaves draft state."
Then include the operating rules:
- what job the agent is doing,
- what sources it should check,
- what examples it should follow,
- what risks it should watch,
- where it must stop,
- what receipt it should bring back.
That is a skill: a reusable job description for the model.
This is how you get faster. You engineer the complete prompt once, improve it through real work, then turn the working version into a skill the agent can reuse.
8. Set the stop sign
This is the part operators need to take seriously.
Tell the model what it is allowed to do and where it must stop.
"Draft only. Do not send."
"Analyze only. Do not change data."
"Recommend only. Do not update pricing."
"Run up to the review gate, then return a receipt."
The stop sign is what turns a prompt from a request into a controlled workflow.
You can give AI more reach later.
Earn it first.
Orientation
That is prompt engineering in plain English.
Give the AI a real job description.
The better the job description, the less the model has to guess.
The less it has to guess, the easier it is to review, repeat, and improve the work.
The ladder is simple: prompt, skill, workflow.
The prompt defines the job. The skill preserves the job once it works. The workflow adds the tools, context, approvals, and receipts around it.
This is why the next layer matters too.
Sometimes you do not know the job well enough to write the prompt yet.
You have a rough idea, a messy workflow, a goal, a few files, and not enough clarity to describe the task cleanly.
That is where meta-prompting comes in.
The next post is about the prompt before the prompt: using AI to interview you, pull out missing context, find the risks, and turn rough intent into an agent-ready instruction.
For now, pick one prompt you use often.
Rewrite it as a job description.
What is the task?
Who is the audience?
What sources should it trust?
What can go wrong?
What does done mean?
Where should it stop?
Comment below with the workflow you would rewrite first.
I read every one.
— Brian