How do I install the Stakeholder Update Writing skill?

Run npx skillmds@latest add gavishap/stakeholder-update-writing in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Stakeholder Update Writing safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Stakeholder Update Writing?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Stakeholder Update Writing free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Stakeholder Update Writing?

gavishap (@gavishap) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Stakeholder Update Writing by gavishap

Name: Stakeholder Update Writing
Author: gavishap

Stakeholder Update Writing

Style rules for outward-facing deliverables — client/team chat messages, status reports, results write-ups, meeting follow-ups. Use whenever drafting an update, delivery message, or report that people outside this chat will read.

gavishap Updated Sep 21, 2026

File contents

Stakeholder update writing

Every outward-facing deliverable must read like the user wrote it themselves. Apply these rules on top of the vendored humanizer skill.

The rules

Humanizer pass. Run the humanizer skill (vendored at .claude/skills/humanizer) over the final text. Hard constraints from it: no em dashes, straight quotes, sentence-case headings, no bold-colon bullet lists, active voice.
First person singular. The user writes as "I" unless they tell you the update speaks for a team.
Quote literal system values when they appear inline in prose: error strings, button labels, status names ("Not Found", "Begin Validation"). Table and field names used descriptively stay unquoted.
Tables over walls of text. Per-record results, change lists, and field references go in tables. Prose is for explanation only.
Keep the identifiers. Record ids, amounts, file names stay in — readers navigate by them. Code internals (function names, branches, diffs) stay out unless the audience is engineers.
Questions live in the message, not the report. Anything needing the audience's call goes in the chat/email message only; an attached report states facts and never poses questions, so nothing is asked in two places.
Match the user's voice. Before drafting, check Wiki/ entity notes or past updates for their register (openers, contractions, sign-offs) and mirror it. Ask if you have no sample.
ETAs are the user's to promise. Draft dates as proposals they can edit, and say in chat that a date is a commitment they'd be making.

Order of work

Draft the content first (facts, tables, numbers verified against the vault), apply rules 2–8, then run the humanizer loop last and fix what it catches.

---name: stakeholder-update-writingdescription: Style rules for outward-facing deliverables — client/team chat messages, status reports, results write-ups, meeting follow-ups. Use whenever drafting an update, delivery message, or report that people outside this chat will read.---# Stakeholder update writingEvery outward-facing deliverable must read like the user wrote it themselves.Apply these rules on top of the vendored `humanizer` skill.## The rules1. **Humanizer pass.** Run the `humanizer` skill (vendored at `.claude/skills/humanizer`) over the final text. Hard constraints from it: no em dashes, straight quotes, sentence-case headings, no bold-colon bullet lists, active voice.2. **First person singular.** The user writes as "I" unless they tell you the update speaks for a team.3. **Quote literal system values** when they appear inline in prose: error strings, button labels, status names ("Not Found", "Begin Validation"). Table and field names used descriptively stay unquoted.4. **Tables over walls of text.** Per-record results, change lists, and field references go in tables. Prose is for explanation only.5. **Keep the identifiers.** Record ids, amounts, file names stay in — readers navigate by them. Code internals (function names, branches, diffs) stay out unless the audience is engineers.6. **Questions live in the message, not the report.** Anything needing the audience's call goes in the chat/email message only; an attached report states facts and never poses questions, so nothing is asked in two places.7. **Match the user's voice.** Before drafting, check `Wiki/` entity notes or past updates for their register (openers, contractions, sign-offs) and mirror it. Ask if you have no sample.8. **ETAs are the user's to promise.** Draft dates as proposals they can edit, and say in chat that a date is a commitment they'd be making.## Order of workDraft the content first (facts, tables, numbers verified against the vault),apply rules 2–8, then run the humanizer loop last and fix what it catches.

Frequently asked questions