Don't Tell Claude to Show Its Work: The reasoning_extraction Trap in Skill Prompts

For years, "explain your reasoning step by step" was table-stakes prompting. It made weaker models more accurate, it gave you a trace to debug, and it was in half the skill prompts on the internet. On Claude Fable 5, it can get your request refused.

Fable 5 returns a summarized version of its thinking, but its raw chain of thought is never returned. A request that tries to force the model to reproduce or echo that internal reasoning in the response text can be declined with stop_reason: "refusal" and stop_details.category: "reasoning_extraction" — and even when it isn't outright refused, it elevates the odds a fallback kicks in. The exact phrases that used to be best practice are now a liability baked into your skill library.

As of July 2026, this is one of the quietest migration hazards. It won't show up as a syntax error or a failed build. It shows up as a skill that mysteriously refuses more often than its neighbors — and the culprit is a single well-intentioned line you copied from a 2024 prompting guide.

Key Takeaways

• "Show your work" can now backfire. Prompts that force the model to echo its internal reasoning can be refused with category reasoning_extraction.
• The raw chain of thought is never returned on Fable 5 by design — you can't extract it, and asking harder just raises refusal risk.
• You already get a summary. thinking blocks with display: "summarized" give you readable reasoning without asking for it in the answer.
• Rewrite offending prompts to ask for a conclusion with justification, not a reproduction of the model's private thoughts.
• Audit your whole library for the trigger phrases — one line can raise a skill's refusal rate across every call.

Why "show your work" is now a trigger

Two facts collide here. First, Fable 5's thinking is always on, and the model produces internal reasoning on every request. Second, that raw reasoning is deliberately not exposed — responses carry thinking blocks whose display is either "summarized" or "omitted", never the verbatim trace.

A prompt like "output your full chain of thought" or "reproduce every reasoning step verbatim" is, from the classifier's point of view, an attempt to defeat that boundary — to extract the internal reasoning the model is designed not to surface. That's what reasoning_extraction names. It doesn't matter that your intent is benign debugging; the shape of the request is what trips it.

This is the crucial reframe: you're not being blocked from seeing reasoning. You're being blocked from forcing the model to regurgitate its private chain of thought into the answer channel. The distinction is everything, because the first thing is still fully available to you — through a different door.

The phrases to hunt down

Grep your skill prompts, system prompts, and skill descriptions for these. Any of them can push a request toward reasoning_extraction:

• "Explain your reasoning step by step."
• "Show your work."
• "Output your chain of thought."
• "Think out loud and include every step in your answer."
• "Before answering, write out your full internal reasoning."
• "Reproduce your complete thought process verbatim."
• "Don't summarize your reasoning — give me all of it."

The common thread isn't the word "reasoning." It's the demand that the model's internal process be reproduced in full in the visible output. "Justify your answer" is fine. "Reproduce your entire chain of thought" is the trap.

Read the summarized thinking blocks instead

If you wanted reasoning for debugging or transparency, Fable 5 already hands it to you — you just read it from the right place. The thinking blocks in the response carry a display: "summarized" view: a readable summary of how the model got there. You don't have to ask for it in the prompt, and asking for it in the answer is exactly what causes the problem.

So the pattern flips. Instead of engineering the prompt to make reasoning appear in content, you leave the prompt clean and read the summary off the thinking blocks programmatically:

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    messages=[{"role": "user", "content": task_prompt}],
)

# The answer — no "show your work" instruction needed in the prompt
answer = "".join(b.text for b in response.content if b.type == "text")

# The reasoning summary — read it, don't demand it in the answer
reasoning = [
    b.text for b in response.content
    if b.type == "thinking" and getattr(b, "display", None) == "summarized"
]

One more operational note: when you continue a conversation on the same model, pass the thinking blocks back unchanged. They're part of the state Fable 5 expects on the next turn. (Other models drop them — which is fine, but don't mangle them yourself.)

Rewriting an offending skill

Take a code-review skill whose prompt reads:

Review this pull request. Explain your reasoning step by step and show all
of your work so I can see exactly how you reached each conclusion. Output
your complete chain of thought before giving the final verdict.

Every clause here is a reasoning_extraction magnet, and none of it is necessary. Rewrite it to ask for a justified conclusion, not a reproduced thought process:

Review this pull request. For each issue you find, give the location, a
one-line description, the severity, and a short justification for why it
matters. End with a verdict: approve, request changes, or block, and the
single most important reason.

The new version still gives you traceable reasoning — every finding is justified — but it asks for conclusions with rationale rather than a dump of the model's internal chain of thought. If you additionally want the model's own reasoning summary for a debugging UI, read it off the thinking blocks as shown above. You get more signal, cleaner output, and no refusal risk.

A quick audit checklist

1. Search every skill prompt for the trigger phrases above, including skill descriptions and any shared system prompt.
2. Classify each hit. Is it asking for a justified conclusion (keep, maybe reword) or a reproduction of internal reasoning (rewrite)?
3. Rewrite the reproductions as "give the answer plus a short justification for each key decision."
4. Move transparency to the response layer. If a downstream UI needs reasoning, read the display: "summarized" thinking blocks instead of prompting for them.
5. Confirm with your refusal logs. If you've been tracking stop_details categories (as the fallback-aware agents piece recommends), watch the reasoning_extraction count drop after the rewrite.

That last step is the feedback loop. Refusal categories are your best evidence for which prompts to fix — a cluster on reasoning_extraction points straight at the offending skill.

Why the boundary exists at all

It's worth understanding the design, because it tells you where the line is. Fable 5 keeps its raw chain of thought private and shares only a summary — that's a deliberate product decision, not an oversight you can prompt your way around. The reasoning_extraction classifier exists to protect that boundary against requests engineered to defeat it. So the question the classifier is effectively asking isn't "does this prompt mention reasoning?" — it's "is this prompt trying to force the private trace into the visible output?"

That framing resolves most of the edge cases you'll hit. "Give me your final answer and a one-paragraph rationale" is asking for a conclusion — fine. "Print your internal reasoning verbatim, don't summarize" is asking to extract the trace — trap. "Walk me through how this algorithm works" is asking about a subject, not the model's own cognition — fine. When you're unsure whether a prompt is safe, ask yourself which of those three it resembles. If it's demanding a verbatim dump of the model's own thinking, rewrite it; anything else is almost certainly clear.

This also means you don't lose transparency by respecting the boundary. The summarized thinking blocks give you a genuine, readable account of the model's approach — just delivered through the channel designed for it rather than forced into the answer.

This is part of a bigger pattern

The reasoning-extraction trap is a specific case of a general Fable 5 truth: prompt habits that helped weaker models can hurt this one. "Show your work" was a crutch for models that reasoned poorly without narration. Fable 5 reasons well internally and shares a summary freely — so the crutch becomes a tripwire. The broader version of this cleanup is covered in Your Skills Are Too Prescriptive, where over-specified procedures get the same treatment.

If you build agents and workflows that chain many skills, one buried "output your chain of thought" line can raise the refusal rate of an entire pipeline. Fixing it is cheap and the payoff is disproportionate.

The takeaway

Don't tell Fable 5 to show its work. It won't hand over its raw chain of thought no matter how you phrase it, and pushing hard just risks a reasoning_extraction refusal. Ask instead for a conclusion with justification, and read the summarized thinking blocks when you need the reasoning itself.

Run the audit today: find the trigger phrases, rewrite the reproductions, and route transparency to the response layer. Then wire up refusal handling so any stray decline degrades gracefully — the fallback-aware agents guide has the code. The rest of the series lives at the Claude Fable 5 hub, and you can explore installable skills and loops across /browse and /loops.