# Audience Profile > 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 deck-builder, slide-outliner, and exec-summary. Use whenever a stakeholder communication deliverable is being designed for a specific audience. - Skill: `sananthanarayan/audience-profile` (Agent Skill, multi-file: 5 files) - Install (CLI): `npx skillmds@latest add sananthanarayan/audience-profile` - Raw SKILL.md: https://api.skillmd.com/api/skills/sananthanarayan/audience-profile/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: sananthanarayan (https://skillmd.com/u/sananthanarayan) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sananthanarayan/audience-profile --- # audience-profile You help the user (or another skill) pick the right *shape* for a communication deliverable based on who's receiving it. This skill is mostly a structured reference — it converts a free-form audience description into a concrete set of rules. ## How to respond 1. **Map the free-form audience to an archetype.** Common ones in [`reference.md`](reference.md): | Archetype | Typical signals | |---|---| | `exec` | "VP", "C-suite", "leadership team", a *single* senior decision-maker | | `board` | "Board of directors", "board update", "quarterly business review" | | `technical` | "Engineering team", "architecture review", "design review", "tech-lead", "staff engineers" | | `sales` | "Customer pitch", "prospect", "sales meeting", "pre-sales" | | `investor` | "Series A", "VCs", "fundraising", "investor update" | | `internal` | "All-hands", "team meeting", "alignment session", "stand-up" | | `partner` | "Partner meeting", "joint customer", "channel partner" | | `customer` | "Customer success", "QBR", "renewal conversation", "onboarding" | When the user describes a *mixed* audience ("VP Eng plus their staff plus the partner CTO"), pick the **least technical** archetype — you can always add detail in an appendix, but you can't un-confuse a non-technical attendee with mid-deck jargon. 2. **Emit a structured profile.** When invoked, return the archetype's full ruleset: ``` Audience archetype: Slide count target: Bullet density: , Tone: Title style: Must-have sections: Layouts to favour: Layouts to avoid: Things to never include: ``` 3. **Be opinionated.** This skill exists to *make decisions* for the user. If they push back, fine — but don't hedge in the initial response. "Use a `big_number` slide here" beats "you could consider a `big_number` slide if you wanted to". 4. **Hand off cleanly.** When called from `deck-builder` or `slide-outliner`, the profile is *input* to that skill — don't try to build the artifact yourself. ## When to use this skill - ✅ Before drafting a deck, exec summary, or design review. - ✅ When the user describes the audience vaguely ("a leadership meeting") and you need to make density/length decisions. - ✅ When you need to challenge a prior draft ("this is too dense for an exec audience"). ## When NOT to use this skill - ❌ For peer engineering communication where the "audience" is just "another engineer reading the doc". The standard documentation style is fine. - ❌ For purely internal artifacts (ADRs, runbooks) — those have their own conventions independent of audience. ## Useful references - [`reference.md`](reference.md) — full archetype matrix with all eight profiles ## Quality bar - **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"). ## Anti-patterns to avoid - ❌ **Treating "executives" as one archetype regardless of context.** A single VP deciding a budget (`exec`) and a board reviewing the quarter (`board`) want different shapes — `board` is more formal, more financial, and assumes less recall of prior context. Match the setting, not the seniority label. - ❌ **Profiling the most senior title in the room instead of the actual decision-maker.** If the VP is there to rubber-stamp what their staff engineer recommends, the staff engineer is the audience. Profile who the deliverable must *convince*, not who has the grandest title. - ❌ **Defaulting a mixed room to the most technical archetype** because the deck "needs the detail". A non-technical attendee lost on slide 3 is lost for the whole meeting; resolve to the least-technical archetype and push depth to an appendix. - ❌ **Hedged, generic output.** "Know your audience and keep it appropriately concise" is a fortune cookie, not a profile. Emit the numbers: slide count, bullet density, the must-have sections in order. - ❌ **Building the artifact instead of the profile.** When called from `deck-builder` or `slide-outliner`, returning slides instead of the ruleset — the profile is *input* to those skills, not a substitute for them. - ❌ **Over-fitting to one named person's quirks** ("Dana hates animations") instead of the role. Profiles are reusable because they're keyed to the archetype; bake in one individual's preferences and the profile dies when Dana changes jobs. Note the personal quirk as a one-line override, keep the archetype intact.