git:20260802.e35a1f5 to git:20260816.5c37a02

---

name: consult-solution-planning

sheetId: "2.40"

description: >-

Turn an engagement's discovery outputs — consult-discovery summaries,

consult-session-notes 痛點 ledgers, the client's stated goals — into a

structured solution plan: persona, operator journey, pains ranked by 影響範圍

size × 強度 intensity × 頻率 frequency, selected opportunities, MVP scope,

and success metrics — filed as a "[Plan]" Google Doc in the client's numbered

[N] Drive folder and ending in an explicit handoff block for

/consult-brd-writer. Operationalizes MrPM-Stanley's 產品企劃力

product-planning framework for consulting engagements. Trigger on

/consult-solution-planning or when Peter says "幫客戶做需求規劃",

"把痛點整理成方案規劃", "方案企劃", "規劃 MVP 範圍", "plan the client

solution", "turn the pains into a plan", or "solution planning for this

engagement". Distinct from product-planning (the generic mirror — raw product

idea in, no engagement context, no filing; use it outside engagements), from

consult-discovery / consult-session-notes (upstream producers of this skill's

inputs), and from consult-brd-writer (downstream — formalizes THIS skill's

plan into the client-grade BRD/PRD).

category: sales-consultant

project: consult-solution-planning

platform: claude

status: Done

author: "Peter Tu (derivative of MrPM-Stanley)"

input: "An engagement's discovery artifacts — consult-discovery summaries, consult-session-notes 痛點 ledgers — or a raw idea, plus the client (deal URL / company name)"

process: "Collect inputs + resolve the engagement → persona → journey → rank pains by size × intensity × frequency → select opportunities → MVP scope + metrics (one confirmed section at a time) → file the [Plan] Doc + CRM note → hand off to consult-brd-writer"

output: "A [Plan] solution-plan Google Doc (persona, journey, ranked pains, MVP scope, success metrics) in the engagement folder, linked on the deal, ending in a BRD handoff block"

synergy:

- "consult-discovery"

- "consult-session-notes"

- "consult-brd-writer"

- "product-planning"

upstream_repo: https://github.com/MrPM-Stanley/product-planning-skill

original_source_url: https://github.com/MrPM-Stanley/product-planning-skill/blob/main/README.md

original_author: "MrPM-Stanley"

---

# Consult Solution Planning

```bash

npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill consult-solution-planning

```

Between "we know where it hurts" (discovery summaries, 痛點 ledgers) and "the

client can sign this" (the BRD) sits a reasoning step nobody writes down: which

pains actually matter, what the smallest worthwhile build is, and how we'll

know it worked. This skill makes that step an artifact — it runs MrPM-Stanley's

產品企劃力 framework (persona → journey → pains ranked 影響範圍 × 強度 × 頻率

→ MVP → metrics) over the engagement's discovery material and files the result

as a `[Plan]` Google Doc in the client's `[N]` folder, linked on the deal.

It is deliberately interactive: every section is a checkpoint, mirroring the

upstream framework's confirm-as-you-go style — because a persona Peter doesn't

recognize or a score he'd contest poisons everything downstream of it.

## How this differs from its neighbours

- **product-planning** (5.02) — the faithful lift-and-shift mirror of the

upstream skill: raw product IDEA in, no engagement context, no filing, no

CRM. Use it outside engagements; use THIS skill inside one.

- **consult-discovery / consult-session-notes** — upstream producers: they

conduct the sessions and keep the 痛點 ledger. This skill consumes their

output; it interviews no one.

- **consult-brd-writer** — downstream: takes this skill's plan (via the BRD

Handoff block) and formalizes it into the client-grade BRD/PRD.

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

- Over the Supabase MCP, `auth.uid()` is **NULL** — every SQL write carries

explicit ids; never rely on defaults that read the session user.

## Hard rules

1. **Never create a competing folder.** No `[N]` folder for this client ⇒ STOP

and route to /consult-intake or /consult-project-specialist (step 1).

2. **One section at a time.** Never generate the whole plan in one shot — each

of steps 2–6 ends with Peter confirming before the next begins.

