Brainforge Knowledge

weekly-kick-off-update-sop

14 min read

Standard Operating Procedure: Weekly Kick-Off Update

Title: Weekly Kick-Off Update
Version: 1.0
Date: 2026-03-02
Owner: GTM / Delivery

1. Purpose

This SOP standardizes the production of weekly kick-off updates for Brainforge clients. The update is a short, client-facing summary of last week’s achievements and this week’s focus, with optional blockers, action items, and questions. It is used to align clients at the start of the week and can be sent by email or pasted into Slack.

The weekly-kick-off-update command (and rule) run this procedure: they ask for target client(s), gather context from Linear and recent transcripts (last 7 days), produce a draft saved to vault, and output a Slack-formatted block in the chat for copy-paste. The structure is based on email-update-template.md adapted for kick-off format (concise summary; no Linear ticket IDs in client-facing text).

2. Scope

  • Applies to: Brainforge clients with a Linear team and/or vault folder (e.g. LMNT, CTA, ABC Home and Commercial). Runs from the brainforge-platform repo (playbook + vault).
  • Outputs: (1) A markdown draft per client in knowledge/clients/{client}/meeting-notes/YYYY-MM-DD_weekly-kick-off-update.md. (2) A Slack-formatted summary per client in the Cursor chat thread (for manual copy-paste).
  • Does not apply to: Automated sending to Slack or email; the user copies the block or draft manually. Client repos are not the primary workspace unless the agent has access to brainforge-platform for playbook and vault.

3. Definitions

  • Kick-off format: Summary (1–2 sentences), Last week’s achievements, This week’s focus, Blockers (if any), optional Action items, optional Meetings Proposed, Questions or discussion topics, Next sync. Client-facing guard (Linear): No Linear ticket IDs (e.g. LMN-123, CTA-45), no linear.app issue URLs, no parenthetical issue keys after titles, and no tracker-style tails on bullets (e.g. (LMNT-167) today Apr 17). Use plain-language work descriptions; state deadlines in normal prose or a dedicated line—not glued to an issue key.
  • Domain-grouped sections: For clients with multiple workstreams, Last week’s achievements and This week’s focus may use bold subheaders by domain (e.g. E-commerce/Shopify, Wholesale, Retail, Connectors/Polytomic, Omni BI, Documentation) with bullets under each.
  • Meetings Proposed: Optional section listing specific proposed meetings (who, purpose); can supplement or replace a long Action items list.
  • Blockers: May use category sub-headers (e.g. Reports:, Connectors:, Renewal:) when there are multiple blocker types.
  • Links: When available from Linear, transcripts, or user-provided context, include relevant URLs (GitHub PRs, Google Sheets, changelog) in the draft and Slack block.
  • Weekly update log: Running history of finalized updates per client. Path: knowledge/clients/{client}/weekly-update-log.md. When the user confirms the final version (e.g. “add to log”), prepend a dated section with that content; create the file if missing. Entries are newest-first. Content: By default use the current contents of the draft file; if the user pastes or provides different final content, use that. Log entries are client-facing only — exclude the Internal (CSO notes) section so the log is safe to share.
  • Internal (CSO notes): A section at the top of the draft only (never in the Slack block). For the person running the update (e.g. CSO). Contains: recommendations on what to include or leave out; notes on gaps—things the agent did not have context for that the CSO should consider adding (e.g. missing meetings, signoffs, priorities, specific asks). Kept internal so the client does not see it.
  • Verbose draft: Prefer including more detail and more bullets in the draft so the CSO can remove or trim; do not over-summarize. Max two sentences per bullet unless deeper detail is necessary. The Slack block can be trimmed when copy-pasting if needed.
  • Slack-formatted block: Section headers in bold (Slack: *Section title*). Use the standard headers for kick-off: Overview, Priorities (or “This week’s priorities”), Wins last week, In progress, Blocked, Next Week, References. Require a nice opening message (warm greeting, e.g. “Happy Monday!”, human framing) and short copy; reference Greg’s example (external-client-default). Markdown bullets only (-), blank line after each section. Canonical format: slack-client-updates-guide.md.
  • Last 7 days: Calendar window for transcript discovery (e.g. if today is Monday, include transcripts from the previous Monday through Sunday, or the last 7 calendar days).
  • Client folder mapping: Canonical source: standards/04-prompts/client-vault-mapping.md. Use the exact path and casing from that file (e.g. LMNT → knowledge/clients/lmnt/, CTA → knowledge/clients/cta/). When adding a new client, add them to the canonical mapping first.
  • Client-facing (Slack block): Content the client may see. Limited to: work completed for them, in-progress items that affect them, blockers that need their action or awareness, this week’s focus, questions for them, concrete next sync date/time when known, and links to shared docs (e.g. SOW, reporting sheet) when relevant.
  • Internal-only (must NOT appear in Slack block):
    • Internal process: Internal check-ins, internal team alignment, capacity allocation, resource gaps, delivery team scheduling, “so the team stays aligned”.
    • Other clients / reuse: Do not mention other clients, “future clients”, “Eden worker”, “modular worker code” reused elsewhere, or any Brainforge-internal reuse.
    • GTM/commercial: Expansion discovery, upsell, “positioning for account growth”, or any commercial/GTM framing.
    • Internal tooling/back-office: Data Platform Documentation TBD fields, “will be filled once we have your input”, internal spreadsheets or process details unless the client already uses that doc and the phrasing is appropriate for them.
    • Instructions to CSO: No placeholder or instruction text (e.g. “Add your next recurring client check-in date and time here if you have it”). Put those only in Internal (CSO notes). Next sync in the Slack block: only include when there is a real date/time to share; otherwise omit the line or section.

