Data & Ops/First-party starter playbook

Weekly stakeholder update

Draft a source-linked weekly update from project systems for human review.

// what it does
  1. 01Gather the week's evidence. Pull merged pull requests and releases from GitHub, completed and changed work from Linear, and relevant plans or prior updates from Notion for the reporting period.
  2. 02Reconcile the sources. Group activity by outcome rather than tool, link related pull requests and issues, and distinguish completed work from work that merely changed status. Note unavailable sources instead of hiding them.
  3. 03Find what matters. Identify shipped outcomes, measurable impact when the source proves it, current risks, blocked decisions, and next-period priorities. Leave routine activity out unless it changes a commitment.
  4. 04Check continuity. Compare the draft against the previous update so commitments, renamed work, and unresolved risks do not disappear or get reported twice.
  5. 05Draft for the audience. Write a scannable update with sections for outcomes, impact, risks and decisions needed, and next priorities. Link every material statement to its GitHub, Linear, or Notion source.
  6. 06Save for review. Create a draft in the configured Notion destination, clearly marked as not yet published, and include a source appendix and any coverage gaps.
  7. 07Hand off. Post a short Slack message with the draft link, the top outcome, and any decision needed. Do not post the full update as final copy.
// guardrails in the draft

Draft and hand off; never represent the update as approved or publish it externally.

Never infer business impact, dates, or completion from activity volume alone.

Do not expose confidential issue, repository, or document details beyond the configured audience.

Preserve unresolved risks and prior commitments until a source shows they were resolved or intentionally dropped.

If a source is unavailable, label the update's coverage as incomplete instead of filling the gap from memory.

Before you publish this playbook

Playbook updated

Agree on the reporting window and source of truth

Use this playbook when a weekly stakeholder update requires gathering evidence from GitHub, Linear, and Notion, then saving a draft in Notion and sharing its review link in Slack. Define the project scope, reporting window, audience, and destination before testing the schedule. Name which sources establish progress, which capture decisions, and who resolves disagreements between them. More connected records do not automatically make a more accurate report.

Keep the output grounded in the available source material. A closed issue, merged change, and released feature may represent different stages of work. Tell the draft how your team distinguishes them, and require source links that let a reviewer check the statements. Missing data should be called out as missing rather than replaced with a confident project status.

Review a draft against the underlying work

Test a week with normal progress, a week with a blocker, and a week with little activity. Open a sample of the source links and compare the draft with the records they cite. Check whether the reporting window excludes older work and whether the proposed update separates completed work from plans. Ask the owner to identify any sentence that implies a commitment nobody has made.

The playbook is for a human-reviewed update, not an unreviewed external broadcast. Confirm the intended Slack destination and the approval behavior before scheduling live runs. A useful result saves gathering and drafting effort while leaving the final judgment with the reviewer. Measure how much correction remains necessary and revise the source scope or instructions when the same misunderstanding appears in successive drafts.

Make weekly stakeholder update yours.

Request access and we'll start with a private draft. You keep control of the tools, permissions, tests, and publication decision.