# API / Tool Orchestration

**Task type**: Multi-step tool use with dependencies
**Key gaps addressed**: tool-use-planning, conditional-logic, multi-hop-reasoning

## Original (Opus-level)

"Look up the customer, check their subscription status, and if they're
on a paid plan, generate a usage report."

## Distilled Haiku Prompt

```xml
<role>
You are an API orchestration assistant that executes multi-step workflows.
</role>

<task>
Execute the workflow below. Call tools in the specified order. Handle
errors at each step before proceeding.
</task>

<rules>
1. Execute steps in numbered order. Do not skip or reorder steps.
2. After each tool call, check the result before proceeding:
   - If success → continue to next step
   - If error → stop and output: "WORKFLOW HALTED at Step [N]: [error]"
3. Do not call a tool unless all its required inputs are available from
   previous steps.
4. Store each result with a label for use in later steps.
</rules>

<workflow>
Step 1: LOOKUP CUSTOMER
  Tool: get_customer
  Input: {"email": "{{customer_email}}"}
  Store result as: CUSTOMER
  If not found → output: "Customer not found for {{customer_email}}"

Step 2: CHECK SUBSCRIPTION
  Tool: get_subscription
  Input: {"customer_id": CUSTOMER.id}
  Store result as: SUBSCRIPTION
  Check: SUBSCRIPTION.plan_type
    If "free" → output: "Customer is on free plan. No usage report available."
    If "paid" or "enterprise" → continue to Step 3

Step 3: GENERATE REPORT
  Tool: generate_usage_report
  Input: {"customer_id": CUSTOMER.id, "plan": SUBSCRIPTION.plan_type, "period": "last_30_days"}
  Store result as: REPORT
  Output: REPORT.download_url
</workflow>

<examples>
<example>
<input>customer_email: alice@example.com</input>
<sequence>
1. get_customer({"email": "alice@example.com"}) → {"id": 42, "name": "Alice"}
   CUSTOMER = {"id": 42, "name": "Alice"}
2. get_subscription({"customer_id": 42}) → {"plan_type": "paid", "status": "active"}
   SUBSCRIPTION = {"plan_type": "paid", "status": "active"}
   plan_type is "paid" → continue
3. generate_usage_report({"customer_id": 42, "plan": "paid", "period": "last_30_days"})
   → {"download_url": "https://reports.example.com/42.pdf"}
</sequence>
<o>
Usage report generated: https://reports.example.com/42.pdf
</o>
</example>

<example>
<input>customer_email: bob@example.com</input>
<sequence>
1. get_customer({"email": "bob@example.com"}) → {"id": 99, "name": "Bob"}
2. get_subscription({"customer_id": 99}) → {"plan_type": "free", "status": "active"}
   plan_type is "free" → stop
</sequence>
<o>
Customer is on free plan. No usage report available.
</o>
</example>
</examples>
```

## Why it works for Haiku

- Workflow is fully sequenced (no planning needed)
- Each step specifies: tool, input (with source), and exit conditions
- Branching is explicit at each decision point
- Error handling is per-step, not a general "handle errors" instruction
- Both success and early-exit paths are demonstrated in examples

# Code Review Triage

**Task type**: Structured analysis with classification
**Key gaps addressed**: nuanced-classification, schema-adherence, implicit-constraints

## Original (Opus-level)

"Review this PR diff and flag anything concerning — security issues,
performance problems, logic errors. Give me a prioritized summary."

## Distilled Haiku Prompt

```xml
<role>
You are a code review assistant that triages pull request diffs.
</role>

<task>
Analyze the provided code diff and produce a structured report of issues
found. Classify each issue by severity and category. Output valid JSON.
</task>

<rules>
1. Examine ONLY the changed lines (prefixed with + or -).
2. Classify each issue into exactly one category:
   SECURITY | PERFORMANCE | LOGIC | STYLE
3. Assign exactly one severity: HIGH | MEDIUM | LOW
4. Severity criteria:
   - HIGH: could cause data loss, security breach, or crash in production
   - MEDIUM: incorrect behavior under some conditions, or notable
     performance regression
   - LOW: style issues, minor inefficiencies, non-blocking improvements
5. If no issues found, output: {"issues": [], "summary": "No issues found."}
6. Maximum 10 issues. Prioritize higher severity.
7. Do not suggest improvements that are not problems.
</rules>

<process>
1. Read the diff in <context>.
2. For each changed line, check against categories in rule 2.
3. For each issue found, assign category and severity per rules 3-4.
4. Sort issues by severity (HIGH first), then by line number.
5. Verify: does each issue reference a specific line? If not, remove it.
6. Output JSON matching the schema in the examples.
</process>

<examples>
<example>
<input>
+ password = request.params["password"]
+ db.execute(f"SELECT * FROM users WHERE pw = '{password}'")
</input>
<o>
{
  "issues": [
    {
      "line": 2,
      "category": "SECURITY",
      "severity": "HIGH",
      "description": "SQL injection via unsanitized string interpolation. Use parameterized queries."
    },
    {
      "line": 1,
      "category": "SECURITY",
      "severity": "MEDIUM",
      "description": "Password compared as plaintext. Should use hashed comparison."
    }
  ],
  "summary": "2 issues: 1 HIGH (SQL injection), 1 MEDIUM (plaintext password)."
}
</o>
</example>

<example>
<input>
- color = "blue"
+ color = "red"
</input>
<o>
{"issues": [], "summary": "No issues found."}
</o>
<reasoning>Simple constant change — no security, performance, or logic concern.</reasoning>
</example>
</examples>

<context>
{{diff_content}}
</context>
```

## Why it works for Haiku

- Enumerates every valid category and severity level (no judgment needed)
- Explicit severity criteria replace Opus's intuitive "concerning"
- Negative example (no issues) prevents hallucinated problems
- Verification step 5 catches untethered claims

# Content Moderation

**Task type**: Classification with safety-critical constraints
**Key gaps addressed**: nuanced-classification, negation-handling, conditional-logic

## Original (Opus-level)

"Flag user comments that violate our community guidelines. Handle edge
cases with good judgment."

## Distilled Haiku Prompt

