prompt-engineering-expert

Prompt Engineering Expert

Examples beat adjectives; structure beats length. Tell the model who it is, what success looks like, and the exact output shape — then iterate against fixed test cases, changing one thing at a time.

When to Use

• Writing or improving a system/user prompt.
• Inconsistent, off-format, verbose, or low-quality model output.
• Needing structured output (JSON/schema), extraction, classification, or agents.
• Reducing hallucination or steering tone/length/reasoning.

When NOT to Use

• Retrieval/context assembly → rag-expert.
• Quantitative eval/regression harness → llm-testing-expert.
• Model training/fine-tuning → deep-learning-expert.
• Anthropic SDK wiring + caching → claude-api (built-in).

Core Principles

1. Structure the prompt

• State role, task, and success criteria explicitly. Durable rules → system prompt; the variable task/data → user turn.
• Separate sections with clear delimiters (markdown headings or XML-like tags <context>…</context>) so instructions, data, and examples don't blur.
• Be specific about constraints: length, tone, audience, and what to do on ambiguity or missing info. Prefer positive instructions ("respond in valid JSON") over a pile of "don't".

2. Steer with examples & reasoning

• Few-shot: 2–5 representative, diverse examples that demonstrate the exact format and tricky edge cases. Examples teach format faster than descriptions.
• For reasoning-heavy tasks, let the model think before answering (chain-of-thought / a scratchpad), but keep the final output concise — or separate reasoning from the user-visible answer.
• Put the most important instruction near the start or end; long middles get "lost".

3. Reliable structured output

• For machine consumption, define a strict schema and use the provider's structured-output/JSON mode or tool-calling. Show one example of the exact shape.
• Provide a fallback so the model doesn't invent values: "if a field is unknown, use null; do not guess."

4. Iterate like an engineer

• Build a small fixed test set including hard/adversarial cases. Change one variable at a time, compare outputs, and version prompts. Don't trust a single lucky run.
• Watch for prompt injection when user content is included; keep instructions and untrusted data clearly separated and don't let data override rules.

Common Mistakes

• Vague asks ("make it good") → specify criteria, format, length.
• Conflicting/buried instructions → consolidate; structure with delimiters.
• No examples for format-sensitive tasks → add few-shot.
• Forcing CoT into the user-facing answer → separate or hide reasoning.
• Over-stuffing the prompt → signal drops; trim to what changes behavior.
• Free-text parsing of "JSON-ish" output → use real structured-output mode + a schema.
• Tuning on one example → use a test set; one input overfits.

Examples

Structured extraction with schema + fallback

System: You extract structured data. Output ONLY valid JSON matching the schema.
Schema: { "name": string, "amount": number, "currency": string|null }
Rules: If a field is absent in the text, use null. Do not guess or add fields.

User:
<text>
Invoice from Acme Corp for $1,250.00, net 30.
</text>

Expected: { "name": "Acme Corp", "amount": 1250.0, "currency": "USD" }

Few-shot classifier (format by example)

Classify sentiment as positive | neutral | negative.
"Loved it" -> positive
"It arrived" -> neutral
"Broke in a day" -> negative
"Does the job, nothing special" ->

See Also

• rag-expert — grounding prompts with retrieved, cited context.
• llm-testing-expert — evaluating prompt changes objectively.
• claude-api (built-in) — Anthropic SDK, tool use, and prompt caching.