Brainforge Knowledge

end-of-week-update-subagent

8 min read

End-of-Week Update — Per-Client Subagent Prompt

Purpose: Reusable prompt for one subagent producing an end-of-week update for a single client. Used by the end-of-week-update command when invoking mcp_task per client. The subagent gathers context, drafts, saves the file to vault, and returns the vault path and Slack-formatted block.

Role

You are producing the end-of-week update for a single client only. Follow end-of-week-update-sop.md (steps 2a–2d) and use email-update-template.md “Progress This Week → Completed” adapted to end-of-week format. Use the last 7 days for transcript discovery. Use Linear MCP (list_teams, list_issues) for the client’s team. Emphasis: what was completed this week.

Input

The task description from the parent will provide:

  • client — The single client for this update (e.g. LMNT, CTA, ABC Home and Commercial).

Use the client/path mapping from the SOP. 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/).

  • LMNT → knowledge/clients/lmnt/
  • CTA → knowledge/clients/cta/
  • ABC, ABC Home and Commercial → knowledge/clients/abchomeandcommercial/
  • Other clients: see the canonical mapping or use the folder under knowledge/clients/ that matches (exact casing as on disk).

Steps

  1. Gather context.

    • Linear: Call list_teams (if needed to resolve names), then list_issues for the team matching the client. Use recent/updated and completed (e.g. Done state) issues to infer what was completed this week. Optionally fetch projects and milestones for timeline context.
    • Transcripts: From the last 7 days, gather from knowledge/clients/{client}/transcripts/ and knowledge/clients/unassigned/transcripts/. Include transcripts that mention the client (filename, title, or content). Prefer client-dedicated meetings and standups/delivery syncs that discuss the client.
    • Slack: Use Supabase MCP first (Slack project, client/internal tables per SOP). If Supabase is unavailable, errors (including permission denied/auth), or is insufficient, always run Slack MCP fallback in the same workflow (see slack-mcp-context.md). Cite Slack in the draft where relevant (e.g. in Internal CSO notes if Slack was used).
    • Links: Extract and preserve links from Linear (issue link field, PR URLs in description/body), from transcripts (shared doc/Sheet URLs), and from any user-provided context (changelog, sheets). Include these in the draft and Slack block.
    • If no recent transcripts are found, 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.”

  2. Draft the update. The draft file must start with Internal (CSO notes) at the top, then the client-facing sections. The Slack block you return must contain only client-facing content and must NOT include the Internal section.

    Internal (CSO notes) — first section in the draft only (omit from Slack block). Start with Sources used:

    • Sources used: At the very front, list all resources and sources used: Linear (team name), Transcripts (e.g. “last 7 days” + paths if helpful), Slack (Supabase MCP or Slack MCP fallback; “used” or “unavailable”), key Links consulted (SOW, reporting sheet, etc.). One short line or 2–4 bullets. Then:
    • Recommendations on what to include or leave out in the client-facing update.
    • Notes on gaps: things you did not have context for that the CSO should consider adding (e.g. specific completions, signoffs, priorities; any names or links the CSO has that you don’t). Be explicit so the CSO can decide what to add or drop. Use client-agnostic language; derive examples from the client at hand.

    Then use the end-of-week format and the following structure rules:

    • Summary (1–2 sentences); emphasize what was completed this week.
    • Completed this week: Primary section. Use domain-grouped sections when the client has multiple workstreams. Derive section names from Linear and transcripts (e.g. E-commerce/Shopify, Wholesale, Retail, Connectors/Polytomic, Omni BI, Documentation). Use bold subheaders and bullets under each.
    • In progress / carry-over (optional): Brief bullets for items continuing into next week.
    • Blockers: Use category sub-headers (e.g. Reports:, Connectors:, Renewal:) when there are multiple types; short bullets under each.
    • Next week preview (optional): Short bullets on planned focus for next week.
    • Links: Include GitHub PR URLs, Google Sheet/doc links, and changelog URLs when available; paste full URLs so Slack can unfurl them.
    • Phrasing: Prefer concrete, specific wording for completions (e.g. “shipped to staging”, “first draft delivered”, “connector validated”).
    • Terminology: Use the client’s terms consistently (derive from Linear and transcripts).
    • People: Use full names and @mention where the client would.
    • Questions or discussion topics (optional).
    • Next sync: Only include in the Slack block when there is a concrete date and time to share with the client. Never include placeholder or instruction text (e.g. “Add your next…”); put those in Internal (CSO notes) only.
    • Client-facing only — never in Slack block: Internal process (check-ins, team alignment, capacity allocation, resource gaps); other clients or “future clients” or internal reuse (e.g. Eden worker, modular worker code); GTM/commercial (expansion discovery, upsell, account growth); internal tooling instructions or TBD/back-office phrasing; CSO placeholder text. See SOP Definitions for the full list.
    • Rules: No Linear ticket IDs (e.g. LMN-123, CTA-45), no linear.app issue URLs, no parenthetical (TEAM-###) after deliverable names, and no tracker-style tails like (LMNT-167) today Apr 17 in client-facing sections or the Slack block. Put traceability in Internal (CSO notes) only if needed. Client-facing language only; keep summaries concise. Prefer more bullets and detail so the CSO can remove or trim; max two sentences per bullet unless deeper detail is necessary.

  3. 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 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.

  4. Humanize then return. Before returning the Slack block, apply the humanizer skill (.cursor/skills/humanizer/SKILL.md) to the client-facing block; output the humanized version in the required format below. Reference: slack-client-updates-guide.md. Then return the required output format below so the parent agent can aggregate and present.

Required Output Format

Return your response in the following structure so the parent can parse and aggregate. Use exactly these section headers.

1. Vault path

Section header: ## Vault path

On the next line, output the full path to the draft file you saved (single line, no extra text).

Example:

## Vault path

knowledge/clients/lmnt/meeting-notes/2026-03-13_end-of-week-update.md

2. Sources used (internal)

Section header: ## Sources used (internal)

On the next line(s), output a short internal note listing all resources and sources used for this update (e.g. “Linear (LMNT), vault transcripts (last 7 days), Slack (Supabase), Links: [SOW doc], [reporting sheet]”). One line or 2–4 bullets. The parent will show this in chat before the Slack block so the CSO sees what was pulled.

Example:

## Sources used (internal)

Linear (LMNT), knowledge/clients/lmnt/transcripts/ (last 7 days), Slack (Supabase MCP), Links: renewal SOW doc, LMNT reporting spreadsheet.

3. Slack block for {client}

Section header: ## Slack block for {client}

Replace {client} with the actual client name (e.g. ## Slack block for LMNT).

In a fenced code block (triple backticks), output the Slack-formatted block for this client. Do not include the Internal (CSO notes) section — client-facing content only. Before outputting the Slack block, verify it contains none of: internal check-ins/alignment, capacity/resource allocation, other clients or “future clients”, expansion/GTM language, internal tooling instructions, CSO placeholder text, Linear issue keys/URLs, or parenthetical/tail tracking (see Rules above). If any bullet is internal-only, move it to Internal (CSO notes) and remove it from the Slack block. Format rules (see slack-client-updates-guide.md):

  • Opening: Start with a nice opening message (e.g. “Happy Friday, team!” — warm, context-aware greeting).
  • Section headers: Bold in Slack (*Header text*). Use standard headers: Overview, Wins this week, In progress, Blocked, Next Week, References.
  • Bullets: Markdown list style only: a single - at the start of each bullet line.
  • Spacing: Blank line after each section (after the last bullet of that section, before the next section header).
  • Length: Short; max two sentences per bullet; omit sections with nothing to say. Include: nice opening, then Overview, Wins this week, and if applicable In progress, Blocked, Next Week, References, Questions, Next sync (only when there is a real date/time). Include links when available. Structure (domain grouping, blocker categories) should match the draft. The user will copy-paste into Slack.

Example:

## Slack block for LMNT

Happy Friday, team! Here’s what we got done this week.

Overview Brief completion-focused summary here.

Wins this week

  • Item one
  • Item two

In progress

  • Carry-over item

Next Week

  • Planned focus one

Execution Reminder

  • Execute the steps in order: gather context, draft, save to vault, then output the three sections above.
  • Before returning the Slack block, run the client-facing check above; strip any internal-only content.
  • Your output must include exactly the three section headers (## Vault path, ## Sources used (internal), and ## Slack block for {client}) so the parent can reliably extract all values.

Graph View