Stakeholder comms
- When to use it
- Non-technical audiences: audience profiling, exec summaries, decision logs, and guides. Decks live in the design pack.
- Covers
- Explain it to decision makers (4)
- Where you decide
- No gated loop of its own; the skills run one at a time.
- Size
- 9 skills · 0 loops
30–60 minutes a session
npx skilldrop-cli install --pack stakeholder-comms
Installs 9 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack stakeholder-comms
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install stakeholder-comms@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack stakeholder-comms --ide cursor
Start here: Turn a long document into a one-page summary for leadership
Paste this into your agent:
Turn this design doc into a one-page executive summary for our steering committee: <paste the doc>.
- How to tell it worked
- exec-summary returns a one-page summary that a time-poor reader can act on in 30 seconds, written without jargon.
- If nothing happens
- If exec-summary does not activate, ask for it by name ("use exec-summary") and check that its folder exists in your skills folder (
~/.claude/skills/by default).
A typical session
When: You need to turn a long document or a meeting into something a non-technical or time-poor audience can act on. About 30–60 minutes.
You bring:
- the long document, such as a design doc or proposal
- notes or a transcript from the meeting where it was discussed
- who the audience is, such as a steering committee or an exec sponsor
-
- You
- Paste the meeting notes, thread or transcript.
- You get
- A structured log of decisions, action items, owners and due dates you can paste into a doc or tracker.
-
- You
- Say who will read it, in your own words.
- You get
- The audience archetype with its rules: length, density, tone, must-have sections and things to never include.
-
- You
- Hand it the long document, the decisions, and the audience profile.
- You get
- A one-page summary a time-poor reader can act on in 30 seconds, without jargon.
-
- You
- Run it on the summary before it goes out.
- You get
- A verdict and severity-tagged findings, such as a missing Ask, each with a suggested fix.
- You decide
- Ship, ship with the listed changes, or rewrite.
-
- You
- Run it on the final version.
- You get
- The text with machine artifacts stripped and any prose tells quoted with rewrites.
You end with: A decision log with owners and dates, and a reviewed one-page summary ready to send.
Compare Stakeholder comms with another pack
Skills in this pack (4)
- 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 slide-outliner and exec-summary. Use whenever a stakeholder communication deliverable is being designed for a specific audience. light
- decision-log Extract decisions, action items, owners, and due dates from meeting notes, Slack threads, design-review transcripts, or any unstructured discussion. Produces a clean structured log the user can paste into a doc, tracker, or ADR queue. Use when the user has notes/threads/transcripts and asks for a "decision log", "action items", "what did we agree", or "follow-ups". light
- exec-summary Compress a long technical document, design doc, or proposal into a one-page executive summary aimed at non-technical or time-poor stakeholders. Use when the user has a long doc and needs a 30-second readable version, or is writing a 1-pager for a steering committee, partner, or executive sponsor. standard
- guide-builder Turn raw notes, a spec, a thread or a messy procedure into a guide someone else can follow — a setup guide, a how-to, an onboarding walkthrough, or a reference for developers — in the length and voice its reader needs. Holds only what the notes say, marks anything inferred where it appears, orders steps so nothing is used before it is set up, and keeps open questions out of the guide so it can be sent as it stands. Use when the user wants setup or getting-started instructions, a walkthrough of how something works, or reference docs for an API or event schema — and it is NOT an SRE operational runbook (use runbook-generator) or a design proposal for review (use design-doc). standard
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard