Weekly Kick-Off Update — Per-Client Subagent Prompt

Purpose: Reusable prompt for one subagent producing a weekly kick-off update for a single client. Used by the weekly-kick-off-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 weekly kick-off update for a single client only. Follow weekly-kick-off-update-sop.md (steps 2a–2d) and use email-update-template.md adapted to kick-off format. Use the last 7 days for transcript discovery. Use Linear MCP (list_teams, list_issues) for the client’s team.


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 issues to infer last week’s progress and this week’s focus.
    • 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 meetings with who and purpose; signoff asks; priorities; concrete next steps like push for QA or create another report; connector status; 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 kick-off format and the following structure rules:

    • Summary (1–2 sentences).
    • Last week’s achievements: 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.
    • This week’s focus: Same domain grouping. Include Meetings Proposed as an optional section (bullet list of proposed meetings with who and purpose) when meetings are discussed.
    • Blockers: Use category sub-headers (e.g. Reports:, Connectors:, Renewal:) when there are multiple types; short bullets under each.
    • 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 (e.g. “first draft completed ready for testing”, “in client review”, “Connections made in Poly just need to start sync”) when context supports it.
    • Terminology: Use the client’s terms consistently (derive from Linear and transcripts; e.g. if they use a product or initiative name, match it).
    • People: Use full names and @mention where the client would (e.g. when introducing a lead or key contact).
    • Action items (optional table: Owner, Action, Due).
    • 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_weekly-kick-off-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-04_weekly-kick-off-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 Monday!” — warm, context-aware greeting).
  • Section headers: Bold in Slack (*Header text*). Use standard headers: Overview, Priorities (or “This week’s priorities”), Wins last 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, Priorities, Wins last week, This week’s focus, and if applicable Blockers, Meetings Proposed, Action items, 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 Monday! Here’s where we are and what we’re focusing on this week.

Overview Brief summary sentence here.

Priorities

  • Focus one
  • Focus two

Wins last week

  • Item one
  • Item two

This week’s focus

  • Focus one
  • Focus two

Execution Reminder

  • Execute the steps in order: gather context, draft, save to vault, then output the two 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.