Prompt Engineering Skill
When to activate
- Writing a system prompt for a Claude-powered application or agent
- Improving the reliability or quality of LLM outputs
- Designing few-shot examples to steer model behaviour
- Debugging why a model isn't following instructions
- Setting up a prompt evaluation framework
- Formatting prompts for structured outputs (JSON, markdown tables, etc.)
When NOT to use
- RAG system design — use the rag-architect skill
- Agent orchestration — use the agent-construction or langgraph skill
- Fine-tuning models — different process entirely
- Prompt injection defence — that's a security topic for the security-reviewer agent
Instructions
System prompt design
Write a production system prompt for [use case]. Use case: [what the AI assistant does — customer support / coding assistant / data extractor / etc.] User: [who sends messages — end users / developers / internal staff] Output format: [free text / JSON / markdown / structured] Constraints: [what the assistant must never do] Tone: [professional / friendly / concise / technical] System prompt structure: ## Role and purpose [Define exactly who the assistant is and what it does] [Be specific — "You are a customer support assistant for Acme Inc., helping users troubleshoot billing issues" is better than "You are a helpful assistant"] ## What you do [List 3-5 specific things the assistant handles] [Use imperative: "Answer questions about...", "Help users...", "Extract..."] ## What you do NOT do [Explicit refusals — critical for production systems] [Examples: "Do not give medical/legal/financial advice", "Do not discuss competitor products", "Do not make up information"] ## Output format [Describe the exact format expected] [If structured: "Always respond in valid JSON matching this schema: {...}"] [If markdown: "Use headings and bullet points. Keep responses under 200 words."] ## Tone and style [Specific guidance: "Be concise — one paragraph max per response", "Use the user's name if available", "If you don't know, say so — do not guess"] ## Examples (optional but powerful) [2-3 few-shot examples showing ideal input → output pairs] User: [example input] Assistant: [ideal output] Write the production system prompt for my use case.
Few-shot prompting
Design few-shot examples for [task]. Task: [what the model should do — classify / extract / reformat / generate / analyse] Input format: [describe] Desired output format: [describe] Common failure modes without examples: [what goes wrong with zero-shot?] Few-shot design rules: 1. Show the format, not just describe it (a concrete example beats 5 lines of instruction) 2. Cover the main input variations (not just the happy path) 3. Include at least one edge case example 4. Examples must be correct — wrong examples harm performance 5. 3-5 examples is usually optimal; > 10 is rarely worth the token cost Template: Here are examples of the task: <example> Input: [example input 1] Output: [ideal output 1] </example> <example> Input: [example input 2 — different variation] Output: [ideal output 2] </example> <example> Input: [example input 3 — edge case] Output: [ideal output 3] </example> Now perform the task for this input: Input: [actual input] Output: For classification tasks: ensure examples cover all classes, balanced. For extraction tasks: show what to return when the field is absent. For generation tasks: demonstrate length, tone, and structure. Design few-shot examples for my specific task.
Chain-of-thought prompting
Add chain-of-thought reasoning to [prompt]. Current prompt: [paste] Problem: [model gives wrong or inconsistent answers on complex inputs] Task type: [math / logic / multi-step reasoning / analysis / planning] Chain-of-thought trigger phrases: Basic CoT: "Think step by step before giving your final answer." Zero-shot CoT (powerful, often sufficient): "Let's think through this carefully: 1. First, identify... 2. Then, consider... 3. Finally, conclude... Provide your reasoning, then state your answer clearly." Few-shot CoT (show the reasoning, not just the answer): <example> Question: [complex question] Reasoning: Let me work through this step by step. First, [observation 1]. This means [inference]. Therefore, [conclusion]. Answer: [final answer] </example> Now answer this question using the same approach: Question: [actual question] Structured reasoning for complex analysis: "Before answering, complete this analysis: 1. SITUATION: [summarise the key facts] 2. CONSTRAINTS: [identify limits or requirements] 3. OPTIONS: [list possible approaches] 4. RECOMMENDATION: [choose the best option and explain why] 5. ANSWER: [final response]" Add chain-of-thought to my prompt. Show before/after comparison.
Output formatting
Control the output format for [prompt]. Desired format: [JSON / markdown table / numbered list / code block / structured text] Why format matters here: [downstream parsing / human readability / API contract] Common formatting failures: [model adds preamble / wrong JSON / mixed formats] JSON output (reliable extraction): Prompt addition: "Respond ONLY with valid JSON. No explanation, no preamble, no markdown code fences. The JSON must match this schema exactly: { "field1": string, "field2": number, "field3": boolean, "items": Array<{name: string, value: number}> } If a field cannot be determined, use null (not the string 'null')." Validation: parse the response with JSON.parse() — if it throws, the prompt needs refinement. Markdown table output: "Format your response as a markdown table with these exact columns: | Column 1 | Column 2 | Column 3 | Do not add any text before or after the table." Numbered list with specific structure: "Respond as a numbered list. Each item: [Title]: [explanation in one sentence]. Example format: 1. First item: This is what it means. 2. Second item: This is what it means." Output control techniques: - Prefix the expected output: "The answer is:" → model continues the format - Use XML tags for clear boundaries: <answer>...</answer> - Specify negative constraints: "Do not include any markdown formatting" - Show the first token: "{" → model continues with JSON Fix the output format for my prompt.
Prompt evaluation
Set up a prompt evaluation framework for [application]. Application: [describe the AI feature] Current prompt: [paste] Quality criteria: [what makes a good output?] Failure modes observed: [what goes wrong?] Evaluation framework: 1. Define metrics (pick 2-4): - Accuracy: correct answer vs. ground truth (for factual tasks) - Format compliance: did it follow the output format? (parseable, valid) - Relevance: did it answer the actual question? - Safety: did it refuse anything it should have / comply with anything it shouldn't? - Latency: tokens generated / time to first token 2. Build a golden test set: - 20-50 representative examples - Cover: common cases, edge cases, adversarial inputs - Each example has: input + expected output (or expected behaviour) - Review golden set with domain expert — garbage in, garbage out 3. Automated evaluation options: - Exact match: for structured outputs (JSON field match) - LLM-as-judge: use Claude to score outputs against criteria "Rate this response 1-5 for [criterion]: [output]" - Semantic similarity: for free-text where paraphrasing is OK - Rule-based: regex for format, word count, forbidden phrases 4. Evaluation loop: a. Write prompt v1 b. Run against golden set c. Identify failure modes d. Fix prompt (add instruction, example, or constraint) e. Re-run — confirm improvement, watch for regressions f. Ship when accuracy meets threshold 5. Production monitoring: - Sample X% of production calls for human review - Track refusal rate, error rate, user feedback - Alert if output format compliance drops below threshold Set up the evaluation framework for my specific application.
Example
User: I'm building a customer support bot for a SaaS product. It keeps making up answers when it doesn't know something. How do I fix this?
Claude's system prompt fix:
This is a grounding problem — the model defaults to generating plausible-sounding answers rather than admitting uncertainty. Fix it with explicit instructions, a clear knowledge boundary, and a refusal template.
Before (broken):
You are a helpful customer support assistant for Acme SaaS. Answer customer questions about the product.
After (fixed system prompt):
You are a customer support assistant for Acme SaaS. You help users with billing questions, account management, and product usage. ## What you know You can answer questions about: - How to use features documented in our help centre - Billing, subscription plans, and invoice questions - Account settings and user management - Common error messages and how to resolve them ## What you do NOT do - Do not guess or make up product features, pricing, or capabilities - Do not answer questions about competitor products - Do not make promises about future features or timelines ## When you don't know the answer Say exactly this: "I don't have that information in my knowledge base. Let me connect you with a human agent who can help." Then provide this: "You can reach our team at support@acme.com or chat with a human below." Never say "I think" or "I believe" — if you're not certain, say you don't know. ## Response format - Keep responses under 150 words - Use bullet points for multi-step instructions - Always end with: "Does that help? Let me know if you have any other questions."
Additional fix — add a knowledge file: Pass the actual product documentation in the context (or via RAG). The model can't "know" something it wasn't told. A system prompt that says "you know X" without providing X just encourages hallucination.


