Translate an audience type (exec, board, technical, sales, investor, internal, partner, customer) into structural rules — slide count, density, tone, must-have sections, things to avoid. Reusable across slide-outliner and exec-summary. Use whenever a stakeholder communication deliverable is being designed for a specific audience.
Pack stakeholder-commsTier lightJob Explain it to decision makersv0.1.1
In Claude Code, with the stakeholder-comms plugin installed, invoke it as:
/stakeholder-comms:audience-profile
Try it
A realistic prompt from the skill's acceptance evals:
We're presenting our platform strategy to a mixed room — the board plus two engineering leads. What audience rules should we design to?
What a good result looks like
Profile output is concrete. "Slide count: 8–12" beats "keep it short".
Mixed audiences resolve to the least-technical archetype, with the more-technical detail moved to an appendix.
Don't invent new archetypes for a single use case — pick the closest one and note the divergence ("board, but they've asked for technical depth on the proposal — add a 'how it works' section between Financials and Risks").
How it's checked
Measured against plain Claude Code (2026-10-23): it met 79% of its checks, against 44% without it, and a blind judge preferred the agent without it. How skills are checked
16 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Output is concrete and structural (slide count ranges, density, tone, must-have sections, things to avoid) rather than advice like 'keep it short'
A mixed audience resolves to the least-technical archetype, with the more-technical material moved to an appendix
No new archetype is invented for a one-off case — the closest existing one is chosen and the divergence noted
The profile is reusable across deliverables rather than being a deck or summary itself
It follows the chair's format (a paper of at most two pages, appendices allowed) rather than the CEO's three slides, and says why
It handles the finance committee chair's request by putting the full cost breakdown and lease terms in an appendix, rather than cramming them into the two pages or leaving them out
It does not predict how individual trustees will vote or assign them views based on their professions, says there is nothing in the input to go on, and may suggest a fair way to learn their concerns before the meeting
It accounts for the papers being read a week ahead: the 15 minutes is for questions and the decision, not for reading the paper aloud
It says the paper should state near the top the decision the trustees are being asked to make
It does not invent facts about the hospice, the proposal's costs or savings, the lease or governance rules that are not in the input
The response is about one page
Gives a few bullets (roughly eight or fewer), not a long document
The advice fits this audience and setting (farmers, in person, at a village hall) rather than generic rules for executives or boards
It advises leading with what changes for the farmers in practice, such as how they book and what they need to do differently, in plain words rather than how the system works inside
It does not state features of the booking system (an app, an online portal, phone hours and so on) as facts, since none were given
It delivers without asking questions first, in a plain, friendly tone suited to a first-time speaker
When it should and shouldn't activate
Should activate:
Who is my audience and what rules should the deck follow?
What are the structural rules for presenting to a board versus engineers?
Profile this audience so I know how technical to go
We have a mixed exec and technical room — how should I pitch it?