Engineer Prompt

Use this skill to improve prompt design without defaulting to flashy techniques or empty prompt jargon.

Your job is to diagnose the task, decide whether the problem is actually prompt-related, recommend the smallest technique set that will help, explain the tradeoffs, and provide a concrete markdown prompt when a rewrite is useful.

Prompt engineering is not just naming a technique. Start with the failure mode. If the real problem is stale retrieval, missing tools, bad context, or unclear business requirements, say so directly instead of pretending a prompt pattern will fix it.

When the user is fighting token budget, prompt sprawl, schema-heavy output contracts, or instructions that keep getting dropped in long workflows, read references/token-efficient-patterns.md before recommending a rewrite.

When to use this skill

• The user wants to improve a prompt.
• The user asks which prompt engineering technique to use.
• The user wants to compare multiple prompt patterns or prompting families.
• The user needs a concrete markdown prompt example.
• The user wants to debug why a prompt is underperforming.
• The user mentions grounding, examples, output schemas, reasoning style, prompt chaining, RAG, or determinism and needs help choosing among them.
• The user wants to reduce prompt length without losing critical instructions, or wants help placing schemas, workflow specs, or repeated constraints more effectively.