prompt-engineering

What this skill does

# Prompt Engineering

Prompt engineering is the practice of designing inputs that guide LLMs to produce desired outputs. Effective prompts reduce errors, improve consistency, and unlock model capabilities.

## Table of Contents

- [Core Principles](#core-principles)
- [Be Clear and Direct](#be-clear-and-direct)
- [Use Examples (Multishot)](#use-examples-multishot)
- [Reasoning Guidance](#reasoning-guidance)
- [XML Tags](#xml-tags)
- [Role Prompting](#role-prompting)
- [Long Context](#long-context)
- [Output Control](#output-control)
- [Self-Verification](#self-verification)
- [Best Practices](#best-practices)
- [References](#references)

## Core Principles

**Golden rule**: Show your prompt to a colleague with minimal context. If they're confused, the model will be too.

1. **Be explicit** - State exactly what you want; never assume the model knows your preferences
2. **Provide context** - Include what the output is for, who the audience is, and what success looks like
3. **Use structure** - Sequential steps, XML tags, and clear formatting reduce ambiguity
4. **Show examples** - Demonstrations outperform descriptions for complex formats

## Be Clear and Direct

Treat the model as a capable but context-free collaborator. Specify:
- What the task results will be used for
- What audience the output is meant for
- What a successful completion looks like

### Vague vs Specific

```
# Vague
Analyze this data and give insights.

# Specific
Analyze this Q2 sales data for our board presentation.
1. Identify the top 3 revenue trends
2. Flag any anomalies exceeding 15% variance
3. Recommend 2-3 actionable next steps
Format as bullet points, max 200 words.
```

### Sequential Steps

Use numbered lists for multi-step tasks:

```
Your task is to anonymize customer feedback.

Instructions:
1. Replace customer names with "CUSTOMER_[ID]"
2. Replace emails with "EMAIL_[ID]@example.com"
3. Redact phone numbers as "PHONE_[ID]"
4. Leave product names intact
5. Output only processed messages, separated by "---"
```

## Use Examples (Multishot)

Provide 3-5 diverse examples to demonstrate expected behavior. Examples reduce misinterpretation and enforce consistent formatting.

### Structure

```
Categorize customer feedback by issue type and sentiment.

<examples>
<example>
Input: The dashboard loads slowly and the export button is hidden.
Category: UI/UX, Performance
Sentiment: Negative
Priority: High
</example>

<example>
Input: Love the Salesforce integration! Would be great to add Hubspot.
Category: Integration, Feature Request
Sentiment: Positive
Priority: Medium
</example>
</examples>

Now categorize: {{FEEDBACK}}
```

### Tips

- Make examples **relevant** to actual use cases
- Include **edge cases** and potential challenges
- Vary examples to prevent unintended pattern matching
- Wrap in `<example>` tags for clarity

## Reasoning Guidance

For complex tasks, guide the model to reason before answering, but ask for concise conclusions or verifiable work rather than unrestricted hidden chain-of-thought.

### Basic

```
Determine the best investment option for this client. Think step-by-step.
```

### Guided

Specify what steps to consider:

```
Think before answering:
1. Consider the client's risk tolerance given their 5-year timeline
2. Calculate potential returns for each option
3. Factor in market volatility history
4. Then provide your recommendation
```

### Structured (Recommended)

Separate private analysis instructions from the required answer format:

```
Analyze this contract for legal risks.

Before answering, check:
- Indemnification implications
- Liability exposure
- IP ownership concerns

Then provide:
<answer>
- Top risks
- Recommended edits
- Open questions
</answer>
```

When you need auditability, ask for brief supporting rationale, calculations, cited evidence, or a checklist of checks performed. Do not require full chain-of-thought unless the target model or product explicitly supports exposing it.

## XML Tags

Use XML tags to separate prompt components. This prevents instruction/content confusion and improves parseability.

### Common Tags

```
<instructions>Task steps and requirements</instructions>
<context>Background information</context>
<document>Source material to process</document>
<example>Demonstration of expected behavior</example>
<constraints>Boundaries and limitations</constraints>
<output_format>Expected response structure</output_format>
```

### Nested Structure

```
<documents>
  <document index="1">
    <source>annual_report_2023.pdf</source>
    <content>{{REPORT_CONTENT}}</content>
  </document>
  <document index="2">
    <source>competitor_analysis.xlsx</source>
    <content>{{ANALYSIS_CONTENT}}</content>
  </document>
</documents>

<instructions>
Compare revenue trends across both documents.
Identify strategic advantages mentioned in the annual report.
</instructions>
```

### Reference Tags in Instructions

Be explicit when referring to tagged content:

```
Using the contract in <contract> tags, identify all clauses
related to termination.
```

## Role Prompting

Set expertise context via system prompts to improve domain-specific performance.

### System Prompt Pattern

```python
system = "You are a senior securities lawyer at a Fortune 500 company."
user = "Review this acquisition agreement for regulatory risks."
```

### Effective Roles

```
# General
You are a [role] at [organization type].

# Specific (better)
You are the General Counsel of a Fortune 500 tech company
specializing in M&A transactions.

# With behavioral guidance (best)
You are a senior data scientist. You prioritize statistical
rigor over speed. When uncertain, you state assumptions
explicitly and suggest validation approaches.
```

### When to Use

- Complex analysis requiring domain expertise
- Tasks where tone/style matters (legal, medical, executive)
- When a specific perspective would improve output quality

## Long Context

For prompts with large documents (20K+ tokens):

### Document Placement

Place long documents **at the top**, before instructions:

```
<documents>
{{LARGE_DOCUMENT_CONTENT}}
</documents>

<instructions>
Summarize the key findings from the document above.
Focus on financial implications.
</instructions>
```

### Quote Grounding

Ask the model to cite sources before analyzing:

```
<documents>
{{PATIENT_RECORDS}}
</documents>

First, find and quote the relevant sections in <quotes> tags.
Then provide your diagnosis in <analysis> tags, referencing
the quoted evidence.
```

### Multi-Document Metadata

Include source information for attribution:

```
<documents>
  <document index="1">
    <source>quarterly_report_q2.pdf</source>
    <date>2024-07-15</date>
    <content>{{CONTENT}}</content>
  </document>
</documents>
```

## Output Control

### Verbosity Specification

```
<output_format>
- Default responses: 3-6 sentences or ≤5 bullets
- Simple factual questions: ≤2 sentences
- Complex analysis: 1 overview paragraph + ≤5 tagged bullets
</output_format>
```

### Format Constraints

```
Output requirements:
- Use markdown tables for comparisons
- Code blocks for any technical content
- No introductory phrases ("Here's...", "Sure...")
- End with exactly 3 action items
```

### Scope Boundaries

Prevent drift from original intent:

```
Implement EXACTLY and ONLY what is requested.
- Do not add features beyond the specification
- Do not refactor surrounding code
- Choose the simplest valid interpretation
- Ask for clarification rather than assuming
```

## Self-Verification

For high-stakes outputs, include verification steps:

```
<verification>
Before finalizing your response:
1. Re-read the original request
2. Check that all requirements are addressed
3. Verify any specific claims against provided documents
4. Soften language where certainty is low
5. Flag any assumptions you made
</verification>
```

### Uncertainty Acknowledgment

```
When uncertain:
- Explicitly state "Based on the provided context..."
- Offer 2-3 plausible in