Prompt Engineering

Prompt Engineering Patterns

Overview

Use this skill to design, review, and debug prompts with an execution-focused workflow.

This skill is not only about wording. Good prompt engineering also includes:

• choosing the right task pattern
• separating stable instructions from task data
• defining an output contract before generation
• deciding when examples are necessary
• using structured outputs or tool/function calling when reliability matters
• evaluating prompt behavior with a small test set instead of guessing

The upstream intent is preserved: this is an expert guide for prompt engineering patterns, best practices, and optimization techniques. The enhanced version makes those patterns operational so an agent can select, apply, and troubleshoot them safely.

Open these support files when needed:

• references/prompt-patterns-reference.md for the decision matrix, anti-patterns, and prompt review checklist
• examples/prompt-patterns-example-pack.md for before/after prompt rewrites and expected outcomes across common task types

When to Use This Skill

Use this skill when the user asks to:

• improve a weak or inconsistent prompt
• choose between zero-shot, few-shot, decomposition, tool use, or schema-constrained output
• debug why an agent ignores instructions, produces malformed output, or hallucinates
• make outputs easier to parse, compare, or automate downstream
• design prompt templates for repeated tasks
• review prompt quality before shipping an agent workflow

Do not rely on prompt engineering alone when the real problem is:

• missing or stale knowledge that should come from retrieval or attached context
• a need to perform actions in external systems, which should use tools/function calling
• missing evaluation coverage, where the right fix is a test set rather than more prompt text
• policy or role conflicts caused by system/developer instructions outside the prompt under review

Operating Table

For more detailed routing, open references/prompt-patterns-reference.md.

Workflow

1. Classify the task

   • Determine whether the job is classification, extraction, summarization, transformation, planning, tool use, or constrained generation.
   • Do not start by tweaking phrasing blindly.

2. Define success criteria

   • Write down what a good answer must contain.
   • Include format, correctness constraints, required fields, and unacceptable behaviors.
   • If a downstream system must parse the output, decide that now.

3. Separate instruction layers

   • Keep stable rules in higher-priority instructions.
   • Keep user content, examples, and source material clearly delimited.
   • Avoid mixing quoted user text with actual instructions.

4. Draft the smallest prompt that can work

   • State the task clearly.
   • Provide only the context needed.
   • Specify the expected output shape.
   • Use delimiters for inputs, source text, and examples.

5. Choose the output contract

   • Use free text for open-ended writing.
   • Use a template for human-readable consistency.
   • Use structured outputs or function/tool calling when parseability and automation matter.
   • Do not treat free-form “respond in JSON” as the reliability default.

6. Add examples only when they improve behavior

   • Prefer 2-5 compact, representative examples.
   • Cover edge cases that the model is currently missing.
   • Remove examples that anchor the model too narrowly.

7. Run a small evaluation set

   • Test 3-5 representative cases, including one edge case.
   • Check instruction adherence, factual grounding, format validity, and unnecessary verbosity.
   • Keep one baseline and one revised variant so the delta is visible.

8. Debug one variable at a time

   • Change only one of: instruction order, delimiters, examples, context length, schema strictness, or tool description.
   • Record what changed and whether behavior improved.

Few-Shot Learning

Use few-shot prompting when the model understands the task class but performs inconsistently on format, edge cases, or style.

Best practices:

• Keep examples short and representative.
• Match the real distribution of inputs.
• Show the exact output format you want.
• Include borderline cases when labels or extraction rules are subtle.
• Prefer a few high-quality examples over many noisy ones.

Use few-shot sparingly when:

• the task is already simple and explicit instructions are enough
• examples may bias the model toward a narrow pattern
• long examples crowd out the actual source material

See examples/prompt-patterns-example-pack.md for concrete before/after rewrites.

Chain-of-Thought Prompting

Use this section carefully.

Do not treat best practice as “ask for hidden chain-of-thought verbatim.” A safer and more durable pattern is to ask for the observable artifact you actually need, such as:

• a short numbered plan
• key assumptions
• a brief justification
• a checklist-based verification pass
• structured intermediate fields

Good uses:

• planning a sequence of actions
• surfacing assumptions before a recommendation
• checking whether all required constraints were applied
• requiring evidence mapping from provided context

Bad uses:

• requesting long unrestricted reasoning for simple tasks
• forcing verbose rationale when only a label or structured extraction is needed
• assuming more reasoning text always improves correctness

If accuracy improves only when the task is decomposed, ask for explicit sub-steps or intermediate outputs rather than unrestricted internal reasoning.