Purpose
Take one core message — a technical update, project status, incident recap, or product recommendation — and produce distinct versions tuned for developers, executives, and mixed rooms, so the same truth lands correctly regardless of who's reading. Eliminates the two failure modes: burying executives in technical detail, or hollowing out a message until practitioners stop trusting it.
When to Use
Invoke this skill when the user asks to:
- Rewrite a technical update for an executive or C-suite audience
- Build a QBR section that works for both the practitioner team and their sponsor
- Turn an engineering-heavy status into an exec briefing or board-ready summary
- Adapt an incident postmortem for the customer's technical team vs. leadership
- Send one email that needs to satisfy both an admin/developer and their VP
- Create tiered talking points for a mixed-stakeholder meeting
Inputs Required
Before starting, collect:
- Source content: The original message, notes, or draft — technical detail included
- Target audiences: Which versions are needed (technical / executive / mixed — one or more)
- Format: Email, deck slide, briefing doc, talking points, or Slack/chat message
- Core outcome: The one decision, action, or takeaway the reader must walk away with
- Relationship context: New account / stable / at-risk / renewal / escalation
- Sensitivities: Anything to soften, avoid, or explicitly own (a miss, a delay, a bad metric)
If target audiences aren't specified, produce all three versions. If format is missing, default to email for executive and technical, talking points for mixed.
Instructions
Step 1: Extract the Invariant Core
Before adapting anything, isolate what stays true across every version:
- The fact: What actually happened or is being recommended (never changes)
- The outcome: The single decision or action required
- The proof: The strongest supporting evidence available Write these three down internally. Every version must preserve all three — only the framing, altitude, and detail change.
Step 2: Build the Technical Practitioner Version
Audience: developers, admins, engineers, technical implementers.
- Altitude: Ground level — the "how" and the "why it works"
- Vocabulary: Precise technical terms; no dumbing down; assume domain fluency
- Detail: Include specifics — versions, configs, error codes, metrics, root cause
- Proof: Reproducible evidence, logs, benchmarks, methodology
- Trust driver: Accuracy and specificity — vagueness reads as incompetence to this audience
- Call to action: A concrete technical next step (implement X, test Y, review config Z)
- Length: Longer is acceptable if every detail earns its place
Step 3: Build the Executive Sponsor Version
Audience: C-suite, VPs, budget owners, business decision-makers.
- Altitude: 30,000 feet — the "so what" for the business
- Vocabulary: Business outcomes — cost, risk, time-to-value, revenue, adoption, retention
- Detail: Minimal technical detail; translate every technical fact into a business consequence
- Proof: Quantified impact — dollars, hours saved, risk reduced, benchmark vs. goal
- Trust driver: Clarity and confidence — one clear ask, no hedging, no jargon
- Structure: Lead with the conclusion (BLUF — bottom line up front), then support
- Call to action: A business decision (approve, prioritize, allocate, endorse)
- Length: Tight — 3–5 sentences or bullets for email; one slide for a deck
Step 4: Build the Mixed-Room Version
Audience: both present at once (e.g., a QBR with the admin team and their VP).
- Layered structure: Executive summary first (so leadership gets it in 15 seconds), technical appendix or expandable detail second (so practitioners can go deep)
- Signposting: Explicitly label sections so each audience knows where their content lives
- Bridge language: Connect the technical detail to the business outcome in one sentence so neither audience feels the other's section is wasted air
- Call to action: Two-tiered — the business decision for leadership, the technical next step for the team
- Avoid the trap of an averaged, blurry middle — layer, don't blend
Step 5: Apply Relationship and Sensitivity Calibration
Adjust tone based on context:
- At-risk / escalation: Lead with ownership and the fix; quantify the path back to health
- Renewal: Emphasize value delivered and forward roadmap in the executive version
- Owning a miss: State the miss plainly in the technical version; frame it as controlled and resolving in the executive version — never spin it away
- New account: Slightly more context-setting; assume less shared history
Step 6: Verify Consistency Across Versions
Read the fact, outcome, and proof in every version side by side. Confirm no version contradicts another — an executive who reads the technical version later must find the same truth, just described differently.
Output Format
- Structure: One labeled section per requested audience version, each ready to send/paste as-is
- Length: Technical version 150–300 words; executive version 60–120 words; mixed version 200–350 words with clear layer breaks
- Format: Matches requested format per audience (email body, slide copy, briefing doc, or talking points); mixed version uses a layered summary-then-detail structure
- Sections: Invariant Core (brief, labeled) → Technical Version → Executive Version → Mixed-Room Version → Consistency Note
- Tone: Technical version — precise and peer-level; executive version — confident, business-fluent, BLUF; mixed version — signposted and bridging. Never condescending in either direction.
Quality Checklist
Before delivering output, verify:
- [ ] The same fact, outcome, and proof appear in every version — no version contradicts another
- [ ] The executive version leads with the conclusion and contains zero unexplained technical jargon
- [ ] The technical version includes at least one specific detail (metric, config, version, root cause) the executive version omits
- [ ] Each version ends with an audience-appropriate call to action — a technical step for practitioners, a decision for executives
- [ ] The mixed-room version is layered (summary + detail), not an averaged blend
- [ ] Any sensitivity flagged in the inputs is handled explicitly, not spun or omitted
Notes
- The most common failure is the "blurry middle" — a mixed message that satisfies no one. Layering beats averaging every time.
- Executives don't want less information; they want a different information — consequence over mechanism. Translate every technical fact into "what it means for the business."
- When owning a miss, the technical version can be more candid than the executive version, but the two must never contradict — leadership will eventually read both.
- For QBR decks specifically, put the executive version on the visible slide and the technical version in the appendix or speaker notes.
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