Stakeholder Briefings

A stakeholder-briefings artifact takes one source (a PRD, a discovery synthesis, a research report, a GTM or launch plan, experiment results, a retro or incident write-up, or raw notes) and produces a single saveable file containing:

1. a master document: the canonical, audience-neutral synthesis of the work (what and why, decisions, status, risks and open questions, asks, timeline), with each claim numbered (M1, M2, ...); and
2. a set of audience briefings: the same content re-pitched for each chosen stakeholder, one self-contained, copy-paste-ready block per audience.

The skill runs master-first, then projects. The master is the single source of truth; every briefing is a projection of it. A briefing may omit, reorder, and translate master content, but it may never assert a claim that is not in the master. That projection rule is what keeps the executive version and the engineering version from quietly disagreeing, and it is the difference between this skill and asking a model to "rewrite this six ways."

Distinct from foundation-stakeholder-update (one async update of meeting outcomes for a single audience, meeting-bound), discover-stakeholder-summary (a map of who stakeholders are and their influence/interest), and foundation-persona (a customer/buyer viewpoint to design or market against).

When to Use

• One piece of work must reach several audiences who each need a different framing, decision, and level of detail (a spec going to engineering, design, data, and the funder at once).
• You are about to manually rewrite the same update three to five ways, one per audience.
• A decision or result needs to propagate across functions without the versions drifting apart.
• A single audience needs a tailored briefing from a non-meeting source (N=1 is supported; the fan-out is the signature use, not a floor).

When NOT to Use