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 r...
Scanned 9/19/2026
Install to Claude Code
npx -y skills add peter-tu-zynkr/zynkr-skill-builder --skill consult-launch-comms --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Consult Launch Comms?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/peter-tu-zynkr-consult-launch-comms)More formats (shields.io, HTML) on the badges page.
---
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"
house-style: bound
---
# 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)
- **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}`
## 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`
- **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:
`mcp__zynkr__update_deal` REPLACES `notes` wholesale, so append in three steps:
1. `mcp__zynkr__get_deal(id="<deal_id>")` — read the current `notes`
2. build the new value: the existing notes, then a blank line, then the block below
3. `mcp__zynkr__update_deal(id="<deal_id>", notes="<combined>", confirm=true)`
Call it once without `confirm` to preview, then again with `confirm=true`. Never
send `notes` without the existing text in front of it — the field is overwritten,
not appended, and skipping the read loses every earlier backlink.
### 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.
## House style
Writing style is **not owned by this file**. The house voice lives in two Google Docs under
`[@] 寫作指南` (`12DBdFz3SK22ie9im_ThFMI7IBRXsTZsV`), read at runtime:
- 《[2.0] Zynkr 通用風格指南 House Voice》 `10bOIQwRm9Pxwgct4hlwCwK_B4Pipai1HqBPZKzyRHSE` —
the universal core, plus the addendum for this surface
- 《[3.2] 禁用詞清單 Forbidden Words》 `1N5sHLP4qzmmhpCGsi6KElxi1z0MFe4QZ0Q_35T10Uyg`
Read both before producing client- or reader-facing text, and scan the draft against 《[3.2]》
before handing it over. If Drive is unreachable, say so in the output rather than proceeding
unchecked. Never re-implement either list inside this file.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!