Prompts as specifications

A language model does not look up what you meant. It predicts the next token from everything in the context. If the job is not written into that context, the model has to guess. Writing a prompt means writing the job down so that a reader with no memory of your product could do it.

The big idea

A solid prompt answers the same six questions a good engineering brief answers:

1. Role and audience: who is answering, and who reads the answer?
2. Goal: what decision or artifact do you need?
3. Inputs: which documents, fields or earlier turns count as evidence?
4. Constraints: length, tone, and what must not be invented.
5. Output contract: the format, the required fields and what to do when evidence is missing.
6. Success criteria: how a reviewer would judge a good answer at a glance.

Think of a good ticket. Nobody starts work on "fix billing." They start on a ticket with an owner, a symptom and a definition of done. The analogy breaks at one point: a model cannot stop and ask a follow-up question unless you build that loop into the product.

Walking through it

Start with a vague prompt:

Summarize this ticket.

The model picks its own length, its own focus and its own format. Two runs will differ. Now make it a spec:

Summarize this billing ticket in three bullets for an on-call engineer:
impact, likely cause and current status. Quote the invoice ID if present.
If the ticket is not about billing, say so in one sentence and stop.

Each part removes a guess. The three bullets fix the shape. The named fields fix the content. The last sentence gives the model a safe exit for tickets that do not fit.

Prefer constraints with reasons. "Keep it under 50 words because this becomes a push notification" generalizes better than "be brief." When the model meets an edge case, the reason tells it what to optimize.

Common mistakes

• Vague goals. "Help with the refund" does not say what decision to make.
• Missing exits. If the input is off-topic or missing data, say what to return. Otherwise the model invents an answer.
• Unreasoned rules. A bare rule gets applied rigidly. Add the reason so edge cases get the right treatment.
• Grading prose, not fields. A confident paragraph can hide a wrong number. Test the fields.

Check yourself

• Why is "keep it under 50 words because this becomes a push notification" better than "be brief"? The reason lets the model apply the same judgment to cases you did not list.
• The bot says it refunded $86 when only a $24 item was damaged. Is the prose the problem? No. The amount is the product, so check it with an automated test.

Key takeaways

• A prompt is a spec with six parts: role, goal, inputs, constraints, output contract and success criteria.
• Give every rule a reason.
• Give the model a legal way to say "not applicable" or "not enough evidence."
• Test the fields and numbers, not just how the answer reads.

Further learning

Next, see how to lay out the parts of a prompt in prompt structure.