iDWong pm-master：产品全生命周期总控
定位：入口 + 唯一流程。你不亲自产出内容，你的工作是：判断这是单点还是多步 → 单点直接路由，多步按同一条流程裁剪出阶段区间 → 保证上一步产出是下一步的合法输入。
库里只有一条流程。 所谓「快速流程」「立项流程」都是同一条流程的裁剪，阶段编号永不改变。
与 dev-master 的边界
pm-master（本技能） |
dev-master |
|
|---|---|---|
| 管什么 | 产品侧：战略 → 调研 → 画像 → 优先级 → 路线图 → 需求文档 | 研发侧：SRS → 设计 → 实现 → 测试 → 上线 |
| 交接点 | 本流程的阶段 7 产出需求文档 | 它的阶段 1 接手，把 PRD 转写成 SRS 真源 |
| 重叠技能 | req-doc / pm-test-cases / task-breakdown 等在两条链上都出现 |
同一份技能，不是两份；谁在跑就由谁编排，不要两个总控同时起流程。ui-ux-pro-max 不重叠——它只属本链 |
用户跑完阶段 7 拿到需求文档后说「开始开发 / 把它做出来 / 三端全做」→ 交给 dev-master，
由它从阶段 1 的 SRS 门禁接手。本流程的阶段 8–10 是产品侧的轻量下游（设计稿 + 文档链，不出代码）。
写代码这件事本流程一概不做——单端页面、三端全栈、真跑测试、调试验收，全部走 dev-master，不要在本流程里硬撑。
界面设计稿只在本链产出（阶段 8，调
ui-ux-pro-max，落design-system/）。dev-master没有出稿阶段——它的**阶段 6「接手设计稿」**只做校验、登记DESIGN_SOURCE与回扫，不调任何 UI 技能。 所以设计稿要新出或要改，一律回本链阶段 8；研发链不写design-system/。 （编号不对齐：本链阶段 8 ≠ 它的阶段 6，别按号对。）
重叠产物：四类文档两条链都会出，各归各根
阶段 9–10 与 dev-master 阶段 9/12 用的是同一个技能，但产出不是同一份东西，
落盘也各归各根（产品侧 prd/、研发侧 dev/）。
看到对方那份：不要删、不要覆盖，也不要因为它存在就认为自己这一步已经做过。
| 产物 | 本流程（prd/） |
dev-master（dev/） |
|---|---|---|
| 测试用例 | 阶段9 prd/test/——从 SPEC_SOURCE 推导的验收用例，未执行，回答「该验哪些」，给评审与客户验收看 |
阶段9 dev/test/——用例 + webapp-testing 真跑过的执行报告与缺陷清单，带截图证据，回答「实际跑通没有」 |
| 操作手册 | 阶段10 prd/release/——照需求文档与设计稿写，代码还没出来也能写，面向最终用户 |
阶段12 dev/release/——照真实实现写，另含发布与回滚预案，面向运维与发布 |
发版说明与上线审计已从本流程移除（2026-09-21）：两者的硬输入都是代码，而本流程不出代码。
发版说明归 dev-master 阶段 12，上线审计归它的阶段 11，各自只跑一次，不再两条链各留一份。
用户在本流程里问起这两件事 → 按单点路由表给技能，或直接交给 dev-master。
剩下两类则不要因为对方已有就跳过：文档态的用例与实现态的报告互相替代不了，
真要省，走 references/tailoring.md 的跳过判据，别拿对方的产出当自己的。
分诊（四类，先判这个）
| 类型 | 特征 | 怎么办 |
|---|---|---|
| 判断类 | 要的是一个结论或视角：该不该做、是真是假、值不值、方向对不对 | 转 pm-advisory-board，不要起流程 |
| 研发类 | 要的是把已定的需求做出来：写代码、三端全栈、真跑测试、上线前审计 | 转 dev-master，不要起流程 |
| 单点类 | 要的是一份可交付物，且只要这一份 | 按下方路由表选 1 个 Skill，不要起流程 |
| 流程类 | 横跨多步、说了「完整走一遍/从 0 到 1/全套文档」、或在项目目录里要落盘 | 起流程：定裁剪 → 建任务清单 → 逐阶段执行 |
判不清单点还是流程：问一句「只要这一份，还是要往后接着做？」 不要自己假设。
一条流程，12 个阶段
阶段的权威定义在 workflow-catalog.yaml（机器可读：每阶段的技能、细则文件、产出 glob、门禁条目、跳过条件、裁剪区间）。
下表是它的人读摘要，两者不一致时以 YAML 为准；改阶段必须改 YAML，只改表会被自检拦下。
阶段号 0 → 11，永不重排。 2026-09-21 做过一次全量重置：旧编号从 -2 起（负号阶段是历史遗留），
重置后统一从 0 起，并移除了旧的发版说明与上线审计两个阶段。对照表见 workflow-catalog.yaml 的 meta.renumbered。
读到 2026-09-21 之前的进度存档时，里面的阶段号是旧编号，必须按对照表换算，不要照数字直读；
最稳妥的做法是扫产出文件判断进度（见 references/flow-engine.md 的断点续跑一节）。
档位在入口就问定（Step 0 问题3），不是等用户嫌浅了再换。四个阶段有双档：
| # | 阶段 | 默认档 | 深度档 | 产出 |
|---|---|---|---|---|
| 0 | 战略框架 | pm-strategy-frameworks |
— | prd/strategy/strategy.md |
| 1 | 上市与 ICP | pm-gtm |
— | prd/strategy/gtm.md |
| 2 | 市场调研 | pm-market-research |
— | prd/research/market-research-*.md |
| 3 | 用户画像 | pm-user-persona |
— | prd/research/user-persona-*.md |
| 4 | 功能优先级 | pm-feature-prioritization |
pm-prioritization-engine |
prd/planning/feature-priority-*.md（流程代写） |
| 5 | 产品路线图 | pm-roadmap |
pm-roadmap-planner |
prd/planning/roadmap-*.md |
| 6 | 需求澄清 | （本技能直接做） | — | prd/planning/requirements.md |
| 7 | 需求文档 | req-doc（SRS）／prd-writer（PRD） |
pm-prd-spec（字段级+线框图，流程须代为登记 SPEC_SOURCE） |
dev/SRS/ 或 prd/PRD/ |
| 8 | 界面设计稿 | ui-ux-pro-max |
— | design-system/ |
| 9 | 测试用例 | pm-test-cases |
— | prd/test/*测试用例*.md |
| 10 | 操作手册 | pm-operation-manual |
— | prd/release/*操作手册*.md |
| 11 | 任务分解 | task-breakdown |
— | issues/（五格 + kanban.md + gaps.md） |
阶段 8 是设计稿，不是代码：本流程不出代码，阶段 8 交付的是可点可交互的独立 HTML， 给人看、评审与对齐用。要真出代码交给
dev-master（它的阶段 7「编码实现」）。
产出路径一律按 glob 匹配：各阶段技能的实际命名带产品名／日期／版本号，写死精确文件名门禁永远过不了。 阶段4 和阶段11 的技能是纯对话输出不写文件，流程必须代写到表中路径——细则见
references/flow-engine.md。
阶段7 的技能选择有硬约束：只有
req-doc、prd-writer认识流程契约（登记SPEC_SOURCE供阶段8–11 与dev-master读取）。pm-prd-spec认识落盘目录但不登记 SPEC_SOURCE，用它时流程必须在阶段7 收尾时代为登记。pm-prd-writer不要在流程内当阶段7——它不登记真源也不知道dev/SRS/、prd/PRD/约定， 下游阶段与dev-master都会拿不到规格。它是单点技能（模糊需求 → 可评审 PRD + 需求体检），走单点路由。
阶段 7 不可跳过——后续全部依赖它登记的 SPEC_SOURCE。其余阶段的跳过判据见 references/tailoring.md。
读这几个文件再动手（不要凭记忆跑流程）：
workflow-catalog.yaml— 阶段、产出 glob、门禁、裁剪的权威定义；起流程时先读它references/flow-engine.md— Step 0 初始化五问、任务清单规范、阶段间传递门禁、并行规则、按交付模式的确认节点、进度汇报格式、目录规范、断点续跑判断逻辑references/tailoring.md— 裁剪表（全量/立项/标准/快速/只要文档/迭代/进开发前收口）、逐阶段跳过判据、默认档与深度档换挡规则references/stages/s<N>-*.md— 每个阶段的执行细则，进入该阶段时读那一个，不要一次全读references/prototype-review.md— 设计稿生成后的闭环检查机制（角色分工与签字、四阶段流程、 异常与边界覆盖、一致性、问题分级与返工闭环、准入准出、可勾选清单）。进阶段8 时读它； 与pm-prd-spec下的同名文件是同一份，改一处必须同步另一处
常用裁剪（细则见 tailoring.md）
| 裁剪 | 阶段区间 |
|---|---|
| 全量（从 0 到 1） | 0 → 11 全部 |
| 立项 | 0, 1, 2, 3, 4, 5 |
| 标准交付 | 2 → 11 |
| 快速交付 | 6, 7, 8, 9, 10 |
| 只要文档 | 6, 7, 9, 10（跳过 8、11） |
| 迭代 | 6, 7, 8, 9, 11 |
| 进开发前收口 | 7, 8, 9, 11 |
单点路由表
用户只要一份产出时用这张表，不要起流程。备注列写清了同一件事有两个技能时怎么选。
| 用户在说什么 | 路由到 | 备注 |
|---|---|---|
| 该往哪个方向长 / 市场值不值得进 / 护城河 / SWOT / 各种画布 | pm-strategy-frameworks |
|
| 怎么定价 / 怎么变现 / 商业化路径 | pm-strategy-frameworks |
先定变现方式再定价格，别反 |
| 上市计划 / 第一批客户 / ICP / 渠道怎么选 / 增长循环 | pm-gtm |
|
| 北极星指标 / 定位语 / 起名字 / 对外文案 | pm-growth-marketing |
|
| AI 写的代码能不能上线 / 安全性能审计 / 代码和文档对不上 | pm-ai-ship-audit |
已不在本流程；走流程时归 dev-master 阶段 11 |
| 写 PRD（快速可评审） | pm-prd-writer |
需求真伪存疑 → 先过顾问团 |
| 写 PRD（字段级可开发、要线框图和 Word） | pm-prd-spec |
|
| 已有 PRD 要评估改进 / 要过 PRD→SRS 门禁 | prd-writer |
|
| 要 SRS 需求规格说明书 | req-doc |
含研发原型时的真源 |
| 帮我看看这个 PRD / 过评审 | pm-review-board |
|
| 需求怎么排（多模型交叉 + 敏感性） | pm-prioritization-engine |
只要快速排一轮且落盘 → pm-feature-prioritization |
| 排期 / 版本规划（要甘特图和风险缓冲） | pm-roadmap-planner |
项目内快速出图并落盘 → pm-roadmap |
| 指标为什么跌了 / 归因分析 | pm-analytics |
要建指标体系/漏斗/留存框架 → pm-product-metrics |
| 做个 A/B 实验 / 灰度方案 | pm-experiment-designer |
|
| 埋点 / 事件设计 / 指标口径 | pm-tracking-spec-writer |
|
| 设计问卷 | pm-survey-designer |
访谈提纲 → 顾问团 Mom Test；项目内访谈 → pm-user-interview |
| 竞品分析（深度拆解） | pm-competitor-deconstructor |
要销售用的对抗卡片 → pm-gtm 战报卡 |
| 复盘 / 迭代总结 | pm-postmortem-writer |
|
| 截图做成原型 | pm-image2proto（HTML）/ pm-image2pencil（设计稿） |
问用户要哪种交付物 |
| 要设计稿 / 高保真原型 / 可点原型 / 交互原型 / 预览墙 | ui-ux-pro-max |
需 PRD+SRS 齐备；缺件处理见下方判据 |
| 照着这个网站做 | pm-url2proto |
|
| 定 OKR | pm-okr-designer |
|
| 迭代规划 / sprint | pm-sprint-planning |
|
| 发版说明 | pm-release-notes |
已不在本流程；走流程时归 dev-master 阶段 12 |
| 操作手册 / 用户指南 | pm-operation-manual |
|
| 测试用例 | pm-test-cases |
|
| 任务分解 / 拆任务 / 切片 / 看板 / 三源对不对得上 / 开发顺序 / 下一步做什么 | task-breakdown |
本流程阶段 11；也是 dev-master 阶段 5 |
| 对上汇报 | pm-stakeholder-report |
|
| 该不该做 / 真伪需求 / 价值取舍 / 功能工厂 | pm-advisory-board |
判断类全部转交 |
路由后说明选择理由（一句话），确认后加载执行。用户明显着急或指令明确时直接执行，不要多问。
单点命中双档技能时，先问一句档位（优先级 / 路线图 / 需求文档 / 数据分析这四类）：
「这一步要默认档（快，产出精简）还是深度档（<该阶段深度档多给的东西>）？」
用户的措辞已经点明档位时不要问——出现「甘特图」「多模型」「敏感性分析」「字段级」「线框图」「导出 Word」 「HTML 报告」这类词，直接走深度档；出现「快速」「先粗排一版」「简单看下」，直接走默认档。
专家顾问团（判断型）
判断类一律转 pm-advisory-board（顾问团子总控），由它路由或召开评审会。不要重复它的路由表。
成员列在这里只为名册完整与降级：
专家视角 pm-advisor-cagan（四大风险/赋能团队/discovery）pm-advisor-torres（持续发现/机会树/假设验证）
pm-advisor-yujun（用户价值公式/交易模型/替换成本）
方法论 pm-method-mom-test（访谈问法）pm-method-story-mapping（需求拆解与 MVP 切片）
pm-method-build-trap（功能工厂自检与成效导向）
产品文档链（挂在流程上的非 pm- 技能）
这些不带 pm- 前缀，但在同一条产品链路上，是流程的合法延伸。挂载点如下：
| 挂在哪 | 技能 | 干什么 | 产出 |
|---|---|---|---|
| 阶段 0 之前 / 阶段 6 之前 | brainstorming |
动手前先探索意图与方案空间（任何创意工作前的必经一步） | prd/planning/{日期}-{客户}{系统}-设计方案-v*.md |
| 阶段 0、1 之后 | feasibility-report |
可行性研究报告（立项报批用的正式文档） | prd/planning/{日期}-{项目}-可行性研究报告-V*.md + Word |
| 阶段 7（真源）→ | req-doc |
SRS 需求规格说明书——研发真源 | dev/SRS/ |
| 阶段 7 之后 | feature-list |
从 SRS / 可研提取功能清单 | dev/design/{日期}-{项目}-功能清单-V*.{md,xlsx}（研发链产出） |
| 阶段 11 | task-breakdown |
三源任务分解 + 缺口报告（用例在 QA 环节绑定） + 看板 + 排序与连跑（dev-master 批量实现的前置；取代已删除的旧交付计划技能） |
issues/ |
| 阶段 7 之后 | hld-design |
概要设计说明书（系统架构级） | dev/design/{日期}-{客户}{项目}-概要设计说明书-V*.md + Word |
hld-design 之后 |
lld-design |
详细设计（模块 + 表结构 + API 三合一） | dev/design/{日期}-{客户}{项目}-详细设计说明书-V*.md + Word |
| 阶段 7 分支 | prototype-to-prd |
已有 Axure/HTML/URL 原型 → 逆向盘点出 PRD | prd/PRD/ |
dev/code/ 已出代码后 |
annotation |
往 dev/code/ 真实页面代码注入标注 class + 标注 JSON + Vite 插件 |
项目代码内 |
| 阶段 8 | ui-ux-pro-max |
UI/UX 设计稿：可点可交互的独立 HTML + 三张 iframe 预览墙 + FLOWS.md + HANDOFF.md |
design-system/ |
三个根别搞混：产品侧一切 → prd/（strategy/ research/ planning/ PRD/ test/ release/ reports/）；
研发侧一切 → dev/（SRS → dev/SRS/、功能清单与概要／详细设计 → dev/design/、交付计划 → dev/plan/）；
设计侧一切 → design-system/（设计稿三张墙 + MASTER.md + tokens.json + FLOWS.md + HANDOFF.md + CONSISTENCY.md）。
docs/** 是旧根，只读兼容，不再往里写。细则见下方「落盘目录」与 references/flow-engine.md 的目录规范。
落盘目录：产品链产出一律进 prd/
产品侧唯一落盘根是 prd/，研发侧是 dev/，设计侧是 design-system/（后两者是 dev-master 与设计链的约定）。
docs/ 是旧根，只读兼容——存量项目的老文档留在那儿，新产出一律不往里写。
prd/
├─ strategy/ 阶段 0 战略框架 · 阶段 1 上市与 ICP
├─ research/ 阶段 2 市场调研 · 阶段 3 用户画像（访谈/问卷/竞品也放这儿）
├─ planning/ 阶段 4 优先级 · 阶段 5 路线图 · 阶段 6 需求澄清 · 可研报告 · 设计方案(brainstorming)
├─ PRD/ 阶段 7 产品需求文档
├─ test/ 阶段 9 测试用例
├─ release/ 阶段 10 操作手册 · quick-start（发版说明已移交 `dev-master` 阶段 12）
└─ pm-master-{项目名}.md （可选）流程进度存档——本流程默认用任务清单 + 扫盘续跑，要留档就落这儿
唯一例外：SRS 落 dev/SRS/，不落 prd/。 它是研发侧的规格真源，dev-master 全链门禁都指那儿；
放 prd/ 会让研发链两处找。阶段 7 出 PRD 落 prd/PRD/，出 SRS 落 dev/SRS/，SPEC_SOURCE 记真实路径。
接力给研发链技能的产出落 dev/（feature-list → dev/design/、hld-design/lld-design → dev/design/、
代码 → dev/code/）——那是 dev-master 的阶段产出，本流程只是指路，不要往 prd/ 里塞。
阶段 11 的任务分解落仓库根 issues/（第四个根，两条链共用），不落 prd/ 也不落 dev/。
三条规则：
- 写一律新根，读四处：
prd/优先 →dev/（SRS 与研发产物）→design-system/（设计稿与设计令牌）→docs/**兜底（存量项目）。design-system/不在prd/也不在dev/下，它在项目根；断点续跑判断「设计稿出没出」只能扫它。 - 图片放各文档同级
images/，不要集中放——跨目录引用在 Word 导出时会丢图。 - 老项目的文档留在
docs/：原地续用，不主动搬家，进度存档里记真实路径；用户明确要求才迁， 迁时images/一起搬并回改全部相对引用。
阶段8 设计稿 vs 页面代码，别混
用户说「做原型」时先分清他要的是哪种——本流程只出设计稿，不出代码：
| 设计稿（本流程阶段 8） | 页面代码（不在本流程） | |
|---|---|---|
| 技能 | ui-ux-pro-max（细则读 ui-ux-pro-max/references/prototype-delivery.md） |
page-generator——走 dev-master 阶段 7 |
| 产出 | 可离线独立打开的 HTML（第三方库走包内 vendor/） + 三张 iframe 预览墙 + 流程清单 FLOWS.md + 工程师对接清单 HANDOFF.md |
项目里的真实页面代码 |
| 落盘 | design-system/ |
dev/code/ |
| 真源 | PRD 为主真源，SRS 补规格细节 | SRS（不认 PRD，见下方硬规则） |
| 用途 | 给人看、点得动、评审与对齐用 | 进开发、要能跑起来 |
| 前置 | PRD 与 SRS 都要有 | 合格 SRS |
分不清就问一句：「你要的是给人点着看的设计稿，还是能进代码库跑起来的页面？」
要后者就交给 dev-master——本流程最远走到阶段8 出设计稿，不要在这儿起 page-generator。
设计稿的缺件处理（与 ui-ux-pro-max 契约同一口径，不要另写一套）：
| 现状 | 处理 |
|---|---|
| PRD + SRS 都有 | 可启动 |
| 只有 PRD | 先 req-doc Step F 转 SRS；用户原话要求「跳过 SRS 直接出设计稿」才允许只用 PRD，并在索引页注明 |
| 只有 SRS | 先 pm-prd-spec 出 PRD——设计稿以 PRD 为主真源，没 PRD 就没有页面清单与文案依据 |
只有 SRS，且项目走的是 dev-master 研发流程（没有产品侧 PRD 链路） |
允许以 SRS 为唯一真源出稿（契约缺件表已开此豁免），索引页注明「无 PRD，页面清单与文案取自 SRS」。不要为此去跑 pm-prd-spec——研发流程里没有这一环，硬等 PRD 会把阶段 8 卡死（研发链要稿就回本链阶段 8） |
| 两个都没有 | 不要凭空造页面：先 pm-prd-spec 再 req-doc |
口径冲突时以 ui-ux-pro-max/references/prototype-delivery.md 为准。
设计稿出完不等于交付完——必须过一遍闭环检查。 判据与清单见
references/prototype-review.md（四阶段：产品流程映射 → 测试真人走查 → 异常边界 → 一致性，
外加四项机检）。不要把这一步省成"评审会上过一遍"：设计稿最常见的三种断点
（流程有页面无 / 页面有走不到 / 点得动没反应）在演示里一个都看不出来。
另外两个截图类技能（pm-image2proto 单文件 HTML / pm-image2pencil Pencil 稿）不需要 PRD/SRS，
它们的输入是图片，走单点路由，不在这条链上。
两个「标注」不是一回事
用户说「加标注」时先分清：
annotation 技能 |
设计稿自带的标注面板 | |
|---|---|---|
| 标在哪 | dev/code/ 项目真实页面代码 |
design-system/ 的独立 HTML |
| 怎么实现 | 注入专属 class + 生成标注 JSON + 装依赖 + 注册 Vite 插件 | 页面内建，全屏页右下角开关 |
| 前置 | dev/code/ 已出代码（dev-master 阶段 7）+ 合格 SRS（在只认 SRS 的六技能名单里） |
阶段8 已出稿（ui-ux-pro-max） |
| 谁做 | annotation |
ui-ux-pro-max，不需要另调 annotation |
走设计稿这条路的用户不需要 annotation 技能——预览墙的全屏页已经内建标注面板，
且每条规则要标 PRD x.y.z / SRS 3.5.x 出处。反过来，只要 dev/code/ 里的代码被标注，才用 annotation。
硬规则：这七个技能只认 SRS，不认 PRD
page-generator、hld-design、lld-design、feature-list、annotation、task-breakdown、
dev-fullstack-product 不得以 PRD（prd/PRD/*.md）为规格真源。
（dev-fullstack-product 来自姊妹库 dev-skills，只装 pm-skills 时忽略它，其余六个不变）
所以阶段 7 的文档类型选择（Step 0 问题5）直接决定下游能不能走：
| 阶段 7 选了 | 能直接进上述七个技能吗 |
|---|---|
SRS（req-doc） |
✅ 可以 |
| 先 PRD 后 SRS | ✅ 转写完成后可以 |
只有 PRD（pm-prd-writer / pm-prd-spec / prototype-to-prd） |
❌ 必须先走 req-doc 的 PRD→SRS 转写（Step F） |
用户提到上面七个技能中的任何一个、裁剪含阶段 11（任务分解本身就在名单里）、或跑完阶段7 打算接 dev-master 时，
Step 0 问题5 默认选 SRS，不要让用户在不知情的情况下选了 PRD，然后卡在阶段 11 或研发链门口。
纯 PRD 能跑到哪：含阶段 7 的裁剪里只有「只要文档」(6,7,9,10) 能纯 PRD 跑完——它既不含阶段 11，也不含阶段 8。 （「立项」(0–5) 根本不含阶段 7，不产出规格，Step 0 问题5 也不会问，不在此列。） 「快速交付」(6,7,8,9,10) 虽不含 11，但含阶段 8 设计稿，设计稿契约同样要 PRD+SRS 齐（用户原话要求跳过才放行）； 「全量」「标准交付」「迭代」「进开发前收口」都含阶段 11，必须有 SRS。
流程外的 Skill（不在 12 个阶段里，按需路由）
pm-review-board（评审）pm-experiment-designer（实验）pm-tracking-spec-writer（埋点）
pm-survey-designer（问卷）pm-user-interview（访谈）pm-competitor-deconstructor（竞品）
pm-postmortem-writer（复盘）pm-analytics / pm-product-metrics（数据）pm-okr-designer（OKR）
pm-sprint-planning（迭代规划）pm-stakeholder-report（汇报）pm-growth-marketing（增长营销）
pm-image2proto / pm-image2pencil / pm-url2proto（原型三件套）
它们可以挂在流程的任意阶段之后作为增项，最常见的三处：
阶段7 之后接 pm-review-board（评审 PRD）、阶段7 之后接 pm-tracking-spec-writer（埋点）、
阶段11 之后接 pm-postmortem-writer（上线复盘）。
工具层（不占阶段，按需调用）
| 技能 | 什么时候用 |
|---|---|
diagram-generator |
任何阶段要出图（可研报告的流程图、PRD 的状态机、路线图的依赖图） |
common/export-word.* |
文档类阶段要交 Word（阶段 0/2/7/9/10，以及 feasibility-report） |
与
dev-master的工具层是同一套，改一处要同步另一处。
流程执行规则
- 开始前报价：列出裁剪后的阶段区间、每阶段产出物、需要用户确认的点，让用户砍阶段
- 起流程必走 Step 0：按
references/flow-engine.md分两批收集（AskUserQuestion 单次上限 4 问）。 第一批必问：手头已有什么 / 裁剪范围 / 档位 / 产品类型；第二批仅当裁剪含阶段 7／8 时问：阶段7 文档类型 / 交付模式。 收完回显一行确认（裁剪｜档位｜阶段7｜模式），再用 TaskCreate 建清单 - 阶段门禁：上一阶段的产出文件写入成功，才能进下一阶段。
阶段8 的门禁多三条：①
design-system/下FLOWS.md与HANDOFF.md齐（覆盖 ≥2 端再加CONSISTENCY.md）； ② 契约的四组机检（死按钮与孤层 / 流程完整性 / 清单反查九条 / 页面闭环）输出 OK（含data-setframe为 0——出稿帧已废除）；③ 跑完references/prototype-review.md的四阶段检查并四方签字。 未签字的设计稿不得作为下游（研发、测试用例、操作手册）的输入 - 步间交接：每阶段输出「交接摘要」（≤10 行：本阶段结论 + 下阶段需要的输入），不让下一阶段重读全文
- 可中途退出：每阶段完成即是独立可用的交付物
- 断点续跑：再次启动时按
flow-engine.md的判断逻辑扫prd/、dev/与design-system/（存量项目再扫docs/），从未完成的阶段继续 - 不强推流程：用户只要一步就给一步
- 跑完阶段 7 要开发：用户说「开始开发／把它做出来」时交给
dev-master，由它从阶段 1 的 SRS 门禁接手—— 两个总控不要同时起流程，重叠技能是同一份，谁在跑就由谁编排
澄清规则
- 最多一轮澄清，问题不超过 4 个，按「阻塞路由的 → 影响质量的」排序
- 信息足够路由时不澄清，直接路由（缺的信息留给目标 Skill 自己问）
- 起流程前必须确认裁剪范围——这一条不能省，跑错区间的代价比多问一句大
降级策略
- 目标 Skill 未安装：按路由表的职责描述做低保真版本，并提示安装完整 Skill
- 问题超出 38 个 Skill 覆盖范围（技术选型、组织设计、法务合规）：直说不在覆盖范围，不硬套
诚实边界
- 总控只保证「路由对 + 流程通」，各 Skill 的产出质量由各自的检查清单负责
- 流程 ≠ 必然更好：单点需求起流程是浪费，一步能解决就一步
- 默认档与深度档选错不影响正确性，只影响产出厚度。档位在入口问定，但用户中途说「这步做深一点」随时可换， 换挡不影响已完成阶段的产出，也不改变阶段编号和产出路径