Prompt Engineering Skill

---
name: prompt-engineering
description: Write, review, or fix a prompt. Use when the user asks for a prompt, wants better output from a model, says the model is ignoring instructions, or is building a system prompt for an app or agent.
---

# Prompt Engineering

There is no perfect prompt, only a perfect process. The highest-leverage move is never a wording trick; it is having a way to tell whether a change helped.

## Diagnose before writing

Establish three things, asking if they are not stated:

1. **Model class.** A reasoning model or a standard one. This flips several rules.
2. **Task type.** Math or symbolic, extraction or classification, creative, agentic, or long-context analysis. Step-by-step reasoning instructions pay off substantially on math and symbolic work and close to nothing elsewhere, so the task type decides whether to include them at all.
3. **Surface.** Chat or API. The API offers structured outputs, role separation, prefilling, and effort controls, and every one of those beats a wording change.

## Build only the components the task needs

In roughly this order, including a component only when it earns its place:

1. **Instruction**: lead with a direct verb and say exactly what you want. Specificity is the most reliable win available.
2. **Context**: why this matters and who the output is for. A reasoned rule outperforms a bare prohibition.
3. **Constraints**: scope, length, audience, exclusions. Prefer telling the model what to do over what to avoid.
4. **Persona**: only for tone and audience framing. Never as an accuracy lever; it does not improve correctness.
5. **Examples**: the strongest addition for format and pattern tasks. Start with one, add more only if outputs stay inconsistent, keep labels balanced, and make every example match the stated rules exactly, because examples override instructions when they disagree.
6. **Output format**: state it explicitly. On an API, use structured outputs rather than describing the format in prose.
7. **Uncertainty permission**: "if the information is insufficient, say so rather than speculating". Cheap, and it reduces fabrication on factual work.
8. **Placement**: put long pasted material at the start or the end, never in the middle, and split a multi-objective prompt into a chain.
9. **Hierarchy**: durable rules in the system prompt, per-request content in the user turn. Never let retrieved documents or tool output sit at instruction-level trust.

On a reasoning model: drop manual step-by-step instructions and worked reasoning examples, keep the prompt direct, remove contradictions aggressively, and control depth with the effort setting rather than with wording. On a standard model doing math or logic: add the step-by-step instruction, and expect a real gain there specifically.

## Strip the anti-patterns

Scan every prompt, yours or theirs, and name each one found with the fix in one line:
- Contradictory or vague instructions, which are the most damaging flaw on current models
- Manual chain-of-thought on a reasoning model
- Expert personas used to improve accuracy
- Politeness, threats, or emotional appeals used as performance levers
- Technique stacking. Longer is not better; the best prompt is the minimum structure that hits the goal reliably
- Critical material buried in the middle of a long input
- Examples whose style or labels contradict the instructions
- Assuming a prompt tuned on one model transfers to another

## Close with the measurement

Never deliver a prompt without it, scaled to the stakes:
1. Define success and gather 5 to 20 test inputs before trusting it.
2. Change one variable at a time, and test two or three phrasings, because a single result is noise.
3. Re-test on every model upgrade.
4. With a metric and roughly fifty labeled examples, move to automatic optimization for the prompts that matter most.

When reviewing someone's prompt, output: the verdict in one line, the numbered issues each tagged with its anti-pattern and fix, the rewritten prompt, and the testing plan.