/down-skilling

name: down-skilling
description: >-
  Distill Opus-level reasoning into optimized instructions for Haiku 5.5
  (and Sonnet). Generates explicit, procedural prompts with n-shot examples
  that maximize smaller model performance on a given task. Use when user says
  "down-skill", "distill for Haiku", "optimize for Haiku", "make this work
  on Haiku", "generate Haiku instructions", or needs to delegate a task to
  a smaller model with high reliability.
metadata:
  author: Oskar Austegard and Opus
  version: 1.7.1

Down-Skilling: Opus → Haiku Distillation

Translate your reasoning capabilities into explicit, structured instructions that Haiku 5.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 5.5 costs 40× Haiku 5.5 on both sides ($4/$20 vs $0.10/$0.50 per MTok for prompts up to 100K tokens; 2026-10 pricing), and Sonnet 5.5 costs 20×. A task that costs $1.00 on Opus costs ~$0.025 on Haiku, so retries no longer erase the saving: Haiku can fail and retry a dozen times and still cost less than one Opus attempt. (At Haiku 4.5's $1/$5 it was 5×, and one retry halved the saving.) What a misfire costs now is mostly *silent* error, a plausible wrong answer no verifier caught, not dollars.

**The math that matters:**

• Input tokens are cheap (Haiku 5.5: $0.10/MTok input vs $0.50/MTok output)
• Adding 2,000 tokens of examples costs ~$0.0002 per call
• Give the orchestrator a verifier and an informed retry (the prior output plus

the check's failure output). On a 2026-10-07 repair battery, Haiku 5.5 rescued every rung-1 miss that way (`agent-routing`)

• What prevents the misfires a verifier cannot see is a test set run before shipping,

not a larger example block (see Start Bare below)

**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:** At 5.5 prices, tokens are no longer the constraint. The expensive mistakes are a judgment rule shipped without the example that calibrates it, and examples standing in for a test set. Both cost you a wrong answer that ships.

Haiku 5.5: Start Bare, Then Add Only What a Miss Asks For

Measured 2026-10-07 on three of this skill's own distilled prompts (feedback extraction, moderation, SQL), each run as shipped, with its `<examples>` stripped, and bare (task, label names and output schema only); two replicates (`oaustegard/experiments` → `downskill-shots`):

| arm | rule-determined items | items an example settles | |---|---|---| | shipped (rules + examples) | 40/40 | 22/24 | | bare (no rules, no examples) | 38/40 | 20/24 | | rules without examples | 40/40 | **15/24** |

Three things follow. Haiku 5.5 does not need examples to apply a rule. Rules written for an example-heavy prompt mislead it once the examples are gone, because it reads them literally: "surface content hostile → flag" flagged a harsh opinion about an article, which the example had shown as APPROVED. And a house convention the model would not guess (spending counts completed orders only) transferred through its example in 1 of 2 runs, so state it as a rule.

**Procedure on Haiku 5.5:**

1. Write the bare prompt: role, task, every valid label, the output schema. 2. Write 10–20 test inputs with expected outputs, at least a third of them at decision boundaries. Run the bare prompt on them. 3. For each miss, add the smallest thing that fixes it:

• an unstated default or house convention ("some" means `LIMIT 10`; spending

counts completed orders) → one explicit rule;

• a judgment boundary (opinion versus harassment, MIXED versus NEGATIVE) → one

example at that boundary, with its `<reasoning>`. Never a judgment rule without the example that calibrates it. 4. Rerun. Stop when the test set passes; typical-case examples add nothing here. 5. For rewriting and summarisation, keep an explicit no-invention rule: without one, 3 of 8 rewrites stated facts the source does not ("We tested it across a range of workloads"). Don't count on a fact-listing step against invention. On 5.5, 0 of 64 rewrites invented a technical detail whether that step was hidden in the process, a visible `<facts>` block, a list supplied in the prompt, or absent (retested 2026-10-08). The anti-invention examples ([model the silence](#when-the-input-could-be-abstract-model-the-silence)) are optional too: the set that drove Haiku 4.5 to 19 of 20 produced 0 of 8 on 5.5. 6. A fact list decides what the rewrite carries over, so choose it on purpose:

• A list Haiku writes itself records the source's claims about itself as facts

("the team describes it as a paradigm shift"), and the rewrite repeats them (8/8). If those should go, say so as a rule.

• A list supplied in the prompt is followed omissions and all: a supplied list

that left out "it is launching" produced 2 of 8 rewrites calling the product "in beta". Supply one only when it has been checked against the source. 7. Don't instruct Haiku 5.5's reasoning ("think in 3-5 steps", "in your reasoning, first list..."). Anthropic's system card measures it near 0% at following instructions about the content of its own thinking (figure 6.4.2.4.A). Put any step whose result you n