Use audience-profile

Translate an audience type (exec, board, technical, sales, investor, internal, partner, customer) into structural rules

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.

Reach for it when Use whenever a stakeholder communication deliverable is being designed for a specific audience.

Install it

npx skilldrop-cli install audience-profile                 # Claude Code, your user folder
npx skilldrop-cli install audience-profile --project       # Claude Code, this repo
npx skilldrop-cli install audience-profile --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Stakeholder comms pack: --pack stakeholder-comms installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Build the PowerPoint for the board meeting"
• "Outline the slides for this deck"
• "Write the one-page executive summary"

If another skill answers instead, ask for this one by name: "use audience-profile".

Check what you get

A good result:

• 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").

Use something else when

• 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.

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: slide-outliner, exec-summary

Edit this page on GitHub · View source