Purpose
Turn a complex technical system into a clear, layered narrative anchored by a single memorable analogy — so a product manager or technical lead can explain the same system to an executive, a cross-functional partner, or an engineer without rewriting it each time. Solves the recurring problem of technical explanations that either overwhelm non-technical audiences or oversimplify to the point of being useless.
When to Use
Invoke this skill when the user asks to:
- Explain a back-end system, data pipeline, or infrastructure to non-technical stakeholders
- Prepare a briefing on a technical migration, re-platform, or architecture decision for leadership
- Justify engineering investment or technical debt to a budget owner or executive
- Describe how a data or ML system works to sales, marketing, or a board
- Simplify a technical concept for a deck, all-hands, or customer conversation
- Get everyone from CEO to engineer aligned on what a system does and why it matters
Inputs Required
Before starting, collect:
- The system to explain: What it is, in the user's own words (2–4 sentences is fine)
- What it does / why it exists: The business problem it solves or the capability it enables
- Primary audience: Executive / cross-functional partner / board / customer / mixed
- The one thing they must walk away understanding: The single takeaway that matters most
- Common misconception or confusion: What people usually get wrong or ask about this system
- Stakes or decision on the table: Is this informational, or tied to a budget, timeline, or approval?
If the primary audience is unclear, default to producing all three depth levels so the user can pick. If the "one thing" is missing, infer it from the business problem and flag the assumption.
Instructions
Step 1: Extract the Core Function
Strip the system down to its single most important job. Ignore implementation detail for now.
- Write the system's purpose in one sentence a 12-year-old could follow, using no jargon
- Identify the input → transformation → output in plain terms (what goes in, what happens, what comes out)
- Name the business consequence: what breaks or becomes impossible if this system didn't exist
- This becomes the spine every layer of the explanation hangs from
Step 2: Build the Anchor Analogy
Create one central analogy that maps to the system's real structure — not a decorative comparison.
- Choose a domain the audience already understands (post office, kitchen, highway, library, filing cabinet, air traffic control, etc.)
- Map the key components of the real system to elements of the analogy (e.g., queue = line at a deli counter, cache = keeping frequent items on the front shelf)
- Pressure-test the analogy: where does it break down? Note the one place it's imperfect so the user can preempt a "gotcha" question
- The analogy must survive being repeated back — if it's too clever to summarize in a sentence, simplify it
Step 3: Write the Three Depth Levels
Produce the same explanation at three altitudes. Each level stands alone and is complete for its audience.
Level 1 — Executive (30 seconds, ~60–80 words)
- Lead with the business outcome, not the mechanism
- One sentence on what it does, one on why it matters, one on the current state or ask
- Zero jargon. If a technical term is unavoidable, define it in the same breath
Level 2 — Cross-Functional (2 minutes, ~150–200 words)
- Use the anchor analogy to walk through how the system works step by step
- Introduce the 3–5 key components by name, each tied to its analogy element
- Include one concrete example of the system doing its job with real-feeling numbers or a scenario
- Name the tradeoff or constraint that shapes decisions (speed vs. cost, accuracy vs. latency, etc.)
Level 3 — Technical (5 minutes, ~250–350 words)
- Drop the analogy scaffolding and describe the actual architecture, data flow, and technologies
- Explain the key design decisions and why they were made
- Address the common misconception directly and correct it
- State the current limitations or risks honestly
Step 4: Address the Misconception and the Stakes
- Write a 2–3 sentence direct rebuttal to the common confusion, phrased for the primary audience
- If a decision is on the table, translate the technical situation into a business framing: cost of action vs. cost of inaction, in terms the decision-maker weighs
Step 5: Produce Supporting Assets
- One-sentence summary: The whole system in a single line the user can repeat verbatim in a hallway or a Slack message
- Visual description: A described diagram (boxes, arrows, labels) the user could sketch on a whiteboard or hand to a designer — specify what each box is and what the arrows represent
- Three anticipated questions with tight answers, calibrated to the primary audience
Output Format
- Structure: Sequential sections following the build order
- Length: 800–1,100 words total
- Format: Structured document — prose within each depth level, bullets for components, a described diagram
- Sections: Core Function (one sentence) → Anchor Analogy → Level 1 Executive → Level 2 Cross-Functional → Level 3 Technical → Misconception & Stakes → One-Sentence Summary → Visual Description → Anticipated Questions
- Tone: Clear and confident, never condescending — the register of a technical lead who respects the audience's intelligence but not their time. Concrete over abstract.
Quality Checklist
Before delivering output, verify:
- [ ] All three depth levels are present and each is complete on its own — a reader could stop at any level and understand the system
- [ ] The anchor analogy maps to real components, and its one weak point is explicitly noted
- [ ] Level 1 contains zero undefined jargon (scan it word by word)
- [ ] The one-sentence summary is genuinely one sentence and repeatable from memory
- [ ] The visual description names every box and labels every arrow — a non-designer could draw it
- [ ] The common misconception is directly addressed and corrected, not just mentioned
Notes
- The most common failure is an analogy that sounds good but doesn't hold structure — always map components, don't just gesture at a vibe
- If the system genuinely can't be reduced to one analogy, use one analogy per subsystem rather than forcing a single stretched metaphor
- For budget or approval conversations, the Level 1 executive framing is the highest-leverage output — spend the most care there
- Encourage the user to lead any live conversation at Level 1 and let the audience pull them deeper, rather than starting at Level 3 and losing the room
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills