Purpose
Turn a dense technical or security concept into an explanation a non-technical stakeholder actually understands and can act on — leading with the point, grounding abstraction in a concrete analogy, and framing why the concept matters to that specific audience's decisions. Solves the recurring problem of technical accuracy that fails to land in an exec review, sales conversation, or cross-functional planning meeting.
When to Use
Invoke this skill when the user asks to:
- Explain a permissions model, roles/scopes, or access control to an executive or business audience
- Simplify API architecture, integration flows, or system design for non-engineers
- Describe agent access, autonomous permissions, or AI system behavior to a customer or leadership team
- Rewrite a security concept (encryption, authentication, data residency, SSO) for a compliance-wary buyer or board
- Prepare talking points that translate a technical decision into business impact
- Turn engineering documentation into a slide-ready or email-ready stakeholder explanation
Inputs Required
Before starting, collect:
- The concept to simplify: The technical or security concept, in whatever detail the user has it (paste of docs, a paragraph, or a name)
- Audience: Who's receiving this — e.g., CEO, CFO, non-technical customer, sales team, legal/compliance, board
- Their stake: What decision, concern, or question this audience actually has (approving budget, assessing risk, buying the product, unblocking a launch)
- Format destination: Where it will live — verbal talking points, email, slide, one-pager, FAQ answer
- Technical accuracy bar: Must-preserve details vs. safe-to-abstract details (any nuance that would be dangerous to oversimplify)
- Tone constraint: How much confidence vs. caution the audience expects (reassuring, neutral, candid about tradeoffs)
If the audience's stake is unspecified, infer the most likely decision for that role and state the assumption. If accuracy bar is unspecified, preserve any security/compliance-relevant nuance by default.
Instructions
Step 1: Identify the Core Idea and the Failure Mode
Before rewriting, isolate two things:
- The one idea that matters most to this audience — not the most technically interesting part, the most decision-relevant part
- The most likely misunderstanding — where a non-technical listener will get lost, form a wrong mental model, or fixate on the wrong risk
State the core idea in a single plain sentence with no jargon. If you can't, the concept isn't yet understood well enough to simplify.
Step 2: Strip and Translate the Jargon
Build a quick jargon map for every technical term in the source:
- Term → plain-language equivalent (e.g., "OAuth scopes" → "a list of exactly what an app is allowed to touch")
- Preserve any term the audience genuinely needs to recognize going forward; translate the rest
- Replace acronyms with function on first use; only keep an acronym if the audience will hear it again
Rule: no unexplained jargon survives into the final output.
Step 3: Build the Explanation in 4 Layers
Structure the rewrite using this fixed layered format — each layer does one job:
Layer 1 — The One-Liner (1 sentence) Lead with the conclusion. What is this and what does it do for us, in a sentence a busy exec could repeat.
Layer 2 — The Analogy (2–4 sentences) Map the concept to something from everyday life the audience already understands. Prefer physical, familiar analogies — building access badges, hotel keycards, a bank teller vs. vault, a valet key that starts the car but won't open the trunk. The analogy must hold for the specific point being made; flag where the analogy breaks if the audience might over-extend it.
Layer 3 — Why It Matters (2–4 sentences) Connect directly to the audience's stake from Step 1. Answer the unspoken "so what?" — the risk it removes, the capability it unlocks, the cost or exposure it affects, the decision it informs. Use business language (risk, cost, speed, trust, liability), not technical language.
Layer 4 — The Takeaway (1–2 sentences) End with what the audience should now believe, decide, or feel confident about. If a decision is being asked of them, make the ask explicit.
Step 4: Add a Depth Ladder (Optional On-Demand Detail)
Some stakeholders drill in. Provide a short "If they ask" section with 2–3 anticipated follow-up questions and one-line answers — so the presenter can go one level deeper without falling into full technical mode. Keep each answer to a single sentence.
Step 5: Accuracy and Honesty Check
Reconcile the simplification against the accuracy bar:
- Confirm no simplification created a factually false statement
- Flag any place where the plain-language version omits a caveat that matters (especially security/compliance)
- Include one line of honest framing if there's a real tradeoff — oversimplified reassurance erodes trust with technical-adjacent audiences
Output Format
- Structure: The 4-layer explanation as the primary deliverable, followed by the "If they ask" depth ladder and a short accuracy note
- Length: 250–450 words for the core explanation; depth ladder adds 3–5 short lines
- Format: Structured document with labeled layers — scannable, presenter-ready, not a wall of prose
- Sections: Core Idea (one sentence) → 4-Layer Explanation (One-Liner, Analogy, Why It Matters, Takeaway) → If They Ask → Accuracy Note
- Tone: Confident and clear, calibrated to the audience's expected posture — reassuring where warranted, candid where there's a real tradeoff; never condescending
Quality Checklist
Before delivering output, verify:
- [ ] The one-liner contains zero unexplained jargon and states the conclusion, not the mechanism
- [ ] The analogy maps to something genuinely familiar and holds for the specific point (breakdown flagged if it could mislead)
- [ ] "Why It Matters" ties to the stated audience stake in business terms, not technical terms
- [ ] Every technical term from the source is either translated or intentionally preserved for recognition
- [ ] No simplification introduced a factually false claim, and security/compliance caveats are preserved
- [ ] A clear takeaway or explicit ask closes the explanation
Notes
- The most common failure is leading with mechanism ("it uses scoped OAuth tokens...") instead of conclusion ("the app can only see what you specifically approve"). Always lead with the conclusion.
- Physical-world analogies (badges, keys, safes, valet keys) outperform digital analogies for non-technical audiences, because the audience already has an intuition for physical access and trust.
- For security concepts, resist over-reassurance. A candid "here's the one thing to watch" builds more trust with executives than a flawless-sounding pitch — and protects you if the caveat later surfaces.
- The depth ladder is what separates a simplified explanation from a dumbed-down one: it lets the presenter stay accurate under questioning without abandoning the plain-language frame.
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