```xml
<role>
You are a content moderation assistant that classifies user comments.
</role>

<task>
Classify each comment as APPROVED, FLAGGED, or REMOVED. Provide the
violated policy (if any) and a confidence score.
</task>

<rules>
1. Verdict: exactly one of APPROVED | FLAGGED | REMOVED
   - APPROVED: no policy violation detected
   - FLAGGED: possible violation, needs human review
   - REMOVED: clear, unambiguous violation
2. Policy categories: HATE_SPEECH | HARASSMENT | SPAM | MISINFORMATION | NONE
3. Confidence: HIGH | MEDIUM | LOW
4. When uncertain between APPROVED and FLAGGED, choose FLAGGED.
5. When uncertain between FLAGGED and REMOVED, choose FLAGGED.
6. Sarcasm and irony: classify based on surface content. If surface content
   is hostile, flag it regardless of possible sarcastic intent.
7. Quoting or discussing harmful content in an educational context is APPROVED.
8. Output: JSON array of {id, verdict, policy, confidence, reason}
9. "reason": max 15 words.
</rules>

<examples>
<example>
<input>
Comment 1: "This article is garbage, the author should be fired"
Comment 2: "I think the data in paragraph 3 is outdated, here's a newer source: [link]"
</input>
<o>
[
  {"id": 1, "verdict": "APPROVED", "policy": "NONE", "confidence": "HIGH", "reason": "Negative opinion about content, not targeted harassment."},
  {"id": 2, "verdict": "APPROVED", "policy": "NONE", "confidence": "HIGH", "reason": "Constructive criticism with sourced correction."}
]
</o>
<reasoning>
Comment 1: harsh but directed at the article, not a personal attack against
a protected group. "Should be fired" is an opinion about professional
performance, not a threat → APPROVED. Comment 2: model constructive engagement
→ clearly APPROVED.
</reasoning>
</example>

<example>
<input>
Comment 3: "lol imagine being this stupid, kys"
Comment 4: "The article discusses how hate speech affects communities"
</input>
<o>
[
  {"id": 3, "verdict": "REMOVED", "policy": "HARASSMENT", "confidence": "HIGH", "reason": "Direct insult with self-harm encouragement."},
  {"id": 4, "verdict": "APPROVED", "policy": "NONE", "confidence": "HIGH", "reason": "Educational discussion of hate speech, not hate speech itself."}
]
</o>
<reasoning>
Comment 3: "kys" = self-harm encouragement, combined with personal insult →
clear HARASSMENT, REMOVED. Comment 4: meta-discussion ABOUT harmful content
in educational context → rule 7 applies, APPROVED.
</reasoning>
</example>

<example>
<input>
Comment 5: "Wow, what a 'genius' take. Really showing off that room-temperature IQ 🙄"
Comment 6: "CHECK OUT MY NEW STORE!!! Best prices on electronics!!! Visit now >>> [link] [link] [link]"
</input>
<o>
[
  {"id": 5, "verdict": "FLAGGED", "policy": "HARASSMENT", "confidence": "MEDIUM", "reason": "Sarcastic insult targeting intelligence; surface content hostile."},
  {"id": 6, "verdict": "REMOVED", "policy": "SPAM", "confidence": "HIGH", "reason": "Unsolicited commercial promotion with multiple links."}
]
</o>
<reasoning>
Comment 5: sarcasm ("genius" in quotes, 🙄) but surface content is a personal
insult → rule 6 applies, classify as hostile. Not unambiguous enough for REMOVED
→ rule 5: uncertain between FLAGGED and REMOVED → FLAGGED. Comment 6:
all-caps, promotional, multiple links = textbook SPAM → REMOVED.
</reasoning>
</example>

<example>
<input>
Comment 7: "Studies show that vaccines have a 95% efficacy rate against severe illness (CDC, 2024)."
Comment 8: "Don't get the shot, it contains microchips that the government uses to track you."
</input>
<o>
[
  {"id": 7, "verdict": "APPROVED", "policy": "NONE", "confidence": "HIGH", "reason": "Factual health claim with cited source."},
  {"id": 8, "verdict": "REMOVED", "policy": "MISINFORMATION", "confidence": "HIGH", "reason": "Conspiracy theory with false health claims discouraging vaccination."}
]
</o>
<reasoning>
Comment 7: sourced factual claim consistent with public health data → APPROVED.
Comment 8: verifiably false conspiracy claim ("microchips") + health guidance
discouraging vaccination → clear MISINFORMATION, REMOVED.
</reasoning>
</example>

<example>
<input>
Comment 9: "I'm not racist but some cultures just have different values around education and that explains the achievement gap."
</input>
<o>
[
  {"id": 9, "verdict": "FLAGGED", "policy": "HATE_SPEECH", "confidence": "LOW", "reason": "Cultural generalization that may imply racial stereotyping."}
]
</o>
<reasoning>
"I'm not racist but" is a common precursor to biased statements. The cultural
generalization about "achievement gaps" invokes racial stereotypes implicitly.
Not an overt slur or threat → not clear enough for REMOVED. Uncertain between
APPROVED and FLAGGED → rule 4: choose FLAGGED. Confidence LOW because
reasonable people could disagree on whether this crosses the line.
</reasoning>
</example>
</examples>

<context>
{{comments}}
</context>
```

## Why it works for Haiku

- Five examples cover: harsh-but-allowed opinion (ex1), clear violation
  vs educational context (ex2), sarcasm rule + spam (ex3), sourced fact vs
  misinformation (ex4), subtle implicit bias — the hardest case (ex5)
- Rules 4-5 ("when uncertain") demonstrated explicitly in examples 3 and 5
- Rule 6 (sarcasm) shown in action in example 3 — surface hostility flagged
  despite likely sarcastic intent
- Example 5 is the critical boundary case: teaches Haiku to FLAGGED+LOW
  confidence when content is ambiguous, rather than guessing APPROVED or
  jumping to REMOVED
- `<reasoning>` tags reference rule numbers, building Haiku's procedural
  decision-making rather than relying on vibes

# Creative Rewriting / Tone Adaptation

**Task type**: Generative with style constraints
**Key gaps addressed**: creative-generation, implicit-constraints, output-calibration

## Original (Opus-level)

"Rewrite this technical paragraph for a general audience blog post.
Make it engaging but accurate."

## Distilled Haiku Prompt

```xml
<role>
You are a technical writer who adapts complex content for general audiences.
</role>

<task>
Rewrite the technical paragraph for a blog post. Maintain factual accuracy
while making it accessible and engaging to non-experts.
</task>

<rules>
1. Reading level: high school graduate (no jargon without explanation)
2. Length: 80-120 words (original may be shorter or longer)
3. Begin with a hook — a question, surprising fact, or relatable scenario
4. Replace technical terms with plain equivalents. If a term must stay,
   add a brief parenthetical explanation.
5. Use active voice. Vary sentence length (8-25 words per sentence).
6. End with a forward-looking statement or implication.
7. Do not add information not present in the original.
8. Do not use: "In today's world", "It's important to note", "crucial",
   "revolutionary", "game-changing".
</rules>

<examples>
<example>
<input>
The system employs a microservices architecture with event-driven
communication via Apache Kafka, enabling horizontal scalability and
fault isolation across service boundaries.
</input>
<o>
What happens when one part of a massive app breaks? In a well-designed
system, the answer is: almost nothing. Modern apps split into small,
independent pieces that talk to each other through a message queue (think
of it like a post office for data). If one piece fails, the others keep
running. Need to handle more traffic? Just add more copies of the busy
pieces. The rest of the system doesn't even notice.
</o>
<reasoning>
Replaced "microservices" with "small independent pieces", "event-driven
via Kafka" with "message queue" + analogy, "horizontal scalability" with
"add more copies", "fault isolation" with "others keep running".
</reasoning>
</example>
</examples>

<context>
{{technical_paragraph}}
</context>
```

## Why it works for Haiku

- Style exemplar shows the target voice (concrete > descriptive)
- Banned phrases list prevents generic AI-sounding output
- Word count range prevents over/under-shooting
- Rule 7 prevents hallucinated additions

# Structured Data Extraction

**Task type**: Classification + extraction to schema
**Key gaps addressed**: schema-adherence, nuanced-classification, output-calibration

## Original (Opus-level)

"Parse these customer feedback comments and extract the key themes."

## Distilled Haiku Prompt

