Consult Flow Design

---
name: consult-flow-design
sheetId: "2.41"
description: >-
  Visualize a consulting engagement's operations on Lucid as a paired AS-IS /
  TO-BE process chart set — drawn from the engagement's own documents (session
  notes, 痛點 ledgers, [Plan] docs, BRD) and recorded back on the CRM deal.
  ALL drawing, editing, and lint mechanics are delegated to the installed
  product-flow-design skill; this wrapper adds engagement resolution, the
  as-is/to-be pairing discipline, chart naming, and CRM linkage. Trigger on
  /consult-flow-design or when Peter says "畫客戶的 as-is/to-be 流程",
  "客戶流程圖", "幫這個案子畫流程", "把客戶流程視覺化", "map the client's
  operations on Lucid", "visualize the engagement workflow", or "draw the
  as-is and to-be for this client". Distinct from product-flow-design (the
  generic Lucid specialist — any chart, no engagement context; a pasted Lucid
  URL with no client context still routes THERE), from
  consult-solution-planning (produces the [Plan] narrative this skill draws),
  and from operations-flow-optimization / operations-transformation (they
  design the flow's CONTENT; this skill only visualizes what the engagement
  documents already say).
category: sales-consultant
project: consult-flow-design
platform: claude
status: Done
author: Peter Tu
input: "The engagement (deal URL / company name) — source docs are gathered from its [N] folder; optionally an existing Lucid URL to update"
process: "Resolve engagement + gather [Notes]/[Plan]/[BRD] docs → check product-flow-design installed → assemble as-is and to-be narratives (confirm) → delegate drawing + V1–V13 lint per chart → append both Lucid URLs to the deal notes → report"
output: "A paired [N] {{COMPANY}} — as-is / — to-be Lucid chart set drawn to the FE/BE/DB convention, lint-clean, with both URLs recorded on the CRM deal"
synergy:
  - "product-flow-design"
  - "consult-solution-planning"
  - "consult-brd-writer"
house-style: bound

---

# Consult Flow Design

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

An engagement's documents describe two processes: how the client works today
(session notes, 痛點 ledger 現況流程 fragments) and how they will work after
the build ([Plan] docs, BRD 目標流程). This skill turns those into the
engagement's visual deliverable — a **paired as-is / to-be Lucid chart set**
with matching swimlanes, so the delta reads at a glance — and records both
chart URLs on the CRM deal.

It is a **thin delegation wrapper**: every Lucid mechanic (swimlanes, Shape ×
Color encoding, layout, V1–V13 lint) belongs to the installed
`product-flow-design` skill and is exercised by invoking it, never by copying
it. What this wrapper owns is the consulting context: which engagement, which
documents, the two-chart pairing discipline, the naming, and the CRM record.

## How this differs from its neighbours

- **product-flow-design** — the generic Lucid specialist: any chart, no
  engagement context. A pasted Lucid URL with no client attached still routes
  there. This skill calls it; it never calls this skill.
- **consult-solution-planning** — produces the [Plan] narrative (the to-be in
  prose). This skill sits downstream and DRAWS that narrative.
- **operations-flow-optimization / operations-transformation** — design what
  the flow SHOULD BE. This skill designs nothing: it visualizes what the
  engagement documents already say, and stops when they say too little.

## 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 the report/backlink: `https://platform.zynkr.ai/deals/{deal_id}`

## Hard rules

1. **Never draw a to-be without an as-is beside it.** The comparison IS the
   deliverable. If Peter asks for one chart only, explain the pairing
   discipline and proceed single-chart only on an explicit confirm.
2. **Never touch Lucid directly.** All drawing, editing, and linting goes
   through an invocation of /product-flow-design. If it's not installed,
   hard-STOP (step 2). Do not re-derive its convention here.
3. **Never create a project folder.** No `[N]` folder ⇒ STOP and route to
   /consult-intake or /consult-project-specialist.
4. **Never draw before the step-3 narrative confirm.** Charts are expensive
   to redo (the Lucid create tool cannot restructure lanes in place).
5. **Client-facing email is ALWAYS a Gmail draft** — if Peter asks to send the
   charts to the client, draft via
   `mcp__google-workspace__draft_gmail_message`. Never send.

---

## Workflow

### 1 · Resolve the engagement and gather its documents

- **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. Point at /consult-intake (inbound lead) or
  /consult-project-specialist (meeting debrief). Hard rule 3.
- **Sources** — `mcp__google-workspace__list_docs_in_folder` on the `[N]`
  folder; read whatever exists of `[Notes]` session notes, 痛點 ledger,
  `[Plan]`, `[BRD]` via `mcp__google-workspace__get_doc_content`. If the
  material is too thin to support a chart (no 現況 description, or no 目標
  flow), say exactly what's missing and point at /consult-session-notes or
  /consult-solution-planning — never invent process steps to fill gaps.

### 2 · PRECONDITION — is product-flow-design installed?

Check the available-skills listing for `product-flow-design`. If absent,
hard-STOP and print its install snippet so Peter can install it — the same
command as this skill's own (top of this file) with
`--skill product-flow-design` instead. Nothing downstream works without it;
do not attempt to draw directly as a fallback (hard rule 2).

### 3 · Assemble the two process narratives — and confirm

From the gathered sources, write two ordered step lists (not charts — prose
narratives the base skill can draw from):

