explainx / blog
Thariq's viral field guide on Claude Fable 5 argues prompts, skills, and context are only a map of the work—not the work itself. Here's why more capable models make that gap matter more, and how to close it in practice.
Jun 28, 2026
The explainx.ai skills registry is the canonical source for Claude Code and Cursor SKILL.md files. This guide explains how npx skills install works, what skills actually do, how to write your own, and how teams can use lockfiles to stay consistent in production.
Jun 27, 2026
Agent skills are reusable instruction packages that teach your AI coding assistant how to handle a specific class of task. This guide walks you through building one from scratch — from the blank SKILL.md to a published package others can install.
Jun 27, 2026
Claude Code gives you three ways to customize agent behavior: system prompts (CLAUDE.md), skills (SKILL.md), and hooks. Using the wrong primitive for the job wastes tokens, creates confusion, and breaks in subtle ways. Here is how to choose.
Claude Code engineer Thariq (@trq212) published a new field guide this week titled "A Field Guide to Fable: Finding Your Unknowns," and it's doing the same rounds his earlier essay on HTML over Markdown did. The core claim is deceptively simple: working with Claude Fable 5 keeps re-teaching him an old lesson — the map is not the territory. Your prompt, your skills, your CLAUDE.md, your context — that's all just a representation of the work. It is not the work itself.
That distinction sounds obvious until you watch what happens when the gap between map and territory widens with a more capable, more autonomous model. This post unpacks the metaphor, why it gets sharper rather than softer as models improve, and the concrete practices — the human/agent PR split, disciplined skill invocation, and deliberate unknown-hunting — that close the gap in day-to-day Claude Code work.
The map/territory distinction comes from general semantics — a map can be useful, detailed, even beautiful, and still be wrong about the terrain it describes. Applied to coding agents, the "map" is everything you hand Claude before it starts working:
CLAUDE.md project conventions and standing rulesThe "territory" is the actual codebase, its history, its undocumented constraints, and the real intent behind the request — most of which never makes it into the map because writing it all down is either impossible or something the requester didn't think to mention.
An agent doesn't act on the territory. It acts on the map. So any place where the map is silent, wrong, or stale becomes exactly where the agent goes wrong — confidently, because from its vantage point the map is all there is.
A recurring reply to Thariq's post asked the natural contrarian question: shouldn't this matter more with dumber models, since they need more hand-holding?
It's the opposite, and the reasoning is worth internalizing:
| Model behavior | Weaker model | More capable, more autonomous model (Fable 5) |
|---|---|---|
| Response to ambiguous instructions | Hedges, asks, or produces something visibly wrong that gets caught fast | Resolves ambiguity confidently and consistently |
| Scope of a single bad assumption | Contained to one small output | Propagates across an entire multi-file, multi-step session |
| Human review behavior | Reviewed line-by-line because output is unreliable | Reviewed more loosely because output is usually right |
| Cost of a map/territory gap | Caught early, cheap to fix | Caught late, after the agent has built on top of the wrong assumption |
A weak model's failures are loud and local. A strong model's failures are quiet and compounding — it takes your map at face value and executes it thoroughly, which is exactly what makes an unstated assumption expensive. This tracks with what Anthropic's own guidance on agentic coding and expertise has found: more autonomous agents shift the bottleneck from "can the model do the task" to "did you specify the task correctly." Capability doesn't remove the need for a good map. It raises the price of a bad one.
One of the most concrete practices to come out of this thread is splitting pull request descriptions into two distinct sections, addressed to two different readers:
Human section — images, screenshots, before/after diffs, short GIFs. Some information genuinely doesn't compress into text: a subtle layout shift, an animation timing, a color that's "almost right but not quite." Forcing a reviewer to reconstruct a visual change from a written description wastes their time and yours.
Agent section — plain text covering intent, constraints, edge cases considered, and things intentionally left out of scope. This is the section a follow-up agent session — yours or a teammate's — actually reads when it picks up related work later. Agents currently reason more reliably over structured text than over pixels, so burying that information inside a screenshot makes it invisible to the next agent that needs it.
Example PR description structure:
## For reviewers
 → 
The button now animates on click instead of an instant color swap.
## For agents
- Changed: `Button.tsx` click handler now debounces via `requestAnimationFrame`
- Constraint: must stay under 16ms per frame budget (see PERF.md)
- Not in scope: the disabled-state styling, tracked in FOLLOWUP-142
- Assumption: existing snapshot tests didn't cover animation timing, added new ones
This is the same instinct behind Thariq's earlier HTML-over-Markdown argument: pick the format that actually carries the information for the reader consuming it, human or agent, rather than defaulting to whatever's fastest to write. It's also a direct extension of the map/territory idea — a PR description is a map of the change, and a map that only serves one kind of reader leaves the other one working from an incomplete territory.
A related question from the thread: with a model as capable as Fable 5, are heavyweight skills frameworks like "superpowers" still worth maintaining, or do they just get in the way?
The honest answer is that a skill is itself a map — a codified shortcut standing in for territory the model would otherwise have to rediscover every session. That's valuable when the shortcut is accurate and repeatable. It's a liability when it's stale, over-specified for a model that no longer needs the hand-holding, or written for a problem that's subtly different this time.
Use this as a rough decision rule, consistent with the guidance in Skills vs Hooks vs Prompts:
| Situation | Reach for |
|---|---|
| Repeatable task with a known failure mode | A skill — encode the procedure once |
| Standing project convention that applies to every session | CLAUDE.md |
| Enforcing an action automatically on a tool call | A hook |
| One-off, exploratory, or genuinely novel work | Direct prompting, no skill |
| A skill hasn't been revisited since a model upgrade | Audit it — some scaffolding may now be dead weight |
The failure mode to watch for is treating a skill written for a weaker model as permanent scaffolding. If a skill mostly compensates for a model's shortcomings — exhaustive step-by-step instructions, defensive over-explaining — a capability jump like Fable 5 can make parts of that skill unnecessary map, not helpful map. Periodically re-reading skills against what the current model actually needs is part of keeping your map current with a moving territory, echoing the reasoning in Steering Claude Code with CLAUDE.md, skills, hooks, and subagents.
The most durable part of the field guide isn't a specific tactic — it's a discipline. A few practices worth adopting directly:
CLAUDE.md or the relevant skill so the same gap doesn't reappear next session.None of this is unique to Fable 5. It's the same discipline behind good context engineering and behind the emphasis on CLAUDE.md as persistent memory — the map only stays useful if you keep updating it against the territory it's supposed to represent.
This post analyzes Thariq's original field guide and public reactions to it on X. Model behavior, skill conventions, and best practices for Claude Code evolve quickly — verify current guidance in your own sessions before treating any specific tactic as permanent.