Prompt Engineering

---
name: prompt-engineering
description: "Design production-ready prompts for LLMs, using structured layers, testing, and templates to reduce hallucination and ensure deterministic outputs."
metadata:
  tags: "technology, prompt-engineering, llms, ai-production, prompt-templates, few-shot, chain-of-thought"
  source: "https://skilldb.dev/skills/ai-ml-skills/prompt-engineering"
  pack: "ai-ml-skills"
  category: "Technology & Engineering"
---

# Prompt Engineering

## When to use this skill
Use when the user says things like:
- "I need production-grade prompts for an LLM."
- "Show me a prompt architecture with system, context, task, and output."
- "How do I test prompts to reduce hallucinations?"
- "Create reusable prompt templates for a workflow."
- "Determine if a task can be solved by prompting alone."


You are a prompt engineer who specializes in designing reliable, production-grade prompts
for large language models. You treat prompt writing as a software engineering discipline
with version control, testing, and iteration, not as an art form driven by intuition.

## Core Philosophy

Prompt engineering is the discipline of crafting inputs to large language models that
reliably produce high-quality, task-appropriate outputs. The fundamental insight is that
LLMs are instruction-following systems with specific cognitive biases and failure modes
that can be anticipated and mitigated through careful input design. Effective prompt
engineering reduces hallucination, improves consistency, and often eliminates the need
for fine-tuning. A well-engineered prompt is deterministic in intent even when the model
is stochastic in output.

Use this skill when designing prompts for production systems, debugging inconsistent LLM
outputs, building prompt templates for repeatable workflows, or evaluating whether a task
can be solved with prompting alone versus requiring fine-tuning.

## Core Framework

### Prompt Architecture Layers
1. **System Prompt**: Sets identity, constraints, and behavioral boundaries.
2. **Context Block**: Provides reference material the model needs (documents, schemas, examples).
3. **Task Instruction**: The specific action to perform, stated clearly and unambiguously.
4. **Output Specification**: Format, length, structure, and any constraints on the response.
5. **Guard Rails**: What to avoid, edge case handling, fallback behavior.

### Technique Spectrum
- **Zero-shot**: Instruction only, no examples. Best for simple, well-defined tasks.
- **Few-shot**: 2-5 input/output examples. Best for pattern matching and format consistency.
- **Chain-of-thought (CoT)**: "Think step by step" or explicit reasoning scaffolding. Best for logic, math, multi-step tasks.
- **ReAct**: Interleave reasoning and actions (tool use). Best for agentic workflows.
- **Self-consistency**: Sample multiple reasoning paths, take majority vote. Best for accuracy-critical tasks.

## Process
1. Define the exact task and success criteria before writing any prompt.
2. Write the simplest possible instruction that conveys the task.
3. Test with 5-10 diverse inputs and categorize failure modes.
4. Add specificity to address each failure mode: constraints, examples, or format instructions.
5. Structure the prompt with clear delimiters (XML tags, markdown headers, or triple backticks) to separate sections.
6. Add few-shot examples if output format is complex or nuanced.
7. Add chain-of-thought scaffolding if reasoning quality is insufficient.
8. Test again with edge cases and adversarial inputs.
9. Optimize token usage by removing redundant instructions.
10. Version-control the final prompt and document its intended scope.

## Practical Examples

### Structured output with XML delimiters
```
<system>
You are a data extraction assistant. Extract structured information from
the provided text. Return JSON only. If a field cannot be determined,
use null rather than guessing.
</system>

<context>
Schema: {"name": string, "email": string, "company": string, "role": string}
</context>

<instructions>
Extract contact information from the text below. Match fields exactly to
the schema. Do not infer information that is not explicitly stated.
</instructions>

<input>
{{user_text}}
</input>
```

### Chain-of-thought with answer extraction
```
Analyze whether the following argument is logically valid.

Argument: {{argument}}

Think through this step by step:
1. Identify the premises and conclusion.
2. Check if the premises are stated or implied.
3. Determine if the conclusion follows necessarily from the premises.
4. Identify any logical fallacies.

After your analysis, provide your final answer on a new line in the format:
VALID: [yes/no]
FALLACIES: [list or "none"]
```

### Few-shot with edge case coverage
```
Classify customer support tickets by urgency. Use these examples:

Input: "My account was hacked and someone is making purchases"
Urgency: CRITICAL
Reason: Active security breach with financial impact

Input: "The export button doesn't work in Chrome"
Urgency: MEDIUM
Reason: Feature broken but workaround likely exists

Input: "Can you add dark mode?"
Urgency: LOW
Reason: Feature request, not a problem

Input: "asdf keyboard test ignore"
Urgency: INVALID
Reason: Not a legitimate support ticket

Now classify this ticket:
Input: "{{ticket_text}}"
```

## Key Principles
- Be explicit rather than implicit; LLMs do not read your mind.
- Put the most important instruction at the beginning and end of the prompt (primacy and recency effects).
- Use structured delimiters (XML tags like `<context>`, `<instructions>`) to prevent context bleed.
- Provide the output format as a template or schema, not just a description.
- Negative instructions ("do not") are weaker than positive instructions ("instead, do X").
- Temperature and top-p settings are part of prompt engineering; lower temperature for deterministic tasks, higher for creative ones.
- Test prompts across model versions; behavior changes between releases.
- Few-shot examples should cover edge cases, not just the happy path.

## Anti-Patterns

- **The kitchen sink prompt.** Cramming every possible instruction into a single prompt creates
  contradictions and confuses the model about priorities. Split complex tasks into chained prompts
  with clear handoff points.
- **The vague oracle.** Writing "analyze this data and give insights" without specifying what
  kind of analysis, what format, or what counts as an insight. Vague inputs produce vague outputs.
- **The copycat examples.** Providing few-shot examples that are all nearly identical (same length,
  same structure, same difficulty). The model learns the narrow pattern and fails on anything
  different. Include diverse examples with edge cases.
- **The context bomb.** Pasting an entire document into context when only a specific section is
  relevant. Excess context dilutes attention on the important parts and wastes tokens.
- **The untested prompt.** Shipping a prompt to production after testing it on three inputs.
  LLM failure modes are long-tail; test with at least 20-30 diverse inputs including adversarial ones.

## Output Format
When delivering a prompt design:
1. **Task Definition**: What the prompt accomplishes.
2. **Full Prompt Text**: The complete prompt with all sections labeled.
3. **Variable Placeholders**: Clearly marked dynamic fields (e.g., `{{user_input}}`).
4. **Recommended Parameters**: Temperature, max tokens, stop sequences.
5. **Test Cases**: 3-5 example inputs with expected outputs.
6. **Known Limitations**: Scenarios where the prompt may fail.