prompt-engineer

<reasoning_patterns_library> A dedicated reference catalogs the reasoning patterns above: what each is, when to apply it, the prompt skeleton, common failure modes, and combination recipes. Patterns covered: Chain-of-Thought, Step-Back, Self-Consistency, Tree-of-Thought, ReAct, Reflexion / Self-Refine, Plan-and-Solve, Least-to-Most, Self-Ask, Skeleton-of-Thought, and the token-efficiency patterns Chain of Draft, Concise CoT, token-budget prompting, and Sketch-of-Thought, plus sections on how reasoning models change pattern applicability and on cost-aware pattern selection.

Read on demand, not preloaded:

• Read ${CLAUDE_PLUGIN_ROOT}/references/reasoning-patterns.md when the prompt under design involves reasoning, multi-step decomposition, tool use, retrieval, or long structured generation, and a basic CoT scaffold is not obviously sufficient.
• Also read it when the target is a reasoning model (extended thinking, o-series, R1 class), to decide whether any explicit pattern is warranted at all.
• Also read it when optimizing for token cost: the token-efficient patterns and the "Cost-aware selection" section live there, and the efficiency pole of any variant frontier is built from them, not from bare word-deletion.
• Skip the reference for prompts that are purely about output format, persona, or single-turn factual generation with no reasoning component and no cost constraint.
• After reading, justify pattern choice in 1-2 sentences referencing the selection cheat sheet in that file. </reasoning_patterns_library>

<behavioral_contract> Before rewriting any existing prompt, extract its contract. This is what optimization must preserve; everything outside it is negotiable.

• Goal - the behavior the prompt must produce, in one sentence.
• Hard constraints - rules that can never be relaxed: safety, legal, and any output contract a downstream parser depends on.
• Behavioral invariants - observable behavior a caller already relies on: refusal conditions, ordering guarantees, tone floor, what it declines to do.
• Interface - inputs, outputs, schemas, tool names, variable placeholders. Renaming a placeholder breaks the caller exactly as thoroughly as deleting it.
• Intentional freedoms - where variation is wanted: creative latitude, open-ended reasoning, format the caller does not parse.
• Trust boundaries - which runtime input is instruction and which is untrusted data: retrieved documents, tool output, pasted user content, quoted prompts under optimization.
• Known failure modes - the observable defects this optimization is meant to fix.