4. Prerequisites

  • Cursor with Linear MCP enabled (see README.md). The agent uses list_teams and list_issues to gather board context.
  • Access to brainforge-platform repo (playbook + vault) for transcripts and meeting notes.
  • Target client(s) confirmed before proceeding (the command prompts if not specified).

5. Responsibilities

  • Person running the update: Chooses target client(s), reviews the draft and Slack block, and sends or pastes the update to the client (email or Slack) as appropriate.
  • Agent: Follows this SOP; gathers Linear and transcript context; produces draft and Slack block; does not include internal ticket IDs in client-facing text; keeps summaries concise.

6. How to Run

Preferred: Use the Cursor command — type / in Cursor chat and select the weekly-kick-off-update command (stored in .cursor/commands/weekly-kick-off-update.md). The agent will prompt for target client(s), then for each client run the procedure (gather context, draft, save, output Slack block).

Alternative: Say “Run weekly kick-off update” or “Create weekly kick-off updates” in chat. The agent will prompt for target client(s), then run the same procedure.

Multi-agent (per-client) mode: When the weekly-kick-off-update command is used with multiple target clients, the agent runs one subagent per client (in parallel). Each subagent gathers context, drafts, saves the file to vault, and returns the vault path and Slack-formatted block. The orchestrating agent aggregates and presents all Slack blocks (labeled by client) and the list of draft paths in the main chat. Single-client runs may also use one subagent for consistency.

Council: The command runs document council automatically on each draft (doc type: Client update (Slack), Stakeholder = client-specific — e.g. “LMNT sponsor”) before presenting the Slack block and council verdict. You can re-run or deepen the council if you edit the draft and ask the agent to “run council again.”

Canonical source for this SOP: standards/04-prompts/weekly-kick-off-update-sop.md.