- **as-is** — from the 現況 material: session notes, ledger 現況流程
  fragments. Every step: actor · action · tool, plus a layer hint where the
  sources make it obvious (front-end touchpoint / manual vs system step /
  what gets stored where).
- **to-be** — from the 目標 material: the [Plan] doc, the BRD's target flow.
  Same actor vocabulary and same lane set as the as-is, so the two charts
  share a swimlane structure and the delta is visible, not just implied.
- Tag each step with its source doc — if a step appears in neither, it
  doesn't go in the narrative.

Present both narratives side by side for a quick confirm **before any
drawing** (hard rule 4). Peter adjusts in text, which is cheap; re-draws are
not.

### 4 · Delegate the drawing

For each confirmed narrative, **run /product-flow-design in draft mode**,
passing:

- the narrative (ordered steps with actor/tool/layer hints),
- the exact chart title — `[N] {{COMPANY}} — as-is` then
  `[N] {{COMPANY}} — to-be`, where `[N]` is the engagement's Drive folder
  number (so chart and workspace pair by eye),
- the instruction that both charts must use the **same lane structure**
  (same lanes, same order) even where one of them leaves a lane sparse.

The base skill owns everything visual: the FE/BE/DB swimlane scaffold, Shape
× Color encoding, register choice, fonts, PNG eyeball pass. Do not second-
guess its shape or color decisions here. If Peter supplied an existing Lucid
URL to update, delegate in **edit mode** against that document instead of
drafting a new one.

### 5 · Delegate the lint

Have /product-flow-design run its **validate** job (rules V1–V13) on both
charts. Any violation → fix via another delegated edit, then re-lint. Loop
until both charts come back clean. This wrapper never lints by itself — it
only relays the base skill's verdict.

### 6 · Record the chart links on the deal

Append both URLs to the deal notes — `mcp__zynkr__update_deal` preferred
(read current notes first, 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.

### 7 · Report — and offer, don't auto, the next step

A compact artifact table, then the delta in one sentence:

```
流程圖已產出：宏宇精密 — 報價流程自動化

| 產出 | 內容 |
|------|------|
| as-is | [4] 宏宇精密 — as-is（<lucid url>）· lint clean |
| to-be | [4] 宏宇精密 — to-be（<lucid url>）· lint clean |
| CRM backlink | <deal url> — notes 已附兩張圖連結 |
| 差異一句話 | 報價計算與追蹤信從人工（3 個 HITL 節點）改為系統自動，人只留最終核准 |
```

Then **ask** — never do unprompted: a proposal deck from the pair (via
/zynkr-slide), or /consult-brd-writer if the engagement has no BRD yet.

---

## Why it's built this way

- **Delegation, not a fork.** The FE/BE/DB convention is a living standard —
  six reference files and a V1–V13 lint that product-flow-design updates in
  one place. A copied-in version would drift the first week; a wrapper that
  invokes the installed skill inherits every improvement for free.
- **The pair is the deliverable.** A to-be alone is a proposal sketch; an
  as-is beside it, same lanes, is an argument. Consulting clients buy the
  delta — hence hard rule 1 and the shared-lane requirement in step 4.
- **Confirm narratives, not drafts.** Text is the cheapest medium to be wrong
  in. The Lucid create tool can't restructure lanes in place, so a wrong
  chart means a full re-draw — the step-3 gate spends minutes to save one.
- **Named after the workspace.** `[N]` in the chart titles mirrors the Drive
  folder number, so the chart set, the folder, and the deal cross-reference
  without a registry.
- **Sources over invention.** The moment this skill invents a process step,
  it stops being documentation and starts being (unreviewed) consulting.
  Content design belongs to consult-solution-planning and the operations
  skills; thin sources here mean STOP, not improvise.

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

- **Chart set shape** → two separate Lucid documents (the MCP create tool
  can't add pages to an existing doc); a two-page single doc only if Peter
  arranges the pages manually afterwards.
- **Register** → presentation-clean (these charts face the client); audit-
  detail on request.
- **Node-label language** → zh-TW, matching the engagement documents.
- **`[N]`** → the engagement's Drive folder number, read in step 1.
- **New vs update** → new charts; edit mode only when a Lucid URL is supplied.
- **Handoffs (deck / BRD)** → OFF; offered in step 7, run only on a yes.

## Provenance

Wraps `product-flow-design` (5.03) by delegation @ b6bfb04c (2026-08-03) — no
mechanics copied; breaks only if the base skill's invocation contract changes.

## Reference files

None shipped — deliberately. The FE/BE/DB three-layer model, the Shape ×
Color encoding table, the swimlane scaffold, and the V1–V13 lint rules live
single-sourced in product-flow-design's own reference files; this wrapper
invokes that skill rather than mirroring its knowledge, so there is nothing
local to drift.

## Limitations

- Visualizes documented state only — it will not design, optimize, or extend
  a flow (operations skills / consult-solution-planning), and it will not
  interview anyone to fill gaps.
- Chart quality is bounded by document quality: thin `[Notes]`/`[Plan]`
  material yields a STOP-and-route, not a speculative chart.
- Unusable without product-flow-design installed — all Lucid access flows
  through it, including lint verdicts this wrapper merely relays.
- One engagement per run; a portfolio-wide chart sweep is repeated runs.
- Records links on the deal but never emails the client — sharing is always a
  Gmail draft Peter sends himself.

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