Audience adaptation
Skill Amey-Thakur/AI-SKILLS/skills/writing/audience-adaptation
Adapt what you write, how much, and how you frame it to the specific reader's knowledge, needs, and stakes. Use when the same content must reach different audiences, or when writing is missing its reader.From its SKILL.md
npx -y skills add Amey-Thakur/AI-SKILLS --skill audience-adaptationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.9 KB, 620 tokens by cl100k_base, as published. Nobody here has run it
Audience adaptation
The same facts land differently on a beginner and an expert, an engineer and an executive, a skeptic and a fan. Writing that ignores its reader is writing for nobody. Adaptation is deciding, for this reader, what to include, what to assume, and how to frame it.
Method
- Name the actual reader and their stakes. Who reads this, what do they already know, what do they need from it, and what do they care about? A page for new users and a page for integrators are different documents even about the same feature. "General audience" is usually an excuse not to decide.
- Calibrate assumed knowledge precisely. Explaining what the reader knows bores and patronizes; assuming what they do not know loses them. Pitch to their level: define the terms they will not know, skip the ones they will, and link deeper for the range in between (see explain-like-im-five and eli-expert prompts for the two extremes).
- Frame in the reader's terms. Lead with what THIS reader values: executives want impact and risk (see exec-one-pager), engineers want how and tradeoffs (see design-doc), users want what it does for them. The same change is "cut costs 30%" to a CFO and "here is the new API" to a developer.
- Adjust depth and length to their need and attention. A busy decision-maker needs the answer up front and the detail available, not required (see structure-and-flow's priority order). A learner needs the build-up. Match the format to how the reader will actually consume it.
- Match tone and formality to the relationship and context. Peer, customer, executive, public: each has a register (see voice-and-tone). Getting this wrong (too casual with a regulator, too stiff with a teammate) undercuts the content.
- When one piece must serve several audiences, layer it. A clear summary up top for everyone, deeper sections for those who need them, glossary or links for the gaps: so each reader finds their level without the others' content in the way (see docs-information-architecture).
Boundaries
- Adapting to the reader is not pandering or dumbing down; it is meeting them where they are so the true content gets through. The facts do not change, the framing and depth do.
- You cannot serve wildly different audiences in one undifferentiated piece; if the needs truly diverge, write separate versions or clearly layered sections (see roadmap-communication's audience views).
- Knowing the audience requires real information about them; when you are guessing, say what you assumed, and prefer the clearer, more inclusive choice (see clear-writing).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.