7. Step-by-Step Procedure

  1. Confirm target client(s). If not provided, ask: “Which client(s) do you want weekly kick-off updates for? (e.g. LMNT, CTA, ABC Home and Commercial).”

  2. For each target client (in order):

    2a. Gather context.

    • Linear: Call list_teams (if needed to resolve names), then list_issues for the team matching the client. Also fetch projects and milestones for the client team: list_projects for the team (with includeMilestones: true or list_milestones per project). Use recent/updated issues to infer last week’s progress and this week’s focus. Do not include ticket IDs in the client-facing draft.
    • Transcripts: From the last 7 days, gather:
      • Assigned: knowledge/clients/{client}/transcripts/ (any transcript in that folder).
      • Unassigned: knowledge/clients/unassigned/transcripts/ — include any transcript whose filename or meeting title mentions the client, or whose content (search) mentions the client or relevant ticket prefixes (e.g. LMN-, CTA-). Prefer client-dedicated meetings and standups/delivery syncs that discuss the client.
    • Slack: Use Supabase MCP first (Slack project oqtkgsndvitzyfzwcdoz, client/internal tables per supabase-context-agent.md and schema-reference.md) for the last 7 days. If Supabase is unavailable, errors (including permission denied/auth), or is insufficient, always run Slack MCP fallback in the same workflow (slack_search_channels → slack_search_public, optional slack_search_public_and_private with user consent). Use results to enrich last week’s achievements, this week’s focus, blockers, and gaps. Note in Internal (CSO notes) if Slack was used. See slack-mcp-context.md for fallback usage.
    • If no recent transcripts are found for a client, still produce the update from Linear only and note in the summary or a short line: “No recent transcripts found; update based on Linear board.”

    2b. Draft the update.

    The draft file must start with Internal (CSO notes) at the top, then the client-facing sections below. The Slack block contains only the client-facing parts and must NOT include the Internal section. Client-facing sections and the Slack block must not contain internal-only content (see Definitions: internal process, other clients, GTM, internal tooling, Next sync placeholders).

    Internal (CSO notes) — first section in the draft only:

    • Sources used (at front): Start with a short list of all resources and sources used for the update: Linear (team name), Transcripts (date range, e.g. last 7 days; paths if helpful), Slack (Supabase MCP or Slack MCP fallback; note “used” or “unavailable”), and key Links consulted (e.g. SOW doc, reporting sheet). This gives the CSO a quick audit of what was pulled. Then:
    • Recommendations on what to include or leave out in the client-facing update.
    • Notes on gaps: things the agent did not have context for that the CSO should consider adding (e.g. specific meetings, signoff asks, priorities, “push for QA”, extra reports, SPINS/connector status, 2026 ingestion meeting).
    • Be explicit and verbose so the CSO can decide what to add or drop.

    Then use the structure from email-update-template.md adapted to kick-off format:

    • Summary (1–2 sentences).
    • Timeline / Milestones (optional one-line or short block): From Linear projects and milestones, include a “Timeline” or “Milestones” line (e.g. “Push Test to Production (target Apr 15); Single-page test start (Mar 22)”) and any overdue/at-risk callouts. Omit if the client has no projects/milestones.
    • Last week’s achievements (bullets). Prefer domain-grouped structure when workstreams are distinct (e.g. E-commerce/Shopify, Wholesale, Retail, Connectors/Polytomic, Omni BI, Documentation); use bold subheaders and bullets under each. Include links (PRs, sheets, changelog) when present in gathered context or user input.
    • This week’s focus (bullets). Same domain grouping when applicable. Include a Meetings Proposed section when meetings are discussed (list each meeting with who and purpose).
    • Blockers (short note if any). Use category sub-headers (e.g. Reports:, Connectors:, Renewal:) when there are multiple types.
    • Action items (optional table: Owner, Action, Due).
    • Questions or discussion topics (optional).
    • Next sync (optional).
    • Rules: No Linear ticket IDs in the body. Client-facing language only; keep summaries concise. Use the client’s terminology and concrete phrasing; use @mentions for people when appropriate. Prefer more bullets and detail so the CSO can remove or trim; max two sentences per bullet unless deeper detail is necessary.

    2c. Save the draft.

    Write to knowledge/clients/{client}/meeting-notes/YYYY-MM-DD_weekly-kick-off-update.md (use current date in YYYY-MM-DD). Use the exact path and casing from the canonical client-vault mapping (standards/04-prompts/client-vault-mapping.md), e.g. knowledge/clients/lmnt/ for LMNT. Create the meeting-notes folder if it does not exist.

    2d. Output in chat.

    Before presenting the Slack block: apply the humanizer skill (.cursor/skills/humanizer/SKILL.md) to the client-facing block; output the humanized version. For that client, output in the chat: (1) a short internal note at the front listing all sources used for the update (Linear, Transcripts, Slack, key Links — from the draft’s Internal “Sources used” or from the subagent’s returned “Sources used (internal)”); (2) then the Slack-formatted block: section headers in bold (*Header*), standard headers (Overview, Priorities, Wins last week, In progress, Blocked, Next Week, References), nice opening message (e.g. “Happy Monday!”), markdown bullets only (-), and a blank line after each section. Include only client-facing content in the Slack block. Do not include the Internal (CSO notes) section in the Slack block. Keep copy short; omit sections with nothing to say. The user should be able to copy-paste the block into Slack. See slack-client-updates-guide.md.

  3. After all clients. State where the drafts were saved (full paths) and that the Slack-formatted blocks are above for copy-paste.

  4. Optional — Add to weekly update log. When the user confirms the final version (e.g. “add to log”, “log this week’s update”): by default use the current contents of the draft file; if the user pastes or provides different final content, use that. Prepend a section ## YYYY-MM-DD with that content to knowledge/clients/{client}/weekly-update-log.md; create the file if it does not exist (use a short title, e.g. “Weekly Update Log — {Client}”). Log entries are client-facing only — exclude the Internal (CSO notes) section. Newest week first.

  5. Optional — Re-run or deepen council. Council runs automatically in the command (Step 2e). If the user asks to re-run the council or go deeper after editing the draft, run the document-council skill on the draft file with doc type “Client update (Slack)” and client-specific Stakeholder. Output the verdict and key findings; optionally append a short “Stakeholder review” summary to the Internal (CSO notes) section.