3. **Score with the rubric, only the rubric.** Every pain gets the 1–5 scale

definitions from `./references/planning-framework.md`; never invent an

ad-hoc scale or skip a ledger pain.

4. **Client-facing email is ALWAYS a Gmail draft** — if Peter asks to send the

plan to the client, use `mcp__google-workspace__draft_gmail_message`. Never send.

---

## Workflow

### 1 · Collect the inputs and resolve the engagement

Gather everything discovery produced: consult-discovery summary docs,

consult-session-notes 痛點 ledgers, the client's stated goals (pasted text or

Google Docs — read via `mcp__google-workspace__get_doc_content(user_google_email="peter_tu@zynkr.ai", document_id="<id>")`).

A raw idea with no discovery behind it is acceptable input too — say so

up front: the plan will be thinner, and evidence-free rows get marked `（假設）`.

Then resolve the engagement:

- **Deal** — from a `…/deals/{id}` URL, or by company name. Prefer

`mcp__zynkr__get_deal` / `mcp__zynkr__list_deals` when the zynkr MCP is

connected; 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 (written

by consult-intake / consult-project-specialist); 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. This client has no project workspace yet — point

at /consult-intake (inbound lead) or /consult-project-specialist (meeting

debrief). Hard rule 1: never create a competing folder.

### 2 · Persona — confirm

Fill the persona canvas (角色 · 目標 · 日常工作流 · 工具 · 痛點觸點 — field

definitions in `./references/planning-framework.md` §1) from the discovery

evidence, citing which source each field came from. One primary operator

persona by default. Present the canvas; **wait for Peter's confirm** before

moving on.

### 3 · Operator journey (as-is) — confirm

Lay out today's flow as the 階段 table (階段 · 動作 · 工具 · 痛點 · 機會 —

template in `./references/planning-framework.md` §2). The 機會 column is

hypothesis only. Present; **confirm** before ranking.

### 4 · Pain ranking — confirm

Score **every** pain in the ledger — none skipped — on the three 1–5 scales

(影響範圍 size · 強度 intensity · 頻率 frequency, definitions in

`./references/planning-framework.md` §3), `score = size × intensity × frequency`.

Present the full table sorted by score desc, each row showing the three

components and a one-line justification. **Peter may re-score any row** — log

old → new next to the pain, re-sort, and re-present until he confirms.

### 5 · Opportunity selection

Apply the score bands: **≥ 48 = MVP 候選 · 20–47 = roadmap · < 20 = 觀察**.

For each MVP 候選, write a one-line solution hypothesis

(`痛點 → 我們打算怎麼解 → 預期改變`) tied back to the journey's 機會 column.

Roadmap and 觀察 pains stay in the plan — visible, not scoped.

### 6 · MVP scope + success metrics — confirm

Run every MVP 候選 through the three scope tests (最小可驗證？兩週可交付？

依賴最少？ — `./references/planning-framework.md` §4); failures shrink or

demote to roadmap. Output an explicit **in / out** list — the 不做什麼 side is

part of the scope. Then attach success metrics in the four-part shape

`baseline → target → 量測方式 → 量測時點` (§5); missing baselines become

`待量測` + a measurement task inside the MVP, never an invented number.

Present scope + metrics; **confirm** — this is the last gate before the Doc.

### 7 · Generate the `[Plan]` Doc + CRM note

Assemble the confirmed sections (persona · journey · ranked-pain table ·

opportunity list · MVP in/out · metrics · the handoff block from step 8) and

create the Doc via the reliable two-step (direct create-in-folder returns 400):

```

## 1. create the doc (lands in My Drive root)

mcp__google-workspace__create_doc(

user_google_email = "peter_tu@zynkr.ai",

title = "[Plan] {{COMPANY}} — {{PROJECT}}",

content = "<assembled plan>"

)

## 2. move it into the client's [N] project folder

mcp__google-workspace__update_drive_file(

user_google_email = "peter_tu@zynkr.ai",

file_id = "<doc id from step 1>",

add_parents = "<the [N] folder id from workflow step 1>"

)

```

