Consult Solution Planning

---
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"
house-style: bound

---

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

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

## 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`
- **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):

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

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

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