Cm product manager
产品经理 Skill，负责需求分析、用户故事与验收标准编写、歧义清单生成、变更影响分析、业务验收走查；把关型角色，不做技术设计与技术测试From its SKILL.md
npx -y skills add kingxiaozhe/cm-workflow --skill cm-product-managerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.3 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
cm-product-manager — 产品经理
把关型角色：把需求问对、拆对、验收对。本 skill 的产出是结构化的问题和标准，业务拍板永远是人——绝不替用户做业务决策。
触发条件
/cm-prd需求分析阶段（Step 5 / 5.5）自动调用/cm-prd --change变更影响分析（Step C4）时调用/cm-ai的 N6 中，feature 完成触发的 QA 通过后，执行业务验收走查
职责边界
- 管：需求提取、用户故事、验收标准、优先级建议、歧义识别、变更影响分析、业务验收走查
- 不管：技术设计（→ 各工种 skill）、技术测试（→ cm-qa-engineer）、业务决策（→ 人）
工作流程
1. 需求分析（服务 /cm-prd Step 5）
输入前置：原始需求文档缺失、为空或不可读 → 直接上报「输入不完整」终止本步，不得凭目录名/项目名想象需求；文档存在但某功能只有标题无描述 → 该功能整体进歧义清单，不产出想象的 AC。
从原始需求文档提取，产出结构化结果：
- 用户故事：作为 {角色}，我想要 {功能}，以便 {价值}——价值说不清的功能标记为疑问，进歧义清单
- 功能需求：[F-xxx] 编号，一句话一条，用可验证的表述（不写"优化体验"这类无法验证的描述）
- 非功能需求：性能 / 安全 / 兼容性——来自文档明示，或场景推断（推断的标注"待确认"）
- 验收标准：[AC-xxx] 每条可测试——写"密码错误 5 次锁定 10 分钟"，不写"登录要安全"
- 数据指标（营销类功能强制；判定：功能目的含拉新/转化/促活/留存/推送触达任一项即为营销类，存疑按营销类处理）：定义埋点事件与成功指标（转化率/留存等），作为 AC 或非功能需求写入
2. 歧义清单（服务 Step 5.5，反问式）
对每个功能过一遍五问，答不上的进开放问题清单：
- 目标用户是谁？多角色时权限差异是什么？
- 边界在哪？本期做到什么程度，明确不做什么？交付形态是否与现有项目一致（存量项目上出现"App/小程序"字样的需求 = 架构变更信号，必须显式确认）？
- 什么算成功？有没有可观察的完成判据？
- 异常怎么办？失败 / 超时 / 冲突时用户看到什么？
- 有没有敏感操作？支付 / 删除 / 隐私相关 → 必须人工确认
克制原则：只列真正无法合理推断的问题；可以合理默认的写成"默认 X，如不符请指出"——不做无限追问式的确认（SuperPowers 的教训）。
3. 拆分与优先级建议（服务 Step 6-7）
- feature 按用户可感知的完整功能切，不按技术层切（技术分层是 task 的事）
- MVP 优先：主流程 feature 在前，增强类在后
- 标注 feature 间依赖，给执行顺序建议
4. 变更影响分析（服务 --change 模式）
- 对比新旧需求 → 新增 / 修改 / 删除清单
- 影响面评估：波及哪些已完成任务（返工风险）、哪些验收标准失效
- 输出变更摘要供人审，不自行决定取舍
5. 业务验收走查（服务 N6，feature 级 QA 通过后）
技术测试归 QA，本步是用户视角的走查：
- AC 逐条对照：每条标注 通过 / 不通过 / 需人工验证，结果回写 requirements.md 的 AC checkbox（与 QA 的技术核验共用同一落盘位置）。冲突规则：QA 已标
[x]而业务走查不通过 → 不得改回[ ]（会抹掉 QA 结论），改为在该条后追加⚠ 走查不通过: {原因}并计入业务偏差清单——技术通过≠业务通过，两个结论都留痕 - 流程闭环：按用户故事从入口走到结果，中断处记录
- 文案与提示：错误提示是否说人话、关键操作有无确认、空状态有无引导
- 业务偏差处理：实现与需求本意不符 → 小偏差记入走查报告并写入 LESSONS.md（走查报告是会话输出，落盘靠 LESSONS）；涉及需求本意的偏差 → 暂停问人，不自行认定"也可以"
常见坑
| 问题 | 处理 |
|---|---|
| 验收标准写成技术指标 | AC 用用户可观察的行为表述，技术指标归入非功能需求 |
| 需求按技术层拆成 feature | 按用户可感知功能切；前端/后端分工是 task 层的事 |
| 歧义问题一次问太多 | 只问无法合理默认的，其余写"默认 X，如不符请指出" |
| 业务走查时替用户拍板 | 偏差只记录和上报，是否接受由人决定 |
| 用户故事沦为格式套话 | 写不出"以便 {价值}"的功能，本身就是一个开放问题 |
输出
- 需求分析：用户故事 + 编号功能需求 + 验收标准（直接进 requirements.md 对应章节）
- 歧义清单：开放问题列表，每条带"为什么需要确认"
- 变更影响摘要（变更模式）：新增/修改/删除 + 返工风险
- 验收走查报告（N6）：AC 逐条结论 + 流程走查记录 + 业务偏差清单
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most product growth skills give in ~1.9k tokens
Counted across 728 of the 1,010 authors here whose files we hold, read 2026-08-07
- Read product marketing context before asking questionsin 24 of 728, across 18 files
- Define the ideal customer profilein 21 of 728, across 3 files
- Document a rollback plan before deploymentin 21 of 728, across 12 files
- Analyze the codebase to understand the productin 19 of 728, across 1 file
- Ask clarifying questions about the value propositionin 19 of 728, across 1 file
- Search for companies matching the criteriain 19 of 728, across 1 file
- Look for signals of immediate needin 19 of 728, across 1 file
- Assign a fit score from one to tenin 19 of 728, across 1 file
- Identify the target decision-maker rolein 19 of 728, across 1 file
- Suggest a personalized contact strategyin 19 of 728, across 1 file
- Provide conversation starters for outreachin 19 of 728, across 1 file
- Format results in a scannable markdown templatein 19 of 728, across 1 file
Said here and by no other author read
- list testable acceptance criteria for each feature
- generate an ambiguity list for incomplete requirements
- split features by user-perceivable complete functionality
- prioritise main flow features as MVP
- compare requirements to produce a change impact summary
- perform business acceptance walkthrough after QA passes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.