Brainforge Knowledge

end-of-week-update-sop

13 min read

Standard Operating Procedure: End-of-Week Update

Title: End-of-Week Update
Version: 1.0
Date: 2026-03-13
Owner: GTM / Delivery

1. Purpose

This SOP standardizes the production of end-of-week updates for Brainforge clients. The update is a short, client-facing summary of what was completed this week, with optional in-progress items, blockers, and next week preview. It is used to close the loop with clients at the end of the week and can be sent by email or pasted into Slack.

The end-of-week-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 “Progress This Week → Completed”; emphasis is on completed work. 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_end-of-week-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

  • End-of-week format: Summary (1–2 sentences), Completed this week (main section, domain-grouped bullets), optional In progress / carry-over, optional Blockers, optional Next week preview, optional Questions or discussion topics, optional 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, Completed this week (and optionally In progress) may use bold subheaders by domain (e.g. E-commerce/Shopify, Wholesale, Retail, Connectors/Polytomic, Omni BI, Documentation) with bullets under each.
  • 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”, “log this week’s update”), prepend a dated section with that content; create the file if missing. For end-of-week entries, use a clear label in the section heading: ## YYYY-MM-DD — End of week. 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. 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 end-of-week: Overview, Wins this week, In progress, Blocked, Next Week, References. Require a nice opening message (warm greeting, e.g. “Happy Friday, team!”, 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 Friday, include transcripts from the past 7 calendar days). Use this window to infer what was completed this week.
  • 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, next week 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 and completion-focused.

6. How to Run

Preferred: Use the Cursor command — type / in Cursor chat and select the end-of-week-update command (stored in .cursor/commands/end-of-week-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 end-of-week update” or “Create end-of-week updates” in chat. The agent will prompt for target client(s), then run the same procedure.

Multi-agent (per-client) mode: When the end-of-week-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/end-of-week-update-sop.md.

7. Step-by-Step Procedure

  1. Confirm target client(s). If not provided, ask: “Which client(s) do you want end-of-week 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 and completed issues (e.g. Done state) to infer what was completed this week. 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. Prefer client-dedicated meetings and standups/delivery syncs that discuss the client.
    • Slack: Use Supabase MCP first (Slack project, 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. Use results to enrich completed work, in-progress items, 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 completions, signoffs, priorities). Be explicit and verbose so the CSO can decide what to add or drop.

    Then use the structure from email-update-template.md “Progress This Week → Completed” adapted to end-of-week format:

    • Summary (1–2 sentences); emphasize what was completed this week.
    • Timeline / Milestones (optional one-line or short block): From Linear projects and milestones, include target dates and any overdue/at-risk callouts if relevant. Omit if the client has no projects/milestones or not needed for end-of-week.
    • Completed this week (bullets). Primary section. Prefer domain-grouped structure when workstreams are distinct; use bold subheaders and bullets under each. Include links (PRs, sheets, changelog) when present in gathered context or user input.
    • In progress / carry-over (optional bullets). Items that will continue into next week; keep brief.
    • Blockers (short note if any). Use category sub-headers when there are multiple types.
    • Next week preview (optional, short bullets). What the team plans to focus on next; keep concise.
    • 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. 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_end-of-week-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). 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, Wins this week, In progress, Blocked, Next Week, References), nice opening message (e.g. “Happy Friday, team!”), 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 — End of week 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 and completion-focused; sections are concise and client-facing.
  • Structure matches end-of-week format (Completed this week as primary; optional In progress, Blockers, Next week preview, Questions).
  • When context supports it: draft uses domain grouping and includes links where available.
  • 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. (3) Add a row to the end-of-week-update command’s client/path mapping table (.cursor/commands/end-of-week-update.md) and to standards/04-prompts/client-vault-mapping.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-13). Purpose, scope, end-of-week format (Completed this week primary), step-by-step procedure, quality checks, optional add-to-log with “End of week” label. Parallel to weekly kick-off workflow; reuses same context gathering and client mapping.
  • v1.1 — Slack format: bold headers, standard header set (Overview, Wins this 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