Cm Product Manager
产品经理 Skill，负责需求分析、用户故事与验收标准编写、歧义清单生成、变更影响分析、业务验收走查；把关型角色，不做技术设计与技术测试
Install
$ agentstack add skill-kingxiaozhe-cm-workflow-cm-product-manager ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-kingxiaozhe-cm-workflow-cm-product-manager) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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 逐条结论 + 流程走查记录 + 业务偏差清单
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: kingxiaozhe
- Source: kingxiaozhe/cm-workflow
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.