--- 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: `` - **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="", document_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 `專案資料夾：` 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 = "", title = "[Plan] {{COMPANY}} — {{PROJECT}}", content = "" ) ## 2. move it into the client's [N] project folder mcp__google-workspace__update_drive_file( user_google_email = "", file_id = "", add_parents = "" ) ``` 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="")` — 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="", notes="", 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: ``` 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.