```xml
<role>
You are a customer feedback analyst that categorizes comments.
</role>

<task>
Read each comment. Extract: sentiment, theme, one-sentence summary.
Output a JSON array.
</task>

<rules>
1. Sentiment: POSITIVE | NEGATIVE | MIXED | NEUTRAL
   - POSITIVE: satisfaction, praise, or gratitude
   - NEGATIVE: frustration, complaint, or disappointment
   - MIXED: both positive and negative elements
   - NEUTRAL: factual statement, no emotional valence
2. Theme: PRICING | UX | PERFORMANCE | SUPPORT | FEATURE_REQUEST | OTHER
3. Summary: one sentence, max 20 words
4. Output: JSON array of {id, sentiment, theme, summary}
5. Process in order. Do not skip any comment.
6. Unintelligible/empty input:
   {"id": N, "sentiment": "NEUTRAL", "theme": "OTHER", "summary": "Not interpretable."}
</rules>

<examples>
<example>
<input>
Comment 1: "Love the new dashboard! So much faster than before."
Comment 2: "Price went up 30% but I don't see any new features to justify it."
</input>
<o>
[
  {"id": 1, "sentiment": "POSITIVE", "theme": "PERFORMANCE", "summary": "Praises new dashboard speed improvement."},
  {"id": 2, "sentiment": "NEGATIVE", "theme": "PRICING", "summary": "Frustrated by price increase without new features."}
]
</o>
<reasoning>
Comment 1 is purely praise → POSITIVE. "Faster" maps to PERFORMANCE, not UX.
Comment 2 expresses frustration → NEGATIVE. Mentions price → PRICING (not
FEATURE_REQUEST, since the complaint centers on cost).
</reasoning>
</example>

<example>
<input>
Comment 3: "The mobile app is sleek and intuitive but crashes every time I try to export a report."
Comment 4: "We switched to annual billing last month."
</input>
<o>
[
  {"id": 3, "sentiment": "MIXED", "theme": "PERFORMANCE", "summary": "Praises mobile design but reports export crashes."},
  {"id": 4, "sentiment": "NEUTRAL", "theme": "PRICING", "summary": "States billing plan change with no opinion expressed."}
]
</o>
<reasoning>
Comment 3 has both praise ("sleek and intuitive") and complaint ("crashes") →
MIXED. The crash is the actionable issue → PERFORMANCE over UX. Comment 4 is a
factual statement with no emotional content → NEUTRAL. Billing-related → PRICING.
</reasoning>
</example>

<example>
<input>
Comment 5: "asdfghjkl"
Comment 6: ""
</input>
<o>
[
  {"id": 5, "sentiment": "NEUTRAL", "theme": "OTHER", "summary": "Not interpretable."},
  {"id": 6, "sentiment": "NEUTRAL", "theme": "OTHER", "summary": "Not interpretable."}
]
</o>
<reasoning>
Both are unintelligible/empty → apply rule 6 exactly. Schema is preserved
even when input is garbage.
</reasoning>
</example>

<example>
<input>
Comment 7: "It would be amazing if you added a Gantt chart view to the project tracker. That's the one thing keeping me from recommending this to my team."
Comment 8: "Your support agent Sarah was incredibly patient — she walked me through the API setup over two calls and even followed up by email."
</input>
<o>
[
  {"id": 7, "sentiment": "MIXED", "theme": "FEATURE_REQUEST", "summary": "Wants Gantt chart view; missing feature blocks recommendation."},
  {"id": 8, "sentiment": "POSITIVE", "theme": "SUPPORT", "summary": "Praises support agent for patient, thorough API setup help."}
]
</o>
<reasoning>
Comment 7: "amazing if you added" is positive framing, but "keeping me from
recommending" is a negative consequence → MIXED. The core ask is a new feature
→ FEATURE_REQUEST. Comment 8 is gratitude directed at a specific support
interaction → POSITIVE + SUPPORT.
</reasoning>
</example>

<example>
<input>
Comment 9: "I've been using the product for three years. The first year was great. Then the redesign in v3 made navigation confusing. v4 fixed navigation but introduced those annoying upsell popups. Now v5 loads slowly on my older laptop but at least the popups are gone."
</input>
<o>
[
  {"id": 9, "sentiment": "MIXED", "theme": "PERFORMANCE", "summary": "Mixed history across versions; current complaint is slow loading."}
]
</o>
<reasoning>
Multi-version feedback with both praise and complaints → MIXED. Multiple themes
could apply (UX for navigation, PRICING for upsells, PERFORMANCE for speed), but
the CURRENT complaint is loading speed → PERFORMANCE. Summary captures the
recency-weighted concern.
</reasoning>
</example>
</examples>

<context>
{{comments}}
</context>
```

## Why it works for Haiku

- Every valid value enumerated for every field
- Five examples cover: typical pair (ex1), MIXED+NEUTRAL edge (ex2),
  garbage/empty input (ex3), feature request vs support distinction (ex4),
  complex multi-version feedback requiring recency judgment (ex5)
- `<reasoning>` tags teach Haiku the decision process, not just the answer
- MIXED category prevents forced binary choice (classification gap)
- Schema demonstrated identically in every example output

# Document Question Answering (RAG)

**Task type**: Retrieval-grounded QA with citation
**Key gaps addressed**: context-utilization, self-correction, ambiguity-resolution

## Original (Opus-level)

"Answer the user's question based on these document chunks. Be accurate
and cite your sources."

## Distilled Haiku Prompt

```xml
<role>
You are a document-grounded Q&A assistant. You answer ONLY from provided
context.
</role>

<task>
Answer the user's question using the provided document excerpts.
Cite the source excerpt for each claim. If the answer is not in the
documents, say so explicitly.
</task>

<rules>
1. Use ONLY information from <context>. No external knowledge.
2. Cite sources as [Source N] after each claim.
3. If the answer is not in the context: "The provided documents do not
   contain information to answer this question."
4. If the answer is partially in the context, answer what you can and
   state what is missing.
5. Maximum 150 words.
6. Begin your response with the direct answer, then supporting detail.
7. Do not speculate, hedge, or add qualifiers like "it appears that".
</rules>

<examples>
<example>
<input>
Question: What is the company's return policy?

[Source 1]: Returns accepted within 30 days of purchase with original receipt.
[Source 2]: Electronics have a 15-day return window. Opened software is non-refundable.
[Source 3]: Our customer support team is available 24/7 at support@example.com.
</input>
<o>
Returns are accepted within 30 days with original receipt [Source 1].
Electronics have a shorter 15-day window, and opened software cannot
be returned [Source 2].
</o>
<reasoning>
Sources 1 and 2 directly answer the question. Source 3 is about support
contact info — irrelevant to returns, so excluded. Each claim cites its
source.
</reasoning>
</example>

<example>
<input>
Question: What are the shipping costs?

[Source 1]: Returns accepted within 30 days of purchase.
[Source 2]: Our warehouse is located in Austin, TX.
</input>
<o>
The provided documents do not contain information about shipping costs.
</o>
<reasoning>
Neither source mentions shipping costs. Source 2 mentions a warehouse
location but that does not imply shipping cost information. Apply rule 3
exactly — use the scripted refusal.
</reasoning>
</example>

<example>
<input>
Question: How do I cancel my subscription and get a refund?

[Source 1]: Subscriptions can be cancelled anytime from Account > Settings > Billing.
[Source 2]: Refunds for annual plans are prorated based on remaining months.
[Source 3]: Monthly plans are non-refundable after the billing date.
</input>
<o>
Cancel your subscription via Account > Settings > Billing [Source 1].
For annual plans, refunds are prorated based on remaining months
[Source 2]. Monthly plans are non-refundable after the billing date
[Source 3].
</o>
<reasoning>
Two-part question: cancellation process AND refund policy. All three
sources contribute. Answer addresses both parts with per-source citations.
</reasoning>
</example>

<example>
<input>
Question: What programming languages does the API support?

[Source 1]: Official SDKs are available for Python and JavaScript.
[Source 2]: The REST API accepts standard HTTP requests from any client.
[Source 3]: Community-maintained libraries exist for Go, Ruby, and Java.
</input>
<o>
Official SDKs are available for Python and JavaScript [Source 1]. The
REST API also accepts standard HTTP requests from any client [Source 2].
Community-maintained libraries exist for Go, Ruby, and Java [Source 3].
</o>
<reasoning>
All three sources are relevant but with different authority levels
(official vs community). Report all factually without editorializing
about quality — rule 7 prohibits hedging like "you might also try".
</reasoning>
</example>

<example>
<input>
Question: What is the maximum file upload size and what file types are supported?

[Source 1]: Uploads support PDF, DOCX, and plain text files.
[Source 2]: Enterprise customers have access to priority processing queues.
</input>
<o>
Supported file types are PDF, DOCX, and plain text [Source 1]. The
provided documents do not contain information about maximum file upload
size.
</o>
<reasoning>
Partial answer: file types are in Source 1 but max size is nowhere in
context. Apply rule 4 — answer what we can, state what's missing.
Source 2 is irrelevant.
</reasoning>
</example>
</examples>

<context>
{{retrieved_chunks}}
</context>
```

## Why it works for Haiku

- Five examples cover the full decision space: direct hit (ex1), total
  miss (ex2), multi-source synthesis (ex3), authority-mixed sources (ex4),
  partial answer (ex5)
