consult-launch-comms git:20260816.5c37a02A

Immutable. This exact content never changes and is served at /api/v1/blob/481955be685c1e95.

---
name: consult-launch-comms
sheetId: "2.42"
description: >-
  Draft the go-to-market communications for a consulting engagement's rollout —
  the client-internal 上線公告 (rollout announcement) and the 說明會 invite,
  written in the client sponsor's voice, filed as [Comms] Google Docs in the
  client's numbered [N] Drive project folder and backlinked to the CRM deal —
  plus an optional, ask-only ANONYMIZED case-study seed handed to the public
  content pipeline. Trigger on /consult-launch-comms or when Peter says
  "寫導入上線公告", "幫客戶寫內部宣布信", "上線溝通信", "寫說明會邀請",
  "draft the rollout comms", "write the launch announcement for the client",
  or "internal rollout email". Distinct from content-newsletter-draft (Peter's
  OWN weekly newsletter to his audience), from consult-info-session (RUNS the
  說明會 this skill's invite announces — event ops live there), and from
  social-publish-article / zynkr-content-writer (generic public publishers —
  the optional public leg HANDS OFF to them; this skill never posts). Drafting
  job only: it produces Docs and handoff packets, runs no event and publishes
  nothing itself.
category: sales-consultant
project: consult-launch-comms
platform: claude
status: Done
author: Peter Tu
input: "The engagement (deal URL / company name) + the shipped outcome (or the [N] folder's [BRD]/[Plan]/[UAT] docs), optionally the 說明會 date"
process: "Resolve engagement + outcome → draft 上線公告 + 說明會邀請 from templates (client-sponsor voice) → review gate → file both [Comms] Docs into the [N] folder + deal note → optional ask-only anonymized public-leg handoff to the content pipeline"
output: "Two filed [Comms] Docs (rollout announcement + info-session invite) linked on the deal, and optionally an anonymized case-study handoff packet for the content pipeline"
synergy:
  - "consult-info-session"
  - "social-publish-article"
  - "content-newsletter-draft"
---

# Consult Launch Comms

```bash
npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill consult-launch-comms
```

A build that ships but never gets announced dies quietly: the client's staff
keep the old process, the sponsor wonders where the ROI went, and the
engagement's best story is never told. This skill drafts the communications
that carry a rollout — the client-internal **上線公告** (what we introduced ·
what changes in your work · how to start in 3 steps · who to ask · one line of
vision) and the **說明會邀請** — both in the CLIENT sponsor's voice, filed as
`[Comms]` Docs in the client's numbered `[N]` Drive folder and backlinked to
the deal. On request only, it also packages an anonymized case-study seed and
hands it to the public content pipeline.

It is a **drafting job, strictly**: it produces Docs and handoff packets. It
runs no event (that's consult-info-session), sends no mail, and publishes
nothing public itself (that's zynkr-content-writer / social-publish-article).

## How this differs from its neighbours

- **content-newsletter-draft** — Peter's OWN weekly newsletter to his audience.
  This skill writes a CLIENT's internal comms; only its optional public leg
  even touches Peter's content world, and then only as a handoff.
- **consult-info-session** — RUNS the 說明會 this skill's invite announces:
  calendar, materials, attendance. This skill only drafts the invitation and
  leaves `{{TBD}}` markers for that skill to fill.
- **social-publish-article / zynkr-content-writer** — generic public
  publishers. The optional public leg HANDS OFF a packet to them; this skill
  never posts anywhere.

## Fixed facts (don't re-derive these)

- **Supabase project_id**: `uomieoqlkazknjgmfdda` (the shared Zynkr project; CRM tables are `crm_*`)
- **Google account** for all Gmail/Drive/Docs tools: `peter_tu@zynkr.ai`
- **Drive parent folder** (`[2.2] 業務與顧問部門：專案`, where numbered project folders live): `1hkXPX7OXPFOU0BcloPbJSFp8O0zArM8t`
- **CRM deal URL** for reports/backlinks: `https://platform.zynkr.ai/deals/{deal_id}`
- Over the Supabase MCP, `auth.uid()` is **NULL** — any SQL fallback write must
  carry explicit ids and never rely on defaults that read the session user.

## Hard rules

1. **Never create a competing folder.** No `[N]` folder ⇒ STOP and route to
   /consult-intake or /consult-project-specialist (step 1).
2. **Nothing is shared before the step-4 gate.** These words go out under the
   sponsor's name — Peter aligns with the sponsor before anything moves.
3. **Client-facing email is ALWAYS a Gmail draft** — if Peter asks to send
   either draft onward, use `mcp__google-workspace__draft_gmail_message`.
   Never send.
4. **ANONYMIZATION RULE (public leg).** The public case-study seed never names
   the client, their industry-identifying specifics, or numbers traceable to
   them — unless Peter confirms written client consent exists.
5. **The public leg is ask-only.** Offered once in step 6; never auto-built.

---

## Workflow

### 1 · Resolve the engagement and gather the shipped outcome

- **Deal** — from a `…/deals/{id}` URL, or by company name. Prefer
  `mcp__zynkr__get_deal` / `mcp__zynkr__list_deals`; fallback SQL via
  `mcp__supabase__execute_sql`:
  `SELECT id, name, notes, stage FROM crm_deals WHERE name ILIKE '%<company>%' ORDER BY created_at DESC;`
- **Folder** — the deal's `notes` carry a `專案資料夾：<url>` backlink; extract
  the folder id. If missing, list the parent
  (`mcp__google-workspace__list_drive_items`, folder_id
  `1hkXPX7OXPFOU0BcloPbJSFp8O0zArM8t`) and match `[N] Company（…）` by name.
- **No folder at all** → STOP (hard rule 1) and point at /consult-intake or
  /consult-project-specialist.

Then gather what actually shipped. List the folder
(`mcp__google-workspace__list_docs_in_folder`) and read what exists — `[UAT]`
first (what was proven to work), then `[Plan]`, then `[BRD]` — via
`mcp__google-workspace__get_doc_content`. Extract: what was introduced, whose
daily work changes and how, the first three concrete actions a staff member
takes, and where help lives. If the folder is thin, ask Peter for the
one-line outcome instead of guessing.

### 2 · Draft the 上線公告

Fill Template A in `./references/comms-templates.md` — sponsor voice
throughout (see the template's why-the-sponsor-signs note): 我們導入了什麼 /
從今天起你的工作哪裡不一樣 / 怎麼開始用（3 步）/ 遇到問題找誰 / 一句願景.
The 3 steps must each be startable in under a minute; the help contact is a
client-internal person, never Peter or Zynkr. If the sponsor's name/title is
unknown, mark it and ask at the gate — never guess.

### 3 · Draft the 說明會邀請

Fill Template B: 時間地點 / 為什麼值得來 / 會講什麼 / 帶著問題來. Take
date/time/place from Peter if he has them; otherwise leave `{{TBD}}` markers
verbatim — consult-info-session fills them when it schedules the event. The
agenda bullets mirror the 公告's "哪裡不一樣" points so the two documents
tell one story.

### 4 · GATE — present both drafts

Show both drafts in full, plus: the sponsor name/title used, any `{{TBD}}`
markers left, and any assumptions made about the outcome. Then **wait**.
Client-internal comms carry the client's voice — Peter aligns with the
sponsor before anything is shared (hard rule 2). Approve / adjust; re-gate
only if the substance (not phrasing) changed.

### 5 · File both Docs into the `[N]` folder + deal note

Create each Doc via the reliable two-step (direct create-in-folder returns
HTTP 400) — titles `[Comms] {{COMPANY}} — 上線公告` and
`[Comms] {{COMPANY}} — 說明會邀請`:

```
mcp__google-workspace__create_doc(
  user_google_email = "peter_tu@zynkr.ai",
  title   = "[Comms] {{COMPANY}} — 上線公告",
  content = "<filled template, placeholder-guide comment deleted>"
)
mcp__google-workspace__update_drive_file(
  user_google_email = "peter_tu@zynkr.ai",
  file_id     = "<doc id>",
  add_parents = "<the [N] folder id from step 1>"
)
```

Then append both URLs to the deal notes — prefer `mcp__zynkr__update_deal`
(read current notes, append, write back); SQL fallback:

```sql
UPDATE crm_deals
SET notes = COALESCE(notes,'') || E'\n\n上線溝通文件：\n[Comms] 上線公告 <doc url>\n[Comms] 說明會邀請 <doc url>'
WHERE id = '<deal_id>';
```

via `mcp__supabase__execute_sql(project_id="uomieoqlkazknjgmfdda", ...)` —
escape single quotes by doubling them (`O'Brien` → `O''Brien`).

### 6 · OPTIONAL — the public leg (ask, never auto)

Ask once: **"想要一份公開版案例種子嗎？（交給內容管線，不會直接發布）"** On
yes, build a handoff packet — anonymized per hard rule 4:

```
## Case-Study Handoff

**主題：** [one line — the process problem and what changed]
**核心洞見：** [the transferable lesson, no client specifics]
**匿名化的 before→after 數字：** [rounded/ratio-ized so they trace to no one]
**目標讀者：** [who this story helps]
```

Then point at `/zynkr-content-writer` (full article) or
`/social-publish-article` (social post) — each installable by swapping the
`--skill` value in this skill's install snippet. The packet is the handoff;
drafting and publishing happen entirely in those skills.

### 7 · Report

```
上線溝通已備妥：宏宇精密 — 報價流程自動化

| 產出 | 內容 |
|------|------|
| 上線公告 | [Comms] 宏宇精密 — 上線公告（<doc url>）|
| 說明會邀請 | [Comms] 宏宇精密 — 說明會邀請（<doc url>・日期 {{TBD}}）|
| CRM backlink | <deal url> — notes 已附兩份文件連結 |
| 待 Peter | 與 sponsor 對稿後由客戶內部發出・說明會排程 → /consult-info-session |
| 公開案例 | 未啟動（step 6 詢問後 Peter 未要求）|
```

---

## Why it's built this way

- **The sponsor signs, not Zynkr.** Adoption reads internal, not vendor: staff
  act on a note from their own manager; the same words from an outside
  consultant read as marketing. Peter drafts, the client owns the voice.
- **Draft here, run there.** Comms freeze once the sponsor aligns; event ops
  (calendar, materials, attendance) have their own cadence and live in
  consult-info-session — hence the `{{TBD}}` contract between the two skills.
- **Gate before filing.** These words carry the sponsor's name inside their
  own company; a wrong claim costs the sponsor credibility, not Peter. The
  gate is where that's still free to fix.
- **Public leg is ask-only + anonymized.** A client's internal win is not
  Peter's content by default; consent is a relationship fact only Peter can
  confirm. The skill therefore packages, asks, and hands off — never posts.
- **Shape-then-handoff, not write-it-all.** Borrowed from
  content-newsletter-draft: the skill that knows the context builds a
  structured packet; the pipeline that owns drafting/publishing takes it from
  there. No duplicated writing logic, no second publisher.

## Inference defaults (Peter overrides by just saying so)

- **Language** → zh-TW for both client-internal drafts; the case-study packet
  is zh-TW unless the target channel is English.
- **說明會 date unknown** → leave `{{TBD}}` and flag for consult-info-session;
  never invent a date.
- **Sponsor unknown** → drafted with a marked placeholder, resolved at the
  gate; never defaults to Peter.
- **Outcome source** → folder docs, `[UAT]` > `[Plan]` > `[BRD]`; a one-liner
  from Peter overrides all of them.
- **Doc titles** → `[Comms] {{COMPANY}} — 上線公告` / `— 說明會邀請`.
- **Public leg** → OFF; offered once in step 6, built only on a yes.

## Provenance

Pattern-borrowed from `content-newsletter-draft` (1.06) — structure only, no
copied content; no drift exposure.

## Reference files

- `./references/comms-templates.md` — the two zh-TW client-internal templates
  (上線公告 + 說明會邀請) with the placeholder guide and the
  why-the-sponsor-signs note; fill, then delete the guide comment.

## Limitations

- Drafts only: it never runs the 說明會 (consult-info-session), never sends
  mail (Gmail drafts at most), and never publishes anything public.
- Announcement quality tracks the `[N]` folder — a thin folder means the
  skill must ask Peter for the outcome rather than derive it.
- The public leg ends at the handoff packet; article/social production and
  their own gates live in the downstream skills.
- Actual delivery inside the client (which internal channel, when) is the
  sponsor's call — this skill can at most stage a Gmail DRAFT to the sponsor
  for handover.