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
---
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
- 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
- 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
- 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
- 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
- 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
- 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
Extract the vendor, date, and amount from: 'Invoice from Acme Corp, 2026-01-15, $4,200'
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
System: Extract structured data from invoices and return JSON.
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
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}
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 heresrc/components/Skills/DocRenderer.js- renders this doc format