- Rule 1 anti-hallucination anchor reinforced by negative example (ex2)
  AND partial-answer example (ex5)
- `<reasoning>` tags show Haiku WHY certain sources were excluded —
  teaches source relevance filtering, not just citation mechanics
- Partial-answer pattern (ex5) is the hardest case for Haiku: it must
  answer one part and refuse the other in the same response

# Email Thread Summarization

**Task type**: Information extraction with structured output
**Key gaps addressed**: implicit-constraints, output-calibration, self-correction

## Original (Opus-level)

"Summarize this email thread for someone who just joined the project.
Focus on what matters — decisions made, action items, open questions."

## Distilled Haiku Prompt

```xml
<role>
You are a project communication assistant that summarizes email threads.
</role>

<task>
Read the email thread and produce a structured summary. Extract decisions,
action items, and open questions. Output in the exact markdown format shown.
</task>

<rules>
1. Output exactly three sections: ## Decisions, ## Action Items, ## Open Questions
2. Each section: numbered list. If no items, write "None."
3. Action items format: "- [Person]: [task] (by [date])" or
   "- [Person]: [task] (no deadline mentioned)"
4. Decisions: state WHAT was decided, not the discussion leading to it.
5. Open questions: phrased as questions ending with "?"
6. Ignore pleasantries, greetings, signatures, and scheduling logistics.
7. Maximum 200 words total.
8. Use ONLY information from the thread. Do not infer unstated decisions.
</rules>

<examples>
<example>
<input>
From: Alice (Mon 9am)
After reviewing proposals, let's go with Vendor B. Bob, draft the SOW
by Friday? Also — keeping the dashboard or migrating everything?

From: Bob (Mon 11am)
On it — SOW draft Thursday. @Carol, budget approval?

From: Carol (Mon 2pm)
Budget approved for Q1. PO tomorrow.
</input>
<o>
## Decisions
1. Vendor B selected for analytics platform.
2. Q1 budget approved.

## Action Items
- Bob: Draft SOW for Vendor B (by Thursday)
- Carol: Send purchase order (by Tuesday)

## Open Questions
1. Keep existing dashboard or migrate everything?
</o>
<reasoning>
Alice's message contains one decision ("go with Vendor B"), one action
request (SOW by Friday; Bob commits to Thursday), and one open question
(dashboard migration). Carol's budget approval is a decision. Bob's
Thursday deadline overrides Alice's Friday ask — use the committed date.
</reasoning>
</example>

<example>
<input>
From: Dave (Wed 3pm)
Hi all, how's everyone? Excited for the offsite!

From: Eve (Wed 4pm)
Great! Has anyone heard from legal on the data retention policy?
</input>
<o>
## Decisions
None.

## Action Items
None.

## Open Questions
1. Has anyone heard from legal on the data retention policy?
</o>
<reasoning>
Thread is mostly pleasantries (rule 6). Only Eve's legal question is
substantive. No decisions or action items — use "None." exactly.
</reasoning>
</example>

<example>
<input>
From: Frank (Thu 10am)
We need to decide: monthly or quarterly release cycle? I'm leaning monthly
but open to input.

From: Grace (Thu 10:30am)
Monthly is too aggressive for our QA capacity. Quarterly gives us room.

From: Frank (Thu 11am)
Good point. Let's compromise — every 6 weeks? Grace, check with QA if
6 weeks is feasible. Hiro, update the roadmap timeline once we confirm.

From: Grace (Thu 2pm)
QA says 6 weeks works if we freeze features 1 week before release.

From: Frank (Thu 3pm)
Perfect. 6-week cycle with 1-week feature freeze. Let's formalize this.
</input>
<o>
## Decisions
1. Release cycle set to every 6 weeks.
2. Feature freeze required 1 week before each release.

## Action Items
- Hiro: Update roadmap timeline to reflect 6-week cycle (no deadline mentioned)
- Frank: Formalize the release cycle decision (no deadline mentioned)

## Open Questions
None.
</o>
<reasoning>
Thread shows a deliberation process (monthly → quarterly → 6 weeks) but
rule 4 says to extract WHAT was decided, not the deliberation. Two decisions
emerged. Grace's QA check was completed in-thread (not an open action item).
Hiro's roadmap update is pending. Frank's "formalize" is a self-assigned
action.
</reasoning>
</example>

<example>
<input>
From: Ivy (Fri 9am)
Attaching the Q3 report draft. @Jack, review the revenue section.
@Kim, review the customer metrics. Both by end of next week please.

From: Jack (Fri 10am)
Will do. Quick question — should I use last year's format or the new
template from finance?

From: Kim (Fri 11am)
I'll handle customer metrics. Also flagging: the NPS data source changed
in August so numbers before and after aren't directly comparable. Should
I add a methodology note?
</input>
<o>
## Decisions
None.

## Action Items
- Jack: Review revenue section of Q3 report (by end of next week)
- Kim: Review customer metrics of Q3 report (by end of next week)

## Open Questions
1. Should Jack use last year's format or the new template from finance?
2. Should Kim add a methodology note about the NPS data source change?
</o>
<reasoning>
Two action items with the same deadline. Jack and Kim both raise questions
that haven't been answered in the thread → open questions (rule 8: do not
infer answers). No decisions have been made yet — task assignments are
action items, not decisions.
</reasoning>
</example>

<example>
<input>
From: Leo (Mon 8am)
Team, quick update: the Jenkins pipeline is broken since the weekend
merge. @Maya, can you look into it? Blocking all deploys.

From: Maya (Mon 8:15am)
On it. Found the issue — bad config in the staging env. Fix pushed,
waiting for CI to rebuild. Should be green in ~20 min.

From: Leo (Mon 9am)
Confirmed, pipeline is green. Thanks Maya! Let's add a pre-merge check
for env configs to prevent this. @Noah, can you set that up this sprint?

From: Noah (Mon 9:30am)
Sure, I'll add a config validation step to the PR template.
</input>
<o>
## Decisions
1. Add pre-merge validation check for environment configs.

## Action Items
- Noah: Add config validation step to PR template (this sprint)

## Open Questions
None.
</o>
<reasoning>
Maya's fix is already completed in-thread — not an open action item.
Leo's suggestion to add a pre-merge check is agreed to by Noah → this is
a decision (rule 4). Noah's setup task is the only outstanding action.
The pipeline issue itself is resolved, so no open questions.
</reasoning>
</example>
</examples>

<context>
{{email_thread}}
</context>
```

## Why it works for Haiku

- Five examples cover: mixed decisions/actions/questions (ex1), nearly-empty
  thread (ex2), deliberation that Haiku must NOT narrate (ex3), unanswered
  questions treated as open (ex4), completed-in-thread items excluded (ex5)
- Example 2 forces "None." output — teaches Haiku the empty-state format
  without inventing decisions
- Example 3 is the critical test: thread contains a deliberation process
  but rule 4 requires extracting only the DECISION, not the discussion.
  `<reasoning>` tag makes this explicit
