Matt Pocock posted on September 3, 2026 that /show-me is "a phenomenal skill," specifically because it "makes PR descriptions extremely easy to read," and described it as "basically a toolbox of nice ways to look at code." The post crossed 87,000 views in four hours, which for a single skill is unusual.
The skill is by Dex Horthy, and the useful thing about it is how narrow it is. It does not generate diagrams. It does not write your PR. It is a style guide — a menu of compact visual formats plus rules for picking between them. When Pocock was asked directly in the thread whether it generates the PR description or only reformats the diff, his answer was exactly right: "It's just a style guide for how to show diffs, it's up to you how you use it."
That distinction is the whole point, and it is why it works.
TL;DR — what people are asking
| Question | Answer |
|---|---|
| What is it? | A skill that makes a coding agent reply in compact visuals — trees, diffs, mermaid, one HTML file — instead of prose. |
| Does it write PR descriptions? | No. It shapes how a diff is shown. People use that output as a PR body because it happens to fit. |
| Install | npx skills add humanlayer/skills --skill show-me, then /show-me. |
| Claude Code only? | No. It is a plain SKILL.md — any harness that reads agent skills can load it. |
| Why not just ask? | Prose requests drift across turns; an invoked skill loads deterministically and carries the format menu. |
| New capability? | None. The model could already draw all of this. The skill supplies selection, which is the hard part. |
| Worth writing your own? | Often yes — a house version encodes your stack's component and service vocabulary. |
| Main failure mode | Diagram slop on problems that were never visual. Its own author concedes diagrams are "sometimes slop." |
The format menu is the product
Strip the skill down and what remains is a list of output shapes with guidance on when each one is correct:
Text-based, for structure
| Format | When it wins |
|---|---|
| Component tree | UI hierarchy — which component owns which state hook |
| Call stack | Control flow and orchestration — who calls whom, in what order |
| File layout | Directory structure with a one-line responsibility per file |
| Pseudocode | Algorithms and branching logic, stripped of language ceremony |
| Type signatures | Interface boundaries and contracts |
| Annotated diff | What changed, at component / call-tree / file-structure level |
Diagram-based, for behavior
| Format | When it wins |
|---|---|
| Mermaid state diagram | A thing that can be in one of several modes, with transitions |
| Mermaid sequence diagram | Multi-party interaction over time — client, server, queue, worker |
| One focused HTML file | UI mockups, layout, state comparison, anything too dense for mermaid |
The HTML case is deliberately capped at one file, one point. Its author's framing is that mermaid and ASCII are "lighter and faster than HTML, good enough for most dev-work shaped problems" — HTML is the escape hatch for a visual UI, a layout, a state comparison, or a concept mermaid cannot hold, and it should be a diagram, an infographic, or a short slide deck, whichever fits.
Why this is a skill and not a prompt
There is a reply in Pocock's thread that explains the mechanism better than most posts on the subject: "prose rules get re-interpreted and a required flag doesn't... when the instruction is soft I drift, when it's a switch I comply."
That is the real argument for packaging this as a skill rather than a line in CLAUDE.md. Two things happen when you move it:
- Determinism. An invoked skill loads its full instructions at invocation time. A standing preference in CLAUDE.md competes with everything else in the context window and degrades over a long session — the same drift problem we covered in steering Claude Code and in the routing question of skills vs hooks vs prompts.
- Cost. CLAUDE.md is re-sent on every turn of every session. A skill is paid for only when it fires. A hundred-line format menu is exactly the kind of thing that should not live in your always-on context — see what actually costs you tokens in a Claude Code session for why that distinction adds up.
This is also the second time this year Pocock has surfaced the same underlying insight — his TypeScript Skills v1 progressive-disclosure work and his earlier argument that agent skills are for real engineers both land on the idea that the value of a skill is the editorial judgment it encodes, not the capability it unlocks.
What it is actually good for
From the thread, the uses that people reported are narrower and more specific than "diagrams are nice":
- Reading someone else's large diff. The annotated-diff format compresses "what structurally changed" into something scannable, which is why PR bodies were the first use to catch on.
- Design discussion before implementation. A component tree or sequence diagram of the proposed change surfaces disagreement while it is still cheap — the same argument behind DESIGN.md templates and Vercel's spec-driven UI approach.
- Getting oriented in an unfamiliar service. Point it at a route or a service and ask for a file layout with one-line responsibilities.
- Restating your own question. Several people use it to have the agent redraw what it thinks you asked — a cheap misalignment check before it starts editing.
- Composing with other skills. One reply described bolting a version of this into a
grill-mereview skill so the review session itself renders visually.
Rolling your own, in about a hundred lines
A skill like this is a SKILL.md with frontmatter and a body. There is no framework to learn — the format is covered end to end in our step-by-step guide to building your first agent skill. What makes a house version worth the hour is that you can encode your vocabulary:
---
name: show-me
description: >-
Answer with a compact visual instead of prose. Use when the user asks to
see, visualize, diagram, or map code, a diff, a service, or a flow — or
says "too much text".
---
## Pick the format first, then draw
| Shape of the question | Format |
| --- | --- |
| "What changed in this PR?" | Annotated diff, grouped by file responsibility |
| "How does X talk to Y?" | Mermaid sequence diagram |
| "What states can this be in?" | Mermaid state diagram |
| "Where does this live?" | File-layout tree, one line of purpose per file |
| "Who owns this state?" | Component tree with hooks annotated |
| Anything mermaid can't hold | ONE self-contained HTML file |
## Rules
- One artifact per answer. Never two diagrams for one question.
- No prose paragraph before the visual. Caption after, at most two lines.
- If the question is not structural, say so and answer normally.
That last rule is the one most people leave out and then regret. Which brings us to the honest part.
Honest limitations
- Diagram slop is real, and its author says so. The blog post behind the skill concedes diagrams can "sometimes be slop" while arguing they still beat textual explanations. That is a defensible position, not a solved problem — a mermaid diagram of something that was never structural is worse than a sentence.
- It adds no capability. Every one of these formats was already within the model's reach. The delta is selection and consistency, which is genuinely valuable and also genuinely modest. Judge it on that.
- Format quality varies by domain. Component trees and sequence diagrams are strong. Free-form HTML explainers are where output quality gets least predictable.
- Mermaid rendering depends on your surface. Terminals do not render it; Markdown previews, GitHub, and artifact viewers do. A mermaid answer in a bare terminal is just text with arrows in it.
- Distribution is via a third-party skills CLI, so you inherit whatever supply-chain posture that implies. If that matters to you, vendor the
SKILL.mdinto your own repo — it is one file. Our agent skills security threat model covers why that is not paranoia. - A skeptical read from the thread is fair: "so it does what agents already do, but nicer?" Yes. That is the claim. Whether nicer is worth an install is a fifteen-minute experiment, not an argument.
Related on explainx.ai
- What are agent skills — the complete guide
- How to build your first agent skill, step by step
- Skills vs hooks vs prompts — when to use each
- Matt Pocock: agent skills are for real engineers
- Matt Pocock's TypeScript Skills v1 and progressive disclosure
- Flint — Microsoft's visualization language for AI agents
- Steering Claude Code — CLAUDE.md, skills, hooks, subagents, rules
- Browse the explainx.ai agent skills directory
Skill behavior, install command, and format list reflect the published description of show-me as of September 3, 2026, and the September 3 discussion thread. Skills change between versions — read the SKILL.md you actually install before relying on the format menu described here.