Then append the Doc to the deal's notes (same pattern as consult-brd-writer):

```sql

UPDATE crm_deals

WHERE id = '<deal_id>';

```

via `mcp__supabase__execute_sql(project_id="uomieoqlkazknjgmfdda", ...)`.

Escape single quotes by doubling them.

### 8 · BRD handoff

Close with a fenced handoff summary (also the closing section of the Doc):

```

BRD Handoff — 宏宇精密 · 報價流程自動化

Persona（一句話）: 業務助理王小明 — 所有報價單的實際製作者，最怕錯價與等簽核

Top pains: P-1 手 key 報價轉抄錯價（4×5×5=100）· P-2 紙本簽核等待（3×4×4=48）

MVP in: 詢價擷取＋自動帶價報價單、線上簽核 | MVP out: ERP 整合、多幣別

Metrics: 報價前置時間 2 天 → 4 小時（量測方式：進線→寄出時間差 · 量測時點：上線後第 4 週）

Plan Doc: <doc url>

```

Then point forward: run **/consult-brd-writer** with this block + the `[Plan]`

Doc URL — it formalizes the plan into the client-grade BRD (or PRD).

---

## Why it's built this way

- **Checkpoints over one-shot.** The upstream framework is interactive by

design: each section feeds the next, so an unconfirmed persona or a contested

score compounds. Confirming per section keeps corrections cheap.

- **A fixed rubric, not vibes.** 1–5 definitions per axis make scores

comparable across engagements and across weeks — and make Peter's re-scores

meaningful diffs instead of mood swings.

- **Bands decide, Peter overrides.** ≥48 / 20–47 / <20 turns prioritization

into arithmetic; judgment enters through re-scoring, which is logged.

- **The plan is its own artifact.** Folding this reasoning into the BRD hides

the ranking; keeping `[Plan]` separate lets the BRD cite it and lets the

客戶 see requirements without seeing internal scoring.

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

- **Doc language** → zh-TW body; rubric axis names keep their English glosses.

- **Persona count** → one primary operator persona; more only on request.

- **Raw-idea mode** → allowed; evidence-free rows marked `（假設）` and the

report notes the plan is discovery-thin.

- **Ties within a band** → sort by 強度 desc, then 頻率 desc.

- **MVP 候選 cap** → at most 3 enter the scope tests; the rest open the roadmap.

- **Baseline missing** → `待量測` + measurement task in-scope; never invented.

## Provenance

Forked from `product-planning` (5.02) @ b6bfb04c (2026-08-03) — consult

adaptation; diverges by design.

Re-sync check: `git log --oneline b6bfb04c..origin/main -- skills/5-product/product-planning/`

→ review hits → port or waive with a dated line here.

## Attribution

The framework and methodology — **產品企劃力** (persona, user journey, pain

points ranked by 影響範圍 × 強度 × 頻率, MVP scope, success metrics) — are by

**MrPM-Stanley**: [upstream repo](https://github.com/MrPM-Stanley/product-planning-skill).

This derivative re-scopes the inputs to consulting-discovery artifacts

(pain-point ledgers, discovery summaries) and adds engagement filing, CRM

linkage, and the BRD handoff. The faithful mirror of the original lives in

this repo as `product-planning` (5.02). The install snippet points at Peter's

repo because the adaptation, not the framework, is what installs here.

## Reference files

- `./references/planning-framework.md` — the operationalized framework: persona

canvas fields, journey template, the 1–5 rubric definitions + score bands,

MVP scope tests, and the success-metric shape. The workflow fills these

shapes; it never redefines them.

## Limitations

- Consumes discovery material; it interviews no one and will not bootstrap a

missing workspace (that's consult-intake / consult-project-specialist).

- Plan quality tracks ledger quality — thin discovery yields a thin plan with

many `（假設）` rows; the skill flags this rather than papering over it.

- Scores are structured hypotheses, not measurements — validation happens via

the metrics after the build, exactly as the upstream framework warns.

- One engagement per run; portfolio-level prioritization across clients is out

of scope.

- It plans; it does not write the BRD/PRD (consult-brd-writer) or build

anything.