菜单
Use when: 需要将需求转化为用户故事、准备敏捷开发任务、进行需求拆分、编写验收标准 Do NOT use when: 需求已可直接进入开发、团队不使用用户故事格式
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Product Manager Skills Pack - Full lifecycle support from demand to delivery 让一个产品经理拥有一个产品团队的能力 Use when: Starting a new product, planning features, analyzing market, designing solutions, managing growth, strategic decision
Use when starting any product management task - automatically detects task type and invokes appropriate PM skill using intelligent routing
Use when: 需要检查super-pm skills健康状态、定期维护审计、验证元数据完整性 Do NOT use when: 正在使用某个功能skill、仅需执行产品管理任务
Use when: 有初步需求清单需要细化细节、需明确需求场景和边界条件、需求描述模糊需要结构化 Do NOT use when: 需求已足够详细可直达开发、仅需快速立项无需深入
Use when: 需要理解用户体验全链路、发现用户痛点与机会点、优化用户转化流程 Do NOT use when: 用户流程已非常清晰、仅需单一功能分析而非全局体验
Use when: 需要了解市场格局与竞争态势、收集行业数据、分析竞品优劣势、评估市场机会 Do NOT use when: 市场已有充分内部调研数据、仅需简单规模估算无需深度分析
| name | pm-user-story |
| description | Use when: 需要将需求转化为用户故事、准备敏捷开发任务、进行需求拆分、编写验收标准 Do NOT use when: 需求已可直接进入开发、团队不使用用户故事格式 |
| allowed-tools | ["Read","Write","AskUserQuestion","Bash","Agent"] |
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
# 检查方案设计目录
mkdir -p docs/02-方案设计
# 检查前置文档
echo "📊 正在检查前置文档..."
if [ -f "docs/02-方案设计/PRD产品需求文档.md" ]; then
echo "✅ PRD文档 - 已找到"
else
echo "⏳ PRD文档 - 未找到"
fi
if [ -f "docs/02-方案设计/功能细节拆解.md" ]; then
echo "✅ 功能细节拆解 - 已找到"
else
echo "⏳ 功能细节拆解 - 未找到"
fi
当流程要求与用户交互时：
使用 AskUserQuestion 询问：
您需要编写哪方面的用户故事？
A) 全部功能用户故事（基于PRD功能列表） B) 单个模块的用户故事（请指定模块） C) 单个功能的用户故事（请指定功能） D) Epic级用户故事（高层次需求） E) 其他（请手动输入）
💡 提示：
- Sprint规划 → 推荐单个模块的用户故事
- 产品规划 → 推荐Epic级用户故事
- 开发准备 → 推荐全部功能用户故事
记录到变量 STORY_SCOPE
根据范围读取相应文档：
必需文档：
可选文档：
读取失败处理：
如果 PRD 文档不存在：
⚠️ 未找到 PRD 文档
用户故事需要明确的功能需求作为输入。
您可以选择： A) 执行 /pm-docs 生成 PRD B) 使用功能细节拆解作为输入 C) 手动输入功能需求（快速模式）
📝 用户故事标准格式：
作为 <角色> 我想要 <功能> 以便于 <价值>验收标准（BDD格式）：
GIVEN <前置条件> WHEN <触发操作> THEN <预期结果>是否继续编写？
A) 理解了，开始编写 B) 我需要更多示例 C) 我有特定的编写规范
基于PRD识别出Epic：
| Epic ID | Epic名称 | 描述 | 包含Story数 |
|---|---|---|---|
| E001 | 用户管理 | 用户注册、登录、信息管理 | 5 |
| E002 | 商品浏览 | 商品列表、搜索、详情 | 4 |
| E003 | 购物车管理 | 加入购物车、编辑、结算 | 3 |
| E004 | 订单管理 | 订单创建、支付、查看 | 6 |
是否需要调整Epic划分？
A) 划分合理，继续 B) 需要调整 C) 我有其他划分方式
对每个Epic进行描述：
**Epic: E001 用户管理**
作为 产品系统
我想要 提供用户管理功能
以便于 用户可以注册登录，管理个人信息
业务价值：
- 用户可以拥有个人账号
- 支持个性化服务
- 提供用户数据用于数据分析
包含Story：US001-US005
优先级：P0
预估工时：5人天
逐个对每个Epic确认后继续。
对每个功能，按以下模板编写用户故事：
US001: 用户注册
作为 新用户 我想要 通过手机号注册账号 以便于 拥有个人账号，享受个性化服务验收标准 - 场景1：正常注册
GIVEN 用户未注册过，打开注册页面 WHEN 用户输入手机号、验证码、密码，点击"注册" THEN 创建账号成功，自动登录，跳转到首页场景2：手机号已注册
GIVEN 手机号已注册 WHEN 用户输入该手机号 THEN 提示"已注册，请直接登录"场景3：验证码错误
GIVEN 用户已获取验证码 WHEN 输入错误验证码 THEN 提示"验证码错误"，允许重新输入技术备注：验证码5分钟有效，密码bcrypt加密 依赖：无 风险：验证码发送失败 → 提供邮箱注册备选
这个用户故事是否完整？
A) 完整，继续下一个Story B) 需要调整 C) 需要补充更多场景
逐个Story编写，直到功能列表完成。
如果有大量Story（>10个），使用 Agent 工具并行生成：
使用 Agent 工具并行派发：
Agent 1: 编写Epic1的所有Story
- 输入：Epic1 描述 + 功能列表
- 输出：完整用户故事（含验收标准）
Agent 2: 编写Epic2的所有Story
- 输入：Epic2 描述 + 功能列表
- 输出：完整用户故事（含验收标准）
Agent 3: 编写Epic3的所有Story
- 输入：Epic3 描述 + 功能列表
- 输出：完整用户故事（含验收标准）
Agent 4: 验收标准生成
- 输入：所有 Story 列表
- 输出：每个 Story 的 BDD 验收标准
主 agent 等待所有 subagent 完成，合并汇总输出最终文档。
| 维度 | v1（串行） | v2（Subagent 并行） |
|---|---|---|
| Story 编写 | 逐个编写 | Subagent 按 Epic 并行编写 |
| 验收标准 | 手动逐条编写 | Subagent 批量生成 |
| Token 占用 | 全部 Story 占用主上下文 | Subagent 独立上下文 |
| 执行效率 | 线性顺序 | 并行 3-4x 加速 |
对于复杂的Story（Story Point > 8 或 验收标准过多），进行拆分：
🔍 Story拆分建议：
US004: 购物车管理 → 拆分为：
- US004-1: 加入购物车
- US004-2: 查看购物车
- US004-3: 编辑购物车商品数量
- US004-4: 删除购物车商品
是否接受拆分？
A) 接受拆分 B) 我有其他拆分方式 C) 不需要拆分
基于业务价值和依赖关系排序：
P0（必须有）：US001注册、US002登录、US006商品列表、US008商品详情、US010加入购物车、US014订单创建、US015订单支付
P1（应该有）：US003找回密码、US004个人信息、US007搜索、US011购物车编辑
P2（可以有）：US008收藏、US009评价、US014取消订单
是否需要调整优先级？
使用 Write 工具创建 docs/02-方案设计/用户故事清单.md。
参考 references/output-template.md 模板，文档结构如下：
提供手动输入模式，允许用户逐个输入功能需求。
保存已编写的Story列表到草稿文件。
references/output-template.md✅ Good 示例：
- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例：
- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」
出现以下情况立即停止并回溯：
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证，再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
docs/ 目录⚠️ 任何一项未通过 → 补全后再标记完成。