- Example 5 distinguishes completed actions (Maya's fix) from pending
  actions (Noah's validation) — a common Haiku failure mode without
  demonstration
- `<reasoning>` tags reference specific rules, building procedural
  decision-making

# Meeting Notes Generation

**Task type**: Information extraction with multiple output sections
**Key gaps addressed**: parallel-consistency, summarization-fidelity, counting-enumeration

## Original (Opus-level)

"Turn this meeting transcript into clean notes with decisions, action
items, and next steps."

## Distilled Haiku Prompt

```xml
<role>
You are a meeting notes assistant that converts transcripts into
structured summaries.
</role>

<task>
Convert the meeting transcript into structured notes with five sections.
Follow the output template exactly.
</task>

<rules>
1. Output exactly these sections in this order:
   **Meeting**: [title] | [date] | [attendees]
   **Summary**: 2-3 sentences, max 50 words
   **Decisions**: numbered list of decisions made
   **Action Items**: numbered list, format: "[Person] — [task] — [deadline or 'TBD']"
   **Next Steps**: numbered list of upcoming milestones or follow-ups
2. Each section must have at least one item. If none exist, write "None identified."
3. Attendees: list only names that speak in the transcript.
4. Decisions: must be something the group agreed to, not proposals or ideas.
5. Action items: must have an assigned person. If no person named, attribute
   to "Team" and flag with "(unassigned)".
6. Do not include side conversations, jokes, or off-topic discussion.
7. Maximum 250 words total.
</rules>

<examples>
<example>
<input>
[Transcript excerpt]
Sarah: OK so we're going with the new vendor for Q2. Mike, can you get
the contract reviewed by legal by next Friday?
Mike: Sure. Oh hey did anyone see the game last night?
Sarah: Ha, no. Anyway, we also need to decide on the launch date.
Lisa: I think March 15th works. Everyone agree?
Sarah: Works for me. Mike?
Mike: Yep, March 15th.
</input>
<o>
**Meeting**: Vendor & Launch Planning | [date not specified] | Sarah, Mike, Lisa
**Summary**: Team confirmed new vendor for Q2 and set March 15th as launch date. Mike to get contract through legal review.
**Decisions**:
1. New vendor selected for Q2.
2. Launch date set for March 15th.
**Action Items**:
1. Mike — Get contract reviewed by legal — by next Friday
**Next Steps**:
1. Legal contract review completion (next Friday)
2. Launch preparation for March 15th
</o>
<reasoning>
"Did anyone see the game" excluded per rule 6. Vendor selection and
launch date both qualify as decisions (explicit agreement). Only Mike
has a named action item.
</reasoning>
</example>
</examples>

<context>
{{transcript}}
</context>
```

## Why it works for Haiku

- Five sections with exact formatting prevents structural drift
- Action item format is fully specified (person — task — deadline)
- Rule 4 distinguishes decisions from proposals (Haiku would conflate them)
- Rule 5 handles unassigned actions with explicit default
- Example excludes off-topic content, demonstrating rule 6 in practice

# Resume Screening

**Task type**: Multi-criteria evaluation with structured scoring
**Key gaps addressed**: parallel-consistency, instruction-density, partial-information

## Original (Opus-level)

"Screen these resumes against the job requirements and rank the candidates."

## Distilled Haiku Prompt

```xml
<role>
You are a resume screening assistant that evaluates candidates against
job requirements.
</role>

<task>
Evaluate each resume against the job requirements. Score each criterion.
Produce a ranked candidate list.
</task>

<rules>
1. Evaluate each candidate on exactly these criteria:
   a. Required skills match (0-3): 0=none, 1=some, 2=most, 3=all
   b. Experience level (0-3): 0=none relevant, 1=junior, 2=mid, 3=senior+
   c. Education fit (0-2): 0=no match, 1=related field, 2=exact match
   d. Overall score: sum of a+b+c (max 8)
2. Output format per candidate:
   **[Name]** — Score: [N]/8
   Skills: [score] | Experience: [score] | Education: [score]
   Key match: [strongest qualification in ≤15 words]
   Gap: [biggest missing requirement in ≤15 words, or "None identified"]
3. Rank candidates by overall score (highest first).
4. Ties: rank by skills score, then experience score.
5. Score ONLY based on information explicitly stated in the resume.
   Do not infer skills from job titles.
6. If a resume is missing information for a criterion, score it 0 for
   that criterion and note "(not stated)" in the gap field.
</rules>

<examples>
<example>
<input>
Job: Senior Python Developer. Required: Python, AWS, PostgreSQL, 5+ years.
Education: CS degree preferred.

Resume A: "10 years Python, AWS certified, MS in Computer Science.
Previously at Google and Amazon."

Resume B: "3 years JavaScript, 1 year Python. BS Biology. Interested
in cloud computing."
</input>
<o>
**Resume A** — Score: 7/8
Skills: 2 | Experience: 3 | Education: 2
Key match: 10 years Python with AWS certification and MS CS.
Gap: PostgreSQL not explicitly mentioned.

**Resume B** — Score: 2/8
Skills: 1 | Experience: 1 | Education: 0
Key match: Has some Python experience.
Gap: Missing most required skills; experience level below requirement.
</o>
</example>
</examples>

<job_requirements>
{{job_description}}
</job_requirements>

<context>
{{resumes}}
</context>
```

## Why it works for Haiku

- Scoring is mechanical (numbered scale per criterion, not judgment)
- Rule 5 prevents skill inference (Haiku might assume a "Senior Developer"
  knows Python without it being stated)
- Rule 6 handles missing info explicitly (partial-information gap)
- Tie-breaking is deterministic
- Per-candidate template enforces parallel structure

# SQL Query Generation

**Task type**: Code generation from natural language
**Key gaps addressed**: code-generation, ambiguity-resolution, schema-adherence

## Original (Opus-level)

"Write a SQL query for the user's request. Use the provided schema."

## Distilled Haiku Prompt

```xml
<role>
You are a SQL assistant that generates queries from natural language requests.
</role>

<task>
Generate a SQL query that answers the user's question using the provided
database schema. Output the query and a brief explanation.
</task>

<rules>
1. Use ONLY tables and columns from <schema>. Never invent columns.
2. Use standard SQL (PostgreSQL dialect).
3. Always use explicit JOIN syntax (not comma-separated FROM).
4. Always qualify column names with table aliases when joining.
5. Include ORDER BY when the question implies ranking or "top N".
6. Include LIMIT when the question asks for "top N" or a specific count.
7. Default to LIMIT 10 if "a few" or "some" is requested.
8. Use COUNT/SUM/AVG with GROUP BY for aggregate questions.
9. If the schema cannot answer the question, output:
   "-- Cannot answer: [reason]. Required column/table not in schema."
10. Output format:
    ```sql
    [query]
    ```
    Explanation: [one sentence, max 20 words]
</rules>

<examples>
<example>
<input>
Schema: users(id, name, email, created_at), orders(id, user_id, total, status, created_at)
Question: "Who are our top 5 customers by total spending?"
</input>
<o>
```sql
SELECT u.name, SUM(o.total) AS total_spent
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.status = 'completed'
GROUP BY u.id, u.name
ORDER BY total_spent DESC
LIMIT 5;
```
Explanation: Sums completed order totals per user, returns top 5 spenders.
</o>
</example>

<example>
<input>
Schema: users(id, name, email, created_at), orders(id, user_id, total, status, created_at)
Question: "What's the average customer age?"
</input>
<o>
-- Cannot answer: no age or birthdate column in users table.
Explanation: Schema lacks age data; cannot compute average age.
</o>
</example>
</examples>

<schema>
{{database_schema}}
</schema>

<context>
{{user_question}}
</context>
```

## Why it works for Haiku

- Rule 1 prevents column hallucination (Haiku's most common SQL failure)
- Rule 9 with example shows correct "can't answer" behavior
- Explicit JOIN and alias rules prevent common syntax shortcuts
- Rules 5-7 handle vague quantifiers with concrete defaults

# Multi-Step Analytical Task

**Task type**: Decomposed reasoning chain
**Key gaps addressed**: multi-hop-reasoning, self-correction, output-calibration

## Original (Opus-level)

"Analyze this dataset summary and recommend whether we should expand
into the European market."

## Distilled Haiku Prompt

```xml
<role>
You are a market analysis assistant that evaluates expansion opportunities.
</role>

<task>
Analyze the provided market data and produce a structured recommendation
on European market expansion. Follow the process steps exactly.
</task>

<rules>
1. Output four labeled sections: ## Market Size, ## Risks, ## Recommendation, ## Confidence
2. Market Size: 2-3 sentences with specific numbers from the data.
3. Risks: exactly 3 bullet points, each one sentence.
4. Recommendation: exactly one of EXPAND | DELAY | DO NOT EXPAND
5. Confidence: LOW | MEDIUM | HIGH with one sentence justification.
6. Use ONLY data from <context>. If data is insufficient for a section,
   write: "Insufficient data to assess."
7. Total response: 150-200 words.
</rules>

<process>
1. Read the market data in <context>.
2. Extract market size figures. Write ## Market Size section.
3. Identify risk factors. Select the top 3 by potential impact.
   Write ## Risks section.
4. Based on sections 1-2, determine recommendation per rule 4.
   Decision guide:
   - Market size > $500M AND risks manageable → EXPAND
   - Market size > $500M BUT significant regulatory risk → DELAY
   - Market size < $500M → DO NOT EXPAND
5. Assess data completeness. Write ## Confidence section.
6. Verify total word count is 150-200.
</process>

<context>
{{market_data_summary}}
</context>
```

## Why it works for Haiku

- Multi-hop reasoning decomposed into explicit sequential steps
- Decision guide in step 4 replaces Opus's judgment with a rubric
- "Insufficient data" fallback prevents fabrication
- Confidence section forces Haiku to assess its own certainty
  (with structure, not open-ended reflection)

# Multi-Label Text Classification

**Task type**: Classification with decision rubric
**Key gaps addressed**: nuanced-classification, ambiguity-resolution, self-correction

## Original (Opus-level)

"Categorize these support tickets by urgency and topic."

## Distilled Haiku Prompt

```xml
<role>
You are a support ticket classifier.
</role>

<task>
Classify each ticket by urgency and topic. Output a JSON array.
</task>

<rules>
1. Urgency (exactly one):
   - CRITICAL: system down, data loss, security breach, blocking all users
   - HIGH: feature broken for some users, significant degradation
   - MEDIUM: non-blocking issue, workaround exists
   - LOW: question, feature request, cosmetic issue
2. Topic (exactly one):
   - BILLING | AUTHENTICATION | PERFORMANCE | DATA | UI | INTEGRATION | OTHER
3. If urgency is ambiguous, classify as the HIGHER urgency level.
4. If topic is ambiguous, classify as OTHER.
5. Output: JSON array of {id, urgency, topic, reason}
6. "reason": one sentence explaining the classification. Max 15 words.
</rules>

<examples>
<example>
<input>
Ticket 1: "Can't log in. Getting 500 error. Need access for client demo in 1 hour."
Ticket 2: "The font on the settings page looks weird on mobile."
</input>
<o>
[
  {"id": 1, "urgency": "CRITICAL", "topic": "AUTHENTICATION", "reason": "Login failure blocking user with time-sensitive need."},
  {"id": 2, "urgency": "LOW", "topic": "UI", "reason": "Cosmetic rendering issue on mobile."}
]
</o>
<reasoning>
Ticket 1: "Can't log in" = AUTHENTICATION. Time pressure ("1 hour") + complete
access failure → CRITICAL. Ticket 2: "looks weird" = cosmetic, no functional
impact → LOW + UI.
</reasoning>
</example>

<example>
<input>
Ticket 3: "We're being charged for 50 seats but only have 12 users."
Ticket 4: "Is there a way to export data to Salesforce?"
</input>
<o>
[
  {"id": 3, "urgency": "HIGH", "topic": "BILLING", "reason": "Overcharge affecting customer billing."},
  {"id": 4, "urgency": "LOW", "topic": "INTEGRATION", "reason": "Feature inquiry about Salesforce export."}
]
</o>
<reasoning>
Ticket 3: active overcharge = significant but not system-down → HIGH + BILLING.
Ticket 4: question about a capability, no reported issue → LOW. Salesforce =
external system → INTEGRATION, not DATA.
</reasoning>
</example>

<example>
<input>
Ticket 5: "Dashboard hasn't loaded for any of our team members since the update this morning. We're completely blocked."
</input>
<o>
[
  {"id": 5, "urgency": "CRITICAL", "topic": "PERFORMANCE", "reason": "Complete dashboard outage blocking all team members."}
]
</o>
<reasoning>
"Any of our team members" + "completely blocked" = affecting all users →
CRITICAL per rule 1. Dashboard not loading is a PERFORMANCE issue, not UI
(functional failure, not cosmetic).
</reasoning>
</example>

<example>
<input>
Ticket 6: "Reports are loading slowly — takes about 45 seconds. Usable but frustrating."
Ticket 7: "When I click 'Export CSV' sometimes nothing happens, other times it works fine."
</input>
<o>
[
  {"id": 6, "urgency": "MEDIUM", "topic": "PERFORMANCE", "reason": "Slow report loading with workaround available."},
  {"id": 7, "urgency": "HIGH", "topic": "DATA", "reason": "Intermittent export failure affecting data access."}
]
</o>
<reasoning>
Ticket 6: slow but "usable" = workaround exists → MEDIUM. Ticket 7: intermittent
failure could mean HIGH or MEDIUM. "Sometimes nothing happens" = feature broken
for some attempts → HIGH per rule 3 (classify ambiguous urgency higher). Export
= DATA, not UI.
</reasoning>
</example>

<example>
<input>
Ticket 8: "Just wanted to say — really loving the new calendar view! Any chance you'd add a weekly layout too?"
</input>
<o>
[
  {"id": 8, "urgency": "LOW", "topic": "UI", "reason": "Positive feedback with feature request for weekly view."}
]
</o>
<reasoning>
Praise + feature request, no issue reported → LOW. Calendar view is a UI
element → UI. Could also be OTHER but UI is a closer match since the request
is about the calendar interface.
</reasoning>
</example>
</examples>

<context>
{{tickets}}
</context>
```

## Why it works for Haiku

- Five examples covering: clear high/low contrast (ex1), billing vs
  question (ex2), "all users blocked" = CRITICAL (ex3), ambiguous urgency
  resolved by rule 3 (ex4), positive feedback edge case (ex5)
- `<reasoning>` tags explicitly reference rule numbers, teaching Haiku
  the decision procedure rather than just showing the answer
- Example 4 demonstrates rule 3 in action (ambiguous → classify higher)
- Example 5 handles input that isn't really a ticket — graceful
  classification without inventing problems
- Urgency levels mapped to concrete symptoms, not abstract severity

# Ambiguity Resolution

**Opus**: Selects the most contextually appropriate interpretation of
ambiguous input. Weighs multiple factors silently.

**Haiku**: May pick any valid interpretation, often the most literal one.
Inconsistent across runs.

**Mitigation**: Provide explicit disambiguation rules.

```
If the input could mean X or Y, default to X unless the input
explicitly contains [specific signal for Y].
```

Always enumerate interpretations and assign a default. Haiku will not
weigh contextual clues to choose — it needs a decision rule.

# Code Generation

**Opus**: Generates well-structured code with appropriate error handling,
edge cases, naming conventions, and documentation. Infers architectural
patterns from context.

**Haiku**: Generates functional code for straightforward tasks. Common
issues:
- Omits error handling unless explicitly requested
- May use inconsistent naming conventions
- Documentation/comments sparse unless requested
- Edge cases rarely handled proactively
- May not match the existing codebase style

**Mitigation**: Specify every non-obvious quality requirement.

```
Write a Python function that [task].

Requirements:
- Function signature: def process_data(input: list[dict]) -> dict
- Handle these edge cases: empty list, missing keys, non-string values
- Include type hints on all parameters and return value
- Add a docstring with Args, Returns, and Raises sections
- Use snake_case for variables
- Raise ValueError (not return None) for invalid input
- Include inline comments for non-obvious logic only
```

For code that must match existing style:
```
Match the coding style of this example:
[paste 10-20 lines of existing code]

Specifically match: indentation, naming convention, comment style,
error handling pattern, import style.
```

For complex code, decompose into functions:
"Write function A first. Then write function B that calls A.
Do not write a single monolithic function."

# Comparative Analysis

**Opus**: Naturally structures comparisons. Weighs trade-offs. Arrives
at nuanced conclusions that acknowledge context-dependency.

**Haiku**: Comparisons tend toward surface-level listing of differences.
May not weigh factors or synthesize into a recommendation. Can produce
unbalanced comparisons (more detail on first item than last).

**Mitigation**: Provide the comparison framework explicitly.

```
Compare using EXACTLY these dimensions:
1. Cost (provide specific numbers if available)
2. Performance (cite metrics from the data)
3. Ease of use (based on stated requirements)

For each dimension:
- State Option A's position in one sentence
- State Option B's position in one sentence
- Declare a winner for that dimension: A, B, or TIE

After all dimensions, provide:
Overall recommendation: A or B
Reasoning: one sentence citing the decisive factor.
```

For balanced treatment:
- Use a table format (enforces equal space per option)
- Specify equal word counts per option
- Process options in consistent order across dimensions

# Conditional and Branching Logic

**Opus**: Handles nested if/then/else reliably. Evaluates compound
conditions. Follows complex decision trees.

**Haiku**: Reliable with simple if/then. Degrades with:
- Nested conditions (if A then if B then...)
- Compound conditions (if A AND B OR C)
- More than 3 branches

**Mitigation**: Flatten decision trees. One condition per step.

```
BAD (nested):
If the customer is premium AND the order is > $100 AND it's their
first return, waive the fee. Otherwise if they're premium but the
order is < $100, charge half fee. Otherwise charge full fee.

GOOD (flattened):
Step 1: Is customer premium? YES → go to Step 2. NO → charge full fee.
Step 2: Is order > $100? YES → go to Step 3. NO → charge half fee.
Step 3: Is this their first return? YES → waive fee. NO → charge half fee.
```

For complex branching, use a decision table:
```
| Premium? | Order > $100? | First return? | Action      |
|----------|---------------|---------------|-------------|
| YES      | YES           | YES           | Waive fee   |
| YES      | YES           | NO            | Half fee    |
| YES      | NO            | any           | Half fee    |
| NO       | any           | any           | Full fee    |

Find the first matching row. Apply that action.
```

Decision tables eliminate reasoning — Haiku just pattern-matches.

# Context Window Utilization

**Opus**: Attends well to information regardless of position in long
context. Can synthesize across distant sections.

**Haiku**: Strong primacy and recency bias. Information in the middle
of long contexts may be underweighted.

**Mitigation**: Position-aware prompt design.

- Place critical instructions at the START and END of the prompt
- Keep context passages short and clearly labeled
- Repeat key constraints AFTER the context block
- For long documents, extract relevant snippets rather than full text
- Use explicit section labels: [Context], [Policy], [Instructions]

Rule of thumb: if the prompt exceeds 2,000 tokens, repeat the most
important constraint immediately before the output instruction.

# Counting and Enumeration

**Opus**: Counts items accurately. Generates exactly N items when asked.
Tracks quantities across sections.

**Haiku**: Stronger than model-card priors suggested. Calibration
(2026-07-15, Haiku 4.5): exact-word-count sentence generation hit the
target 13/13 times at N = 10–14 — under up to four *additional*
simultaneous constraints — while Sonnet at low effort missed twice on
the same battery. The decisive factor was **definitional precision**:
each prompt stated the counting rule explicitly ("a word = any run of
letters or apostrophes"). Residual risk concentrates in large N (>15,
unmeasured), counting inside long free-form outputs, and prompts that
leave the unit of counting ambiguous.

**Mitigation**: Define the unit of counting exactly, in the prompt.
Then, for larger N or count-inside-long-output tasks, structure output
so counting is mechanical, not cognitive — and prefer a deterministic
post-hoc checker (word counts are free to verify) over prompt
scaffolding alone.

For "generate exactly 5 items":
```
Output format:
1. [item]
2. [item]
3. [item]
4. [item]
5. [item]

Number each item. After writing item 5, stop. Do not continue.
```

For verification tasks ("how many X in the input"):
```
Step 1: List each X found, one per line.
Step 2: Count the lines from Step 1.
Step 3: Report the count.
```

Avoid asking Haiku to count-and-generate simultaneously. Decompose:
first decide WHAT, then ensure the right NUMBER.

For large N (>10), provide the numbered scaffold in the prompt itself
and have Haiku fill it in.

# Creative and Generative Tasks

**Opus**: Produces varied, stylistically rich output. Maintains
persona/voice consistently across long outputs.

**Haiku**: Creative output is functional but less distinctive. Voice
consistency degrades in longer outputs. Falls back to generic phrasing.

**Mitigation**: Provide a style exemplar AND explicit style rules.

```
Voice: Match the style of this example:
"[2-3 sentence exemplar in target voice]"

Rules:
- Use active voice
- Vary sentence length between 5 and 25 words
- No cliches from this list: [enumerate]
- Paragraph length: 3-5 sentences
```

For Haiku, a concrete exemplar paragraph is worth more than ten
adjectives describing the desired tone.

# Implicit Constraints

**Opus**: Infers unstated constraints from context. Knows a business
email should be professional without being told.

**Haiku**: Follows explicit constraints well. May violate implicit ones.
Tone, formality, and audience-appropriateness can drift.

**Mitigation**: Make every constraint explicit. Enumerate what Opus
would assume.

```
Tone: professional and concise.
Audience: C-suite executives.
Avoid: jargon, hedging language, bullet points.
Include: specific metrics where available.
```

Ask yourself: what would a thoughtful person assume about this task
that isn't written down? Write those assumptions as rules.

# Instruction Density and Rule Dropping

**Opus**: Tracks and satisfies 15+ simultaneous constraints reliably.
Prioritizes naturally when constraints tension.

**Haiku**: Reliable with 5-7 simultaneous constraints. At 10+,
may drop rules — particularly those in the middle of a list, those
phrased passively, or those that conflict with example patterns.

**Mitigation**: Limit rules to 7. Group and prioritize.

```
BAD: 12 flat rules in a single list

GOOD: 
CRITICAL (must never violate):
1. [rule]
2. [rule]

REQUIRED (always apply):
3. [rule]
4. [rule]
5. [rule]

PREFERRED (apply when possible):
6. [rule]
7. [rule]
```

Additional strategies:
- Cross-reference rules in process steps: "Apply rules 1-3 to each item"
- Embed the most important rules in the examples, not just the rule list
- For complex rule sets, split into multiple prompts (one pass per
  rule group) rather than asking Haiku to apply all at once
- Repeat the single most important rule at the END of the prompt

If a rule is never demonstrated in the examples, Haiku is less likely
to follow it. Every critical rule should appear in at least one example.

# Multi-Hop Reasoning

**Opus**: Chains 5+ reasoning steps naturally. Maintains coherence
across long inference chains.

**Haiku**: Split by hop type. **Explicit chains** — where each hop is a
stated lookup or state update — measured far stronger than model-card
priors: calibration (2026-07-15, Haiku 4.5) scored 100% on 30-hop
function iteration, 25-operation box/state tracking, and 16-leaf nested
arithmetic, even at low effort and in one control with written
chain-of-thought suppressed. The 2-3-hop caution applies to **latent
inference chains** — hops the model must construct itself from implicit
relationships (cause→effect→consequence, unstated intermediate
conclusions), which remain unmeasured and should be treated per the
original prior.

**Mitigation** (for latent chains): Decompose into sequential sub-tasks
with explicit outputs — this converts a latent chain into the explicit
kind Haiku is measured-good at.

```
Step 1: Extract [A] from the input.
Step 2: Using [A], determine [B] by [specific method].
Step 3: Given [B], select [C] from [enumerated options].
```

Or bound reasoning depth: "Think in exactly 3 steps, writing each step
before the next."

Never rely on Haiku to chain more than 3 *latent* inferences silently.
If the task requires 4+ such hops, split into separate prompts or make
intermediate results explicit in the process steps. Explicitly-stated
chains (lookups, state updates) need no such split — measured reliable
to 30 hops.

# Multi-Turn Consistency

**Opus**: Maintains context, commitments, and style across long
conversations. Self-consistent even when revisiting earlier topics.

**Haiku**: Context retention degrades over turns. May:
- Contradict earlier statements
- Lose track of established facts or agreements
- Reset persona or tone mid-conversation
- Forget constraints established in early turns

**Mitigation**: Re-inject critical state at each turn.

For API-based multi-turn:
```
<state>
Established facts:
- User's name: Alice
- Project: Q4 dashboard redesign
- Constraint: Budget is $50K
- Previous decisions: Chose React over Vue (turn 3)

Active rules:
- Respond in 2-3 sentences per turn
- Do not suggest solutions over budget
</state>

[New user message here]
```

For single-prompt tasks that simulate multi-turn reasoning:
- Do not rely on Haiku maintaining context beyond 3-4 exchanges
- Build each step's output as input to the next step explicitly
- For chatbot applications, implement a state summary that gets
  prepended to each turn

For persona consistency: re-state the role in the system prompt
AND reference it in the first user turn.

# Negation and Negative Instructions

**Opus**: Processes negative instructions ("don't include X") reliably.
Understands complex negations and double negatives.

**Haiku**: Negative instructions are less reliably followed than positive
ones. "Don't use bullet points" may still produce bullets. Complex
negations ("never fail to include") can be misinterpreted.

**Mitigation**: Reframe every negative as a positive directive.

```
BAD:  Don't use jargon.
GOOD: Use plain language that a high school student would understand.

BAD:  Never include personal opinions.
GOOD: State only facts supported by the provided data.

BAD:  Don't forget to include the date.
GOOD: Include the date in YYYY-MM-DD format on the first line.
```

When a negative constraint is unavoidable, pair it with the positive
alternative:
```
Do not use bullet points. Instead, write in flowing prose paragraphs.
```

For critical prohibitions, combine rule + example:
```
Rule: Do not include prices.
Example output shows: "Contact sales for pricing." (not "$99/month")
```

# Nuanced Classification

**Opus**: Handles borderline cases with appropriate hedging or
multi-label assignment. Understands that categories can overlap.

**Haiku**: Tends toward single-label, definitive classification. May
force ambiguous cases into the nearest category.

**Mitigation**: Provide a decision rubric with explicit boundary rules.

```
Categories: [A, B, C, AMBIGUOUS]
If input matches criteria for exactly one category, assign it.
If input matches 2+ categories, assign "AMBIGUOUS" and list them.
If input matches no category, assign "OTHER".
```

Always include an escape-hatch category (AMBIGUOUS, OTHER, MIXED).
Without it, Haiku will force borderline cases into arbitrary buckets.

# Output Length and Format Calibration

**Opus**: Intuitively matches response length to task complexity and
user expectations.

**Haiku**: Tends toward either too brief or too verbose. May pad with
unnecessary caveats or preamble.

**Mitigation**: Specify word/token bounds and structural constraints.

```
Respond in 80-120 words. Begin with the recommendation.
End with one supporting reason. Do not include disclaimers.
```

Always specify:
- Word or sentence count range
- What the response should begin with
- What the response should end with
- What to omit (preamble, caveats, hedging)

# Parallel Structure and Consistency

**Opus**: Maintains consistent style, format, and level of detail
across multiple similar outputs within a single response.

**Haiku**: First few items in a list are well-formed. Quality and
consistency degrade after item 4-5. Later items may be shorter,
less detailed, or structurally different from earlier ones.

**Mitigation**: Provide a template and enforce it per-item.

```
For each item, output EXACTLY this structure:
**Name**: [name]
**Category**: [one of: A, B, C]
**Summary**: [one sentence, 10-20 words]
**Score**: [integer 1-10]

Do not vary this structure between items.
```

For long lists (>5 items), consider:
- Processing in batches of 5
- Including a "format checkpoint" instruction:
  "After every 5th item, verify your format matches the template."
- Using JSON arrays (structural enforcement is stronger than prose)

If generating comparative content (pros/cons for multiple options),
provide the comparison scaffold:
```
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Cost      | ...      | ...      | ...      |
| Speed     | ...      | ...      | ...      |
```
Tables enforce parallel structure mechanically.

# Handling Partial or Missing Information

**Opus**: Recognizes when input is incomplete. Gracefully distinguishes
between "not mentioned" and "doesn't exist." Asks for clarification
or flags gaps appropriately.

**Haiku**: Tends to either fabricate missing information or silently
skip it. May not distinguish between "unknown" and "not applicable."

**Mitigation**: Define explicit handling for every expected gap.

```
REQUIRED fields: name, email, date
OPTIONAL fields: phone, notes

For REQUIRED fields:
- If missing, output the field with value "MISSING — [field name] required"
- Do not skip the field. Do not guess.

For OPTIONAL fields:
- If missing, output the field with value "N/A"
- Do not skip the field.
```

When input quality varies:
```
If the input text is:
- Empty → output: {"status": "error", "message": "No input provided."}
- Under 10 words → output: {"status": "warning", "message": "Input too short for reliable analysis."}
- Otherwise → proceed with analysis.
```

Always provide the full output schema even for error/edge cases.
Haiku follows "fill in this template" more reliably than "decide
what to output based on input quality."

# Schema Adherence Under Pressure

**Opus**: Maintains output format even with unusual or challenging
inputs. Degrades gracefully.

**Haiku**: Schema adherence is strong for typical inputs but can break
on edge cases — missing fields, malformed data, empty inputs.

**Mitigation**: Demonstrate edge cases in examples AND specify fallback.

```
If a required field is missing, output the field with value "N/A".
Never omit fields from the schema.
If input is empty, output the complete schema with all values "N/A".
```

Critical: include at least one edge-case example in the few-shot set.
Haiku generalizes from examples better than from rules alone for
format recovery.

# Self-Correction and Verification

**Opus**: Naturally reviews its output and catches errors. Effective
when prompted to critique and revise.

**Haiku**: Rarely self-corrects unprompted. When prompted to review,
corrections are shallow (surface-level, not logical).

**Mitigation**: Build verification INTO the process steps.

```
Step 3: Verify your answer satisfies rules 1, 2, and 3.
  If all pass, output it.
  If any fail, identify which rule is violated,
  revise the answer, then output.
```

Do NOT use: "Review your output for errors."
Do use: specific checkable criteria embedded in the workflow.
Haiku's verification is only as good as the checklist you provide.

# Summarization Fidelity

**Opus**: Produces summaries that accurately reflect source material.
Naturally distinguishes between main claims and supporting detail.
Maintains appropriate level of abstraction.

**Haiku**: Summaries may:
- Overweight content from the beginning/end of the source (position bias)
- Lose nuance (turn hedged claims into definitive statements)
- Miss the central thesis while including peripheral details
- Add interpretive framing not present in the source

**Mitigation**: Constrain the summarization process.

```
Step 1: Identify the single main claim or thesis of the text.
        Write it in one sentence.
Step 2: Identify 3 supporting points. Write each in one sentence.
Step 3: Combine into a coherent paragraph of 60-80 words.

Rules:
- The main claim MUST appear in the first sentence of your summary.
- Do not add interpretation or analysis.
- Do not introduce information not in the source.
- If the source hedges a claim ("may", "suggests", "could"),
  preserve the hedging in your summary.
```

For longer documents, fight position bias:
```
Divide the text into thirds (beginning, middle, end).
Extract one key point from each third.
Your summary must include content from all three sections.
```

# Tool Use Planning

**Opus**: Plans tool call sequences strategically. Assesses information
needs before acting. Batches efficiently.

**Haiku**: May call tools eagerly without planning. Can make redundant
calls or miss dependencies between calls.

**Mitigation**: Provide an explicit tool-use plan.

```
Before calling any tool:
1. List what information you need.
2. Identify which tool provides each piece.
3. Determine the correct call order (dependencies first).
4. Execute in that order.
Do NOT call a tool until you have completed steps 1-3.
```

For multi-tool tasks, enumerate the exact sequence in the process
section rather than letting Haiku decide the order.