Prompt writing that holds up when you reuse it

The gap between a prompt that works once and one you can rely on is not cleverness. It is specificity about the output and about what the model should do when the input is not what you expected.

Describe the output, not the vibe

“Write a professional summary” produces something different every time because professional is not a specification. “Write three sentences, under sixty words, no adjectives in the first sentence” produces something you can check.

If you cannot tell whether the output is correct by looking at it, the prompt is underspecified and no amount of rewording will fix that.

Give it the shape you want back

When output feeds into anything automated, state the format exactly and give an example. A model that has seen the shape you want returns it far more reliably than one asked to produce valid JSON in the abstract.

Say what to do when it cannot comply

• Missing information: say explicitly to leave a marked gap rather than invent one.
• Input in an unexpected format: say to return a short error string you can detect.
• Request outside scope: say to decline rather than attempt it.
• Without these, the model will guess, and a plausible guess is harder to catch than an obvious failure.

Separate instructions from content

Put the content being processed inside a clear delimiter and refer to it by name. This keeps the model from treating text inside a document as instructions, which matters a great deal once the content comes from outside your organisation.

Version them

Treat prompts you depend on as code: store them somewhere with history, and when you change one, note what you were trying to fix. A prompt library nobody can reconstruct the reasoning for becomes unmaintainable at about the thirty-prompt mark.