AI & Machine Learning6 min read

Prompt Engineering

The craft of writing inputs that make LLMs produce reliable, on-format outputs without retraining - the fastest way to improve quality before reaching for fine-tuning

LLMAIClaudeOpenAIPrompting
---
name: prompt-engineering
description: >
  You are a prompt engineer. You design system prompts, few-shot examples, and output constraints that make LLMs produce reliable, safe, structured results in production.
---

Prompt engineering is the fastest lever on LLM output quality - before fine-tuning, before RAG, before switching models. A production-ready prompt has four parts: role, constraints, output format, and examples. The gap between a working prompt and a production prompt is an eval set; without one you cannot tell if a change helped or hurt.

Workflow

  1. Build an eval set of 15-20 representative inputs before writing the first prompt versionWithout a baseline you cannot tell if prompt changes improved or broke behavior - informal testing on 3 examples misses the long tail of real user inputs
  2. Write the system prompt with four sections in order: role, constraints, output format, examplesA prompt missing output format produces inconsistent structure that requires downstream parsing hacks; missing examples produces format drift across the distribution of inputs
  3. Add 2-3 few-shot examples covering the typical case, an edge case, and the expected output for an ambiguous inputExamples outperform instructions for format adherence - the model infers the pattern rather than following a rule, which is more robust to paraphrase
  4. Test adversarial inputs: empty string, very long input, prompt injection attempts, non-target-language inputPrompts that work on clean inputs fail on edge cases that real users hit regularly; catching these before production is cheaper than fixing them after
  5. Use LLM-as-judge with a rubric for quality dimensions that cannot be checked with exact string matchCorrectness on reasoning tasks, tone, and safety cannot be evaluated with regex; a second model scoring outputs against a rubric scales the eval set without human annotation
  6. Version prompts in source control alongside the model version they were tuned forA prompt optimized for Claude 3 may fail silently on Claude 4 or GPT-4o; version-locked tracking makes regressions visible and rollback possible

Output Format

A production system prompt has four sections in this order: role definition, behavioral constraints, output format spec with a JSON schema or markdown template, and 2-3 input/output examples.

You are a [role]. [Constraint 1]. [Constraint 2]. Always respond in this exact format:
{"field": "value"}

Examples:
Input: [example]
Output: {"field": "example value"}

Input: [edge case]
Output: {"field": "edge case value"}

Examples

Structured JSON extraction from free text

Input

Extract the vendor, date, and amount from: 'Invoice from Acme Corp, 2026-01-15, $4,200'

Output

System prompt specifies: {"vendor": string, "date": YYYY-MM-DD, "amount_usd": number}. One few-shot example. Output: {"vendor": "Acme Corp", "date": "2026-01-15", "amount_usd": 4200}

Wrong: instruction without output format or examples

Input

System: Extract structured data from invoices and return JSON.

Output

Inconsistent keys (vendor vs company vs name), inconsistent date formats, hallucinated fields - the model guesses the schema differently on every run

Right: role + schema + example

Input

System: You are an invoice parser. Extract only vendor, date (YYYY-MM-DD), and amount_usd (number). Return only the JSON object, no other text. Example: 'Bill from Acme 2026-01-15 $100' -> {"vendor":"Acme","date":"2026-01-15","amount_usd":100}

Output

Consistent schema, correct types, no hallucinated fields, no explanation text - works across diverse invoice formats

Edge Cases & Gotchas

  • Prompt injection - user input that overrides system instructions. Fix: wrap user input in XML tags (<user_input>...</user_input>) and instruct the model to treat the content inside as data, not instructions
  • Token limit exceeded by large few-shot block - user input gets truncated from context. Fix: measure prompt template token count at startup and enforce max_input_tokens = context_window - template_tokens - response_buffer
  • Language drift - model responds in the user's language instead of the required output language. Fix: add 'Always respond in English regardless of input language' as the last line of the system prompt
  • Format non-compliance on long outputs - model adds explanation text before or after the JSON on complex outputs. Fix: append 'Return only the JSON. No preamble, no markdown fences, no explanation' and test with inputs that trigger long reasoning chains

When to Break These Rules

  • Skip few-shot examples when the model already performs correctly on zero-shot - adding examples increases token cost and can introduce bias toward the example distribution
  • Use fine-tuning instead when: you need consistent style or persona across 1000+ diverse outputs, few-shot would require 10+ examples to cover the space, or latency from a long prompt exceeds your SLA

Reference Files

  • src/data/skills/index.js - add skill entries here
  • src/components/Skills/DocRenderer.js - renders this doc format

More skills in this library

Browse all technical skills - Mobile, AI/ML, Web, Backend, Design, and Product.