# Pm Master

> 产品全生命周期单一流程（12 阶段）。管理 37 个 PM Skill + 10 个同链路的非 pm- 技能（SRS/设计/任务/标注链）。 流程链：战略框架 → 上市与ICP → 市场调研 → 用户画像 → 功能优先级 → 产品路线图 → 需求澄清 → 需求文档（SRS/PRD）→ 界面设计稿 → 测试用例 → 操作手册 → 任务分解（三源合一 + 看板）。 能力：(1) 单点需求直接路由到最合适的 Skill (2) 多步需求按同一条流程裁剪出阶段区间并编排 (3) 判断类问题转交 pm-advisory-board 组织专家评审 (4) 入口处让用户选「默认档／深度档」，并支持断点续跑与中途换挡。 触发词：「pm-master」「产品总控」「我该用哪个 Skill」「帮我推进这个需求」「从头到尾走一遍」 「完整链路」「完整流程」「走完整流程」「一键生成所有文档」「完整产品交付」「从0到1」「新产品立项」 「产品全流程」，或者用户描述了一个产品工作场景但没指明用哪个 Skill、或任务明显需要多个 Skill 接力时。 不适用：研发侧的 SRS／概要设计／详细设计／编码／测试／上线（那条链走 `dev-master`，从它的阶段 1 接手）； 发版说明与上线审计**已不在本流程**——发版说明归 `dev-master` 阶段 12，上线审计归它的阶段 11。

- Skill: `idwong/pm-master` (Agent Skill, multi-file: 17 files)
- Install (CLI): `npx skillmds@latest add idwong/pm-master`
- Raw SKILL.md: https://api.skillmd.com/api/skills/idwong/pm-master/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: iDWong (https://skillmd.com/u/idwong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/idwong/pm-master

---


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

三条规则：

1. **写一律新根，读四处**：`prd/` 优先 → `dev/`（SRS 与研发产物）→ `design-system/`（设计稿与设计令牌）→ `docs/**` 兜底（存量项目）。
   **`design-system/` 不在 `prd/` 也不在 `dev/` 下**，它在项目根；断点续跑判断「设计稿出没出」只能扫它。
2. **图片放各文档同级 `images/`**，不要集中放——跨目录引用在 Word 导出时会丢图。
3. **老项目的文档留在 `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` 的工具层是同一套，改一处要同步另一处。

## 流程执行规则

1. **开始前报价**：列出裁剪后的阶段区间、每阶段产出物、需要用户确认的点，让用户砍阶段
2. **起流程必走 Step 0**：按 `references/flow-engine.md` 分两批收集（AskUserQuestion 单次上限 4 问）。
   第一批必问：**手头已有什么 / 裁剪范围 / 档位 / 产品类型**；第二批仅当裁剪含阶段 7／8 时问：**阶段7 文档类型 / 交付模式**。
   收完回显一行确认（裁剪｜档位｜阶段7｜模式），再用 TaskCreate 建清单
3. **阶段门禁**：上一阶段的产出文件写入成功，才能进下一阶段。
   **阶段8 的门禁多三条**：① `design-system/` 下 `FLOWS.md` 与 `HANDOFF.md` 齐（覆盖 ≥2 端再加 `CONSISTENCY.md`）；
   ② 契约的**四组**机检（死按钮与孤层 / 流程完整性 / 清单反查九条 / 页面闭环）输出 OK（含 `data-setframe` 为 0——出稿帧已废除）；③ 跑完 `references/prototype-review.md` 的四阶段检查并四方签字。
   未签字的设计稿**不得**作为下游（研发、测试用例、操作手册）的输入
4. **步间交接**：每阶段输出「交接摘要」（≤10 行：本阶段结论 + 下阶段需要的输入），不让下一阶段重读全文
5. **可中途退出**：每阶段完成即是独立可用的交付物
6. **断点续跑**：再次启动时按 `flow-engine.md` 的判断逻辑扫 `prd/`、`dev/` 与 `design-system/`（存量项目再扫 `docs/`），从未完成的阶段继续
7. **不强推流程**：用户只要一步就给一步
8. **跑完阶段 7 要开发**：用户说「开始开发／把它做出来」时交给 `dev-master`，由它从阶段 1 的 SRS 门禁接手——
   两个总控不要同时起流程，重叠技能是同一份，谁在跑就由谁编排

## 澄清规则

- 最多一轮澄清，问题不超过 4 个，按「阻塞路由的 → 影响质量的」排序
- 信息足够路由时不澄清，直接路由（缺的信息留给目标 Skill 自己问）
- **起流程前必须确认裁剪范围**——这一条不能省，跑错区间的代价比多问一句大

## 降级策略

- **目标 Skill 未安装**：按路由表的职责描述做低保真版本，并提示安装完整 Skill
- **问题超出 38 个 Skill 覆盖范围**（技术选型、组织设计、法务合规）：直说不在覆盖范围，不硬套

## 诚实边界

- 总控只保证「路由对 + 流程通」，各 Skill 的产出质量由各自的检查清单负责
- 流程 ≠ 必然更好：单点需求起流程是浪费，一步能解决就一步
- 默认档与深度档选错不影响正确性，只影响产出厚度。**档位在入口问定**，但用户中途说「这步做深一点」随时可换，
  换挡不影响已完成阶段的产出，也不改变阶段编号和产出路径