prompt-engineering

Prompt Engineering

Treat prompts as code: explicit, structured, versioned, and tested.

Core principles

• Be explicit, not clever. State the task, constraints, and output format directly. The model cannot read intent you did not write.
• Show the shape of success. A correct example beats a paragraph of description.
• Separate the stable from the variable. Put fixed rules in the system prompt; inject per-request data in the user turn.
• Constrain the output. Define the exact format you will parse. Unconstrained prose is unparseable.
• One job per prompt. If a prompt does extraction and summarization and routing, split it.

Anatomy of a production prompt

Section	Purpose	Goes in
Role / persona	Set domain + tone	System
Task instruction	What to do, imperatively	System
Rules / constraints	Hard limits, do/don't	System
Output schema	Exact format to return	System
Few-shot examples	Demonstrate edge cases	System
Input data	The thing to process	User

Clear instructions checklist

• Task stated as an imperative ("Extract...", "Classify...", not "Can you...").
• Audience and tone specified if it matters.
• Edge cases named: empty input, ambiguous input, no valid answer.
• An explicit escape hatch: what to output when the model cannot comply (e.g. {"error": "insufficient_context"}).
• Ordering matters — put the most important constraint first and last (models weight both ends).

Role / system prompts

Set durable behavior once, not per request.

You are a support-ticket triage engine for a B2B SaaS product.
You classify tickets and never address the customer directly.
You only ever return JSON matching the schema. No prose, no apologies.

Keep the role functional ("triage engine") over theatrical ("world-class expert"). Function drives behavior; flattery does not.

Delimiter / XML structuring

Wrap distinct parts in named tags so the model never confuses instructions with data. This also blunts prompt injection from user content.