Stakeholder comms pack reference

Every skill in the Stakeholder comms pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

Non-technical audiences: audience profiling, exec summaries, decision logs, and guides. Decks live in the design pack.

Skills

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.

Tier light · v0.1.1 · SKILL.md · skill page

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

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

Not for:

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

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.

Tier light · v0.1.1 · SKILL.md · skill page

Use it when the user has notes/threads/transcripts and asks for a "decision log", "action items", "what did we agree", or "follow-ups".

A good result:

• Don't invent ownership. If the source says "we should email the legal team", don't pick a name. Flag as unowned.
• Don't promote opinions to decisions. "I think we should use Postgres" is not a decision unless the group acknowledged it.
• Quote, don't paraphrase, the source column. A 5–10 word verbatim snippet is the audit trail.
• Active voice in the action column. ✅ "Send PR for ADR-0007 to legal" — ❌ "ADR-0007 to be sent to legal".
• Convert relative dates. Today's date is needed — ask if unclear.

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.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it 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.

A good result:

• Quantify or qualify. Numbers are best ("\$2.4M ARR at risk"), but if you don't have numbers, say "directional" rather than inventing precision.
• Plain language. A non-engineer should not encounter a term they don't recognize in the first paragraph.
• No internal-team-speak. "OKRs", "swimlanes", "north-star metric" are okay; "sharding strategy", "eventually consistent", "blue-green" need translation or replacement.
• Active voice, second person where natural. "You'll need to approve the budget" beats "budget approval will be required".

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.

Tier standard · v0.2.0 · SKILL.md · skill page

Use it 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).

A good result:

• Every fact in the guide is in the notes; every inference is marked where it appears.
• The guide can be sent as written: no questions, internal notes or to-do markers in it.
• A reader following top to bottom never uses something before it is set up.
• One action per step; success checks only where the notes give them.
• References say "not stated" rather than guessing types, required fields or meanings.
• Length and voice fit the reader asked for.

Not for:

• SRE operational runbook — incidents, on-call escalation, deploy/rollback, SLOs → runbook-generator.
• Proposing a design for review/approval — options, trade-offs, risks, rollout → design-doc.
• Compressing a long doc for an exec audience → exec-summary.
• Raw unstructured mess that isn't ready to shape (a transcript, a Slack thread) → run brief-intake first, then come back.

Included from core

Installed with this pack. Details: Core pack reference.

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

Edit this page on GitHub · View source