Building complex prompts from scratch

A production prompt is not a sentence. It is a small system: an input specification, a task definition, a set of constraints, an output format, and guardrails for the cases where the input does not match expectations. Building one from scratch is a skill you develop by doing it wrong several times, then doing it right.

This lesson gives you the sequence that produces a working prompt on the first try more often than not.

Step 1: Write the task in one sentence

Before you write any prompt, write one sentence that describes exactly what the prompt should do. Not what it should produce — what it should do.

"This prompt takes a customer complaint, assigns it a severity level (low/medium/high/critical), and drafts a response that addresses the complaint and explains the next step."

If you cannot write that sentence, you do not yet understand the task well enough to prompt for it.

Step 2: Specify the inputs

What does the prompt receive? Define the shape and format of the input. If the input is free text, define its expected range. If the input is structured (a JSON object, a form field), define the schema.

"Input: a customer complaint submitted via the support contact form. It may be one sentence or several paragraphs. It may reference an order number, a product name, or neither."

Step 3: Specify the outputs

What should the prompt produce? Define the format, the fields, and the success criterion for each.

"Output: a JSON object with three fields: severity (string: low/medium/high/critical), reasoning (one sentence explaining the severity), response (2–3 paragraph customer-facing reply)."

Step 4: Add examples

Provide one or two examples of input → output pairs. Cover the easy case and the hard case. The hard case is the one where the input is ambiguous or the classification is not obvious.

Step 5: Add guardrails

Guardrails handle inputs that fall outside the expected range. Every prompt that runs in production will eventually receive an input you did not anticipate. Define what the prompt should do in those cases.

"If the complaint is vague or does not contain enough information to classify severity, assign severity 'low' and include in the response a question that will help clarify the issue."

Step 6: Test on five inputs before shipping

Run the prompt on five real inputs from your actual data. Include at least one edge case: a very short complaint, a very long one, one with no identifying information, one with an angry tone, one with a technical question you cannot answer. See where it fails. Add constraints or examples for the failure modes.

If you get stuck

If the prompt works on simple inputs but fails on complex ones, the failure is usually in the output format specification. Complex inputs produce complex outputs, which may not fit a simple format. Add a format constraint that handles the complex case explicitly.

If the severity classification is inconsistent, the classification criteria are not specific enough. Replace the labels (low/medium/high/critical) with behavioral descriptions: "high: customer is unable to use the product due to the issue. medium: customer is significantly inconvenienced but can work around the issue."

Cross-reference

L11 (Using examples) covers how to write effective few-shot examples. L12 (Avoiding hallucinations) covers guardrails for knowledge-related failures. L14–16 apply this technique to real domain tasks.

Deliverable

Build a prompt following the six steps in this lesson. The prompt should take a short text input, perform a classification or extraction, and return structured JSON. Test it on five inputs and fix at least one failure mode before you consider it done.