down-skilling

# Down-Skilling: Opus → Haiku Distillation

Translate your reasoning capabilities into explicit, structured instructions
that Haiku 4.5 can execute reliably. You are a compiler: your input is
context, intent, and domain knowledge; your output is a Haiku-ready prompt
with decision procedures and diverse examples.

## Core Principle

Opus infers from WHY. Haiku executes from WHAT and HOW.

Your job: convert implicit reasoning, contextual judgment, and domain
expertise into explicit procedures, concrete decision trees, and
demonstrative examples. Every inference you would make silently, Haiku
needs stated explicitly.

## Economics: Why Examples Are Free

Opus input costs ~6× Haiku input. A task that costs $1.00 on Opus costs
~$0.17 on Haiku — but only if Haiku gets it right on the first try.
One retry wipes the savings; two retries makes Haiku more expensive.

**The math that matters:**
- Input tokens are cheap (Haiku: $0.80/MTok input vs $4.00/MTok output)
- Adding 2,000 tokens of examples costs ~$0.0016 per call
- A single failed-then-retried call costs ~$0.008+ in wasted output
- **Examples pay for themselves if they prevent even 1-in-5 retries**

**What this means for prompt design:**
- If you're sending an 8K token document, you can afford 3-4K tokens of
  examples — the examples cost less than the document itself
- Lengthy input prompts don't inflate output costs — output pricing is
  independent of input length
- The constraint is not token cost but diminishing returns: after 5-7
  examples, additional examples rarely improve performance

**Bottom line:** Every example that prevents a Haiku misfire saves 5-25×
its input cost in wasted output tokens. Under-investing in examples is
the most expensive mistake in down-skilling.

## Activation

When triggered, perform these steps:

1. **Extract task context** from the conversation: what is the user trying
   to accomplish? What domain knowledge applies? What quality criteria
   matter?

2. **Identify the reasoning gaps** — what would Opus infer automatically
   that Haiku needs spelled out? Common gaps:
   - Ambiguity resolution (Opus picks the sensible interpretation; Haiku
     needs a decision rule)
   - Quality judgment (Opus knows "good enough"; Haiku needs explicit
     criteria)
   - Edge case handling (Opus reasons through novel situations; Haiku
     needs enumerated cases)
   - Output calibration (Opus matches tone/length intuitively; Haiku
     needs explicit constraints)

3. **Generate the distilled prompt** following the structure in
   [Prompt Architecture](#prompt-architecture)

4. **Generate 4-7 diverse examples** following the principles in
   [Example Design](#example-design) — this is the highest-leverage step

5. **Audit your example set before delivering.** Two checks, both must pass:
   - **Source-anchoring**: for each example output, every concrete fact
     (named technology, number, comparison, quoted phrase) is inferrable
     from that example's input. If you can't reproduce the output knowing
     only the input, either add the detail to the input or remove it from
     the output. Invented facts in examples cause Haiku to copy the
     invention pattern at runtime.
   - **Length calibration**: example output lengths sit inside the stated
     output range. If your rule says "60–90 words" but your examples
     average 35, the rule will not hold — Haiku follows the example
     central tendency.

   If either check fails, regenerate the offending examples before
   delivering. Examples beat rules; misaligned examples beat aligned
   rules.

6. **Deliver** the complete Haiku-ready prompt as a copyable artifact or
   file, including system prompt and user prompt components as appropriate

## Prompt Architecture

Structure every distilled prompt with these components in this order.
Haiku responds best to this specific sequencing:

```
<role>
[Single sentence: who Haiku is and what it does]
</role>

<task>
[2-3 sentences: the specific task, its purpose, and the deliverable]
</task>

<rules>
[Numbered list of explicit constraints. Be precise about:]
- Output format (JSON schema, markdown structure, etc.)
- Length bounds (word/token counts, not vague "brief"/"detailed")
- Required elements (must-include fields or sections)
- Prohibited behaviors (specific failure modes to avoid)
- Decision rules for ambiguous cases
</rules>

<process>
[Numbered steps. Maximum 7 steps. Each step is one action.]
[Include validation checkpoints: "Before proceeding, verify X"]
[Include decision points: "If X, do Y. If Z, do W."]
</process>

<examples>
[4-7 diverse examples showing input → output pairs]
[This section should be the LARGEST part of the prompt]
[See Example Design section for distribution requirements]
</examples>

<context>
[Task-specific data, reference material, or domain knowledge]
[Use labels: [Context], [Policy], [Reference]]
</context>
```

## Haiku Optimization Rules

Apply these when generating any Haiku-targeted prompt:

### Structure & Syntax
- Use XML tags to delimit every section — Haiku respects labeled boundaries
- Keep sentences under 25 words where possible
- One instruction per sentence; split compound instructions
- Use numbered steps, not prose paragraphs, for procedures
- Specify token/word budgets explicitly: "respond in 80-120 words"

### Reasoning Support
- Replace open-ended judgment with decision rubrics:
  BAD: "Assess whether the code is production-ready"
  GOOD: "Check: (a) no TODO comments, (b) all functions have error
  handling, (c) no hardcoded secrets. Score pass/fail per item."
- Bound reasoning depth: "Think in 3-5 steps, then give your answer"
- Provide a fallback for uncertainty: "If you cannot determine X,
  respond with: 'UNCERTAIN: [brief reason]'"

### Context Management
- Front-load critical instructions (Haiku attends strongly to position)
- Budget rule of thumb: instructions + rules ≤ 800 tokens, examples get
  the rest. For a task processing an 8K document, 3-4K tokens of exampl