Prompt Engineering Patterns

Prompt Engineering Patterns

Overview

This skill curates the upstream prompt-engineering-patterns material into an execution-oriented workflow for designing, testing, and hardening prompts.

Use it when you need more than a clever prompt phrase. Modern prompt engineering is an iterative engineering loop:

1. define the task and success criteria,
2. place instructions at the right priority level,
3. choose the right output contract,
4. add examples or grounded context when needed,
5. test on representative cases,
6. troubleshoot specific failure modes,
7. keep the variants that measurably improve results.

Treat prompts as interfaces, not magic spells. Good prompts reduce ambiguity, make outputs easier to validate, and improve consistency, but they do not guarantee determinism. Use lightweight evals and acceptance thresholds before declaring a pattern production-ready.

For quick operator support, use:

• references/domain-notes.md for a decision matrix and failure-mode map
• examples/worked-example.md for before/after prompt revisions across common task types

When to Use This Skill

Use this skill when you are:

• designing prompts for production or repeated use
• improving output reliability, structure, or controllability
• deciding between plain instructions, examples, decomposition, or schema-based outputs
• tuning prompts for grounded answers against supplied context
• fixing recurring failures such as hallucinations, format drift, verbosity, or instruction collisions
• building a small eval set to compare prompt variants

Do not use this skill as the primary solution when:

• the real problem is bad source data, missing retrieval, or a broken tool integration
• you need model fine-tuning, classifier training, or application architecture changes more than prompt changes
• the task is unrelated to LLM prompting
• you are trying to bypass safety policies or force disallowed behavior

Operating Table

Workflow

1. Define the objective

   • State the task in one sentence.
   • Identify the audience, constraints, and failure cost.
   • Decide whether the result is for a human, a downstream tool, or another model step.

2. Define success before rewriting the prompt

   • Write 3-5 acceptance checks.
   • Include at least one edge case.
   • If the output feeds automation, include strict format checks.

3. Place instructions at the correct priority level

   • Put durable behavior and non-negotiable rules in system/developer instructions when your stack supports them.
   • Put task-specific requests, data, and user intent in the user message.
   • Avoid scattering critical rules across multiple places.

4. Choose the lightest pattern that fits

   • Clear instructions only: for straightforward tasks.
   • Few-shot examples: when style, mapping, or transformation behavior matters.
   • Decomposition/checklists: when the task has multiple steps or failure points.
   • Grounded-context prompting: when the answer must come from supplied material.
   • Structured outputs/schema: when the output must be machine-readable.

5. Write the first prompt with explicit boundaries

   • Separate instructions, context, and input using headings, XML-style tags, or clear delimiters.
   • State what to do when information is missing, conflicting, or out of scope.
   • Specify output length, format, and refusal or fallback behavior where relevant.

6. Test against a small eval set

   • Use 5-20 representative cases.
   • Include normal, edge, and adversarial cases.
   • Compare prompt variants on the same cases.

7. Troubleshoot by failure mode

   • Do not just “make it more specific.”
   • Identify whether the problem is instruction clarity, bad examples, weak grounding, poor output contract, or missing eval coverage.

8. Freeze reusable patterns

   • Keep the winning prompt with notes on what changed.
   • Retain known-bad cases as regressions.
   • Document provider-specific dependencies such as schema enforcement support.

Instruction hierarchy and role separation

Prompt quality depends on where instructions live.

• System/developer instructions: stable behavior, policy-safe boundaries, tool-use expectations, output rules that should persist across tasks.
• User instructions: task request, task data, desired outcome, optional preferences.
• Reference/context blocks: source material the model should use or quote from.

Guidelines:

• Keep the highest-priority instructions short and durable.
• Do not rely on a later example to override an earlier hard rule.
• If two instructions conflict, resolve the conflict explicitly in the prompt instead of hoping the model guesses correctly.
• Ask for concise, verifiable reasoning artifacts when needed; do not depend on hidden chain-of-thought extraction as a primary quality mechanism.

Few-Shot Learning

Use few-shot examples when the task is easier to learn from demonstrations than from abstract rules alone.

Best uses:

• classification with nuanced labels
• rewriting into a house style
• extraction or mapping tasks
• transformations where edge behavior matters

Best practices:

• Keep examples close to the real task distribution.
• Use high-quality examples only; bad examples teach bad behavior.
• Make the examples consistent in format and level of detail.
• Include boundary cases when common mistakes are predictable.
• Keep the number of examples as small as possible while preserving behavior.

Avoid few-shot examples when:

• the task is simple enough for direct instructions
• examples may anchor the model to stale wording or outdated policy
• token budget is tight and the examples are not adding measurable value

Failure signal:

• The model copies example wording, labels, or structure too literally and ignores a new instruction. If that happens, simplify the examples, restate priority rules, or move non-negotiable behavior into higher-priority instructions.

Reasoning control

Older guidance often overused “think step by step.” Prefer reasoning controls that improve correctness and keep outputs auditable.

Use one of these patterns instead:

• Plan then answer: ask for a brief plan or checklist before the final output when intermediate structure improves correctness.
• Decomposition: split the task into ordered sub-questions.
• Verification checklist: require the model to confirm that constraints were met.
• Answer-only mode: when extra reasoning text creates noise or leakage into machine-readable outputs.

Prefer this:

• “First identify the governing constraints. Then produce the final answer in the specified schema.”
• “Use the provided source excerpts only. If evidence is insufficient, say what is missing.”
• “Before finalizing, check whether each required field is present and valid.”

Be careful with this:

• “Think step by step” as the only improvement strategy.

Reasoning text is not a substitute for better instructions, examples, grounded evidence, or evals.