8. Quality Checks

  • Each target client has a draft file and a Slack block.
  • Draft (client-facing sections) and Slack block contain no Linear ticket IDs (e.g. LMN-123, CTA-45), no linear.app issue URLs, no parenthetical (TEAM-###) after titles, and no tracker-style tails (e.g. (LMNT-167) today Apr 17).
  • Summary is 1–2 sentences; sections are concise and client-facing.
  • Structure matches kick-off format (Last week’s achievements, This week’s focus, plus optional Blockers, Meetings Proposed, Action items, Questions).
  • When context supports it: draft uses domain grouping, includes links where available, and includes Meetings Proposed or category sub-headed Blockers as applicable.
  • Draft starts with Internal (CSO notes) at the top; Slack block contains only client-facing content and does not include the Internal section. Before presenting the Slack block to the user, verify it does not contain “Internal” or “CSO notes”; if it does, strip that section.
  • Slack block contains no internal-only content: no internal process/capacity, no other clients or reuse, no expansion/GTM, no internal tooling instructions, no Next sync placeholder text.
  • Transcript discovery used the last 7 days and included both assigned and unassigned transcripts that reference the client.

9. Escalation Path

  • Unknown client or missing vault folder: Ask the user for the client name and, if needed, the correct vault path or Linear team name.
  • Adding a new client: (1) Create knowledge/clients/{ClientName}/ (and meeting-notes/ if desired). (2) Confirm the Linear team name matches (e.g. for “Eden” use team name Eden). (3) Add a row to the weekly-kick-off-update command’s client/path mapping table (.cursor/commands/weekly-kick-off-update.md) with exact casing for the vault path.
  • Linear MCP errors: Follow README.md; retry after checking auth/config. If unavailable, produce the update from transcripts only and note “Linear board not available; update based on transcripts.”
  • No transcripts and no Linear: Inform the user and ask for manual highlights or skip that client.
  • Subagent returns unexpected format: Surface the raw response, note the issue, and ask the user whether to retry that client or use the draft file if it was saved.

10. Version History

  • v1.0 — Initial draft (2026-03-02). Purpose, scope, step-by-step procedure, quality checks. References email-update template and weekly-kick-off-update command.
  • v1.1 — Domain-grouped sections, Meetings Proposed, blocker categories, links, client terminology (e.g. Omni BI), weekly update log and confirm-and-add workflow.
  • v1.2 — Internal (CSO notes) section at top of draft only (excluded from Slack block); verbose draft preference so CSO can remove or trim.
  • v1.3 — Vault path exact casing; add-to-log content (default draft file, client-facing only); max two sentences per bullet; add new client steps; Internal-leak check; optional stakeholder council after run.
  • v1.3.1 — No content change (deploy retrigger).
  • v1.4 — Linear context extended: fetch projects and milestones for client team (list_projects, list_milestones). Add optional “Timeline / Milestones” line to draft and Slack block (target dates and overdue/at-risk callouts).
  • v1.5 — Client-facing guardrails: Definitions for client-facing vs internal-only (Slack block); 2b/2d/8 enforce no internal process, other clients, GTM, internal tooling, or Next sync placeholders; aligned with end-of-week-update guardrails.
  • v1.6 — Slack format: bold headers, standard header set (Overview, Priorities, Wins last week, …), nice opening message, humanizer before output; canonical guide standards/02-writing/Communications/slack-client-updates-guide.md. Document council runs automatically in command (Client update (Slack), client-specific Stakeholder).

Graph View

Backlinks