git:20260816.5c37a02 to git:20260907.364596e

---

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"

---

# 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

- **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:

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