Prompt Engineering Checklist: 15 Checks Before You Ship a Prompt

Prompt Engineering Checklist: 15 Checks Before You Ship a Prompt

Three tries, and the output finally looks right. That feels like success. Then a colleague runs the same prompt on a slightly different input and gets something unusable: wrong length, a missing field, a tone that belongs to a different product. Prompts rarely fail loudly. They fail in the gap between what you meant and what you actually wrote down.

The checklist below follows the order in which problems usually appear: clarity, context, examples, edge cases, safety, evaluation. Fifteen checks. Each one takes a minute. Each one is expensive to skip.

A prompt is not a magic phrase. It is a brief, a specification, and a set of boundaries. When it works, it works because the model had enough information to make the right choices. When it fails, it usually fails because the prompt left a decision to chance.

Clarity: One Instruction, One Meaning

Ambiguity is the most common defect, and it hides in ordinary words. "Summarise this appropriately" tells a model almost nothing. "Summarise this in three bullets, each under twenty words, for a support agent who has not read the ticket" tells it everything it needs.

Before anything else, read your prompt as if you knew nothing about the project. Every place you pause and think "well, obviously" is a place the output can wander.

• 1. The task is one sentence with one main verb. If you need "and also", you may be looking at two prompts wearing a trench coat. Split them, or at least put them in a clear order.
• 2. The audience and tone are named. "Explain to a new hire" changes word choice more than any adjective you could add.
• 3. Success criteria are written down. If you cannot list what a good output contains, neither can the system. Write those criteria for yourself first; they double as your evaluation rubric later.

If you cannot describe a good output in plain language, no amount of prompt polish will produce one.

Clarity in practice

Compare "Write a follow-up email" with "Write a three-sentence follow-up email to a customer whose shipment was delayed. Apologise once, give the new delivery date, and offer a tracking link. Tone: calm, accountable, no marketing language." The second prompt is not longer for the sake of length. Every extra detail removes a possible wrong turn.

Context and Constraints: What Cannot Be Guessed

Every prompt has a context gap. The missing information lives in your head, in a style guide, in a message thread, and none of it arrives unless you write it out. The test is simple: would a capable freelancer with no access to your team produce the right thing from this brief? If not, add what is missing.

• 4. Background is explicit. What the product does, who reads the output, what happens to it downstream. Two sentences of context often save a page of corrections.
• 5. Source material is delimited and labelled. Wrap pasted text in clear markers, say what each block is, and state which parts to use and which to ignore.
• 6. Constraints are numbers, not feelings. "Keep it short" becomes "Under 120 words and no more than three paragraphs." "Be thorough" becomes "Include four sections and at least two examples per section." If length varies by input, state a minimum and a maximum.

Example: instead of saying "Use the customer data below," write "The first block is the customer's original message. The second block is the order record. Use the order record for dates and status, but do not quote it directly in the reply." That single instruction prevents the model from mixing up source material.

Examples and Formatting: Show the Shape of the Answer

Models are pattern matchers. A description of a good answer is useful; an example of a good answer is better. If the output must follow a structure, show the structure in the prompt. Do not make the model guess what "professional" or "friendly" or "clear" looks like in your product.

• 7. At least one positive example is included. Show a model the shape of a good answer. If the output should be JSON, include valid JSON, not a description of JSON.
• 8. At least one negative example or explicit "do not" list is included. "Do not include pricing, legal advice, or competitor names." Negative examples are especially useful for tone and safety.
• 9. Output format is specified. Say whether to use Markdown, plain text, bullet points, numbered lists, or headings. If a downstream parser consumes the output, say "Return only JSON. No prose before or after."

Example: instead of "Make it sound professional," show two versions. "Too casual: Hey, your package is late, sorry about that. Preferred: I'm sorry your shipment has been delayed. Here is the updated delivery date and tracking link." Models learn boundaries faster from contrast than from adjectives.

Edge Cases and Failure Modes: Design for the Bad Input

Most prompts are written for the happy path. Production is not the happy path. Inputs arrive empty, duplicated, in the wrong language, twice as long as expected, or with instructions buried inside them. A prompt that only works on clean data is not finished.

• 10. Missing or empty fields are handled. Say what to do when a required input is absent: ask a clarifying question, return a structured error, or omit a section. Example: "If the customer message contains no order number, output 'missing_order_number' and do not guess."
• 11. Conflicting instructions are resolved. If two rules collide, state which one wins. "If the source text conflicts with the style guide, follow the style guide and note the conflict in a final 'notes' field."
• 12. Long or malformed inputs have a plan. Define truncation, summarisation, or rejection. "If the input exceeds 2,000 words, summarise it first, then answer using only the summary."

This is where prompts earn trust. A prompt that handles blank input, duplicate records, mixed languages, or an angry customer tone is a prompt that survives production. A prompt that ignores those cases is a demo.

Safety, Privacy, and Compliance: Non-Negotiable Checks

Safety is not a separate project you bolt on later. It is part of the brief. If the model should never reveal certain data, invent certain claims, or give certain kinds of advice, the prompt must say so directly.

• 13. Sensitive data rules are explicit. Tell the model what not to echo, store, or infer. "Do not include names, email addresses, phone numbers, or account IDs in the output. Replace them with placeholders."
• 14. Refusal and escalation paths are defined. Say when to stop, what to say, and where to route the user. Example: "If the request asks for a medical diagnosis, respond with: 'I can't provide a diagnosis. Please contact a licensed clinician.' Do not add other advice."

These checks protect users, but they also protect the product. A model that improvises in a sensitive area creates risk that no amount of good tone can offset.

Evaluation: Prove It Works Before You Ship

Testing is the difference between "it worked once" and "it works." You do not need a massive evaluation suite to start. You need a small set of inputs that represent the real world, and a clear idea of what a correct output looks like.

• 15. The prompt is tested against a small evaluation set. Use five to ten inputs: one happy path, one edge case, one adversarial input, one empty or missing field, and one unusually long input. Compare the outputs against your success criteria, not against your mood.

If an output fails, decide whether the prompt was unclear, the context was missing, or the model simply cannot do the task reliably. Those are different problems. Do not fix a missing example by adding more adjectives.

A prompt that has never failed a test has probably never been tested properly.

A five-minute pre-ship test

1. Run the prompt on the simplest possible input.
2. Run it on the ugliest input you can find.
3. Run it twice and compare the outputs for consistency.
4. Ask a colleague to read the prompt and predict the output before running it.
5. Check the result against your success criteria, then check it against the edge cases.

After You Ship: Version, Monitor, Improve

Shipping is not the finish line. Inputs change, model versions change, and product requirements change. A prompt that was perfect last quarter can quietly become a liability. Treat prompts like code, because that is what they are.

• Version every prompt. Keep a changelog with the date, the change, and the reason. When output quality drops, you need to know what moved.
• Log failures. When an output is wrong, save the input and the output. A folder of real failures is more valuable than another round of guessing.
• Re-run evaluation after changes. A small eval set takes minutes to run and catches most regressions. If you changed the prompt, the old test results are no longer valid.
• Assign an owner. Prompts without owners drift. Someone should be responsible for reviewing failures and deciding when to update the prompt, the examples, or the surrounding system.

The fifteen checks above are not bureaucracy. They are a way to make the invisible visible before a user sees the mistake. Most prompts fail in the gap between intent and instruction. These checks close that gap, one minute at a time.

Photo: RDNE Stock project / Pexels