Brainforge Knowledge

standup-deck-sop

5 min read

Standard Operating Procedure: Standup Deck (Weekly Sync Presentation)

Title: Standup Deck — Weekly Sync Presentation
Version: 1.0
Related: meeting-prep.md, meeting-summary-agent.md

1. Purpose

Prepare a client-facing, presentation-style deck for a recurring weekly standup with a named client. The output is ephemeral (chat only); no file is saved in this version. The workflow reduces deck prep time by reusing context from the latest same-type sync, the client’s Linear board, and (when available) Slack.

2. Scope

  • Applies to: When the user asks to prepare a deck or presentation for a recurring weekly sync (or standup) with a client. Uses vault transcripts + Linear; Slack is optional when/if available.
  • Output: A single deck rendered in the Cursor chat thread: Agenda (titles only) + per-topic Summary and Next Steps. Client-facing only; no Linear ticket IDs, URLs, parenthetical keys, or tracker-style tails on bullets; no internal-only content.
  • Does not apply to: Saving the deck to a file (v1 is ephemeral); automated Slack/email send.

3. Definitions

  • Carry-over topics: Topics that have action items, blockers, or next steps from the latest same-type sync, or that are not yet closed (from transcripts + Linear). No Linear ticket IDs in client-facing text.
  • Presentation-friendly: Agenda = topic titles only (no summaries). Each topic section = short Summary (bullets: what’s done/decided, blockers) + Next Steps (bullets: ongoing or planned; can be blank if to be discussed in meeting).
  • Client-facing only: Exclude Linear ticket IDs (e.g. LMN-123), linear.app issue URLs, parenthetical (TEAM-###), tracker-style tails (e.g. (LMNT-167) today Apr 17), internal channel discussions, and internal jargon unless relevant to external stakeholders.

4. Prerequisites

  • Access to brainforge-platform repo (playbook + vault) for transcripts and meeting notes.
  • Linear MCP enabled when available (see README.md). Used to gather open/blocked work for the client team; IDs are not surfaced in the deck.
  • Client/path mapping: use the same table as meeting-prep.md and the meeting-prep skill (e.g. Eden → knowledge/clients/eden/, LMNT → knowledge/clients/lmnt/). If the client is not in the table, list knowledge/clients/ and match the closest folder.

5. Step-by-step procedure

Step 1 — Identify client

Extract the client name from the user’s request. Resolve to a folder under knowledge/clients/ using the mapping in meeting-prep.md or the meeting-prep skill. If unsure, list knowledge/clients/ and pick the closest match.

Step 2 — Gather context (in this order)

2a. Latest meeting sync (same client/topic)

  • List knowledge/clients/{client}/transcripts/ and knowledge/clients/unassigned/transcripts/.
  • Filter by filename or (if needed) by title/content for recurring sync: e.g. “weekly”, “standup”, “sync”, “recurring” (and client name when relevant).
  • Take the most recent 1–2 transcripts that match. If none match, use the most recent 1–2 transcripts for this client and note in chat: “No same-topic filter applied; used most recent client transcripts.”
  • Read and extract: topics, decisions, action items, blockers, next steps. Apply meeting-summary-agent.md name/software disambiguation when interpreting transcript content.

2b. Client Linear board

  • If Linear MCP is available: call list_teams (if needed to resolve names), then list_issues for the team matching the client.
  • Use open/blocked issues to enrich topics and next steps. Do not include Linear issue IDs in the deck; use plain-language titles/descriptions only.

2c. Slack (optional)

  • Slack context uses Supabase first, Slack MCP as fallback. Use Supabase MCP (Slack project, client/internal tables) per supabase-context-agent.md. If Supabase is unavailable, errors (including permission denied/auth), or is insufficient, always run Slack MCP fallback in the same workflow per slack-mcp-context.md. Include only client-relevant, external-stakeholder-safe points. If neither is available, omit or note in chat: “Slack not queried; add context manually if needed.”

Step 3 — Produce list of carry-over topics

From transcripts + Linear, build a list of topics that:

  • have open action items, or
  • have blockers, or
  • have next steps, or
  • are not yet closed.

Present this list in chat with a short reason per topic (e.g. “has open action items”, “blocker”, “not closed”).

Step 4 — Ask user for focus topics

Ask: “Any specific topics you want to focus or highlight in this deck?”

Incorporate the user’s answer when building the final deck (e.g. order, emphasis, or extra bullets). If they say “no” or skip, use the carry-over list as-is.

Step 5 — Generate output in chat only

Produce the deck in the chat thread only. Do not create a markdown file.

Output format (exact structure):

  1. Agenda

    • Bulleted list of major topic titles only. No summaries in this section.

  2. Per-topic sections (one section per topic)
    For each topic:

    • Topic title (as heading or bold)
    • Summary — Short bullets: what’s done/decided, blockers. Client-facing language only.
    • Next Steps — Short bullets: ongoing or planned tasks. Leave blank if action items are to be discussed in the meeting.

Rules for the output:

  • Client-facing only: no Linear ticket IDs, URLs, parenthetical keys, or tracker-style tails; no internal channel details unless relevant to external stakeholders.
  • Keep content short and scannable: bulleted lists, avoid long sentences.
  • Omit a topic section if there is no content to show; do not pad with “None” or filler.

6. Cross-references

  • Client/path mapping and sources: meeting-prep.md and the meeting-prep skill (.cursor/skills/meeting-prep/SKILL.md).
  • Transcript interpretation (names, software, hierarchy): meeting-summary-agent.md.

Graph View