/pd —— 业务输入 → 产品需求、产品设计与 Meegle 工作项

把分散的调研和业务信息整理为可共同评审的产品定义，再拆成可独立交付的 Meegle 工作项。 这一步不做技术方案、不排期，也不进入研发实现。

全程只用产品经理的视角思考和写作。 描述用户、场景、问题、规则和产品行为； 不写代码、接口、字段、表结构、技术选型、架构或实现步骤，也不用它们论证方案可行性。 技术影响面由 /s 读代码后写进 SPEC.md，实现方案由 /p 负责。

输入

尽可能读取以下事实来源；没有就明确缺口，不要猜：

• 业务目标、规则、约束和截止时间
• 用户调研、访谈、反馈、数据与具体案例
• 历史需求、已有产品能力和已否决方案
• 产品文档、界面、流程和术语
• 现有系统对用户呈现的行为，以及已知的产品级限制（用产品语言转述，不复制技术细节）
• Meegle 中已有或相似的工作项

装了飞书项目 CLI 就直接读取相关工作项；没装就让用户提供内容或链接。 原始诉求只是输入，不直接等于产品需求。

工作流

1. 核对输入覆盖范围

先列出已经读取的来源和缺失的关键证据。区分事实、判断与假设；影响产品方向的未知项必须进入 「待澄清」，不能被顺手补全。

2. 定义产品需求

整理并确认：

• 谁在什么场景遇到什么问题
• 当前做法及其成本
• 业务目标与用户价值
• 成功后应发生的行为或指标变化
• 本次范围、非目标和不能改变的现有行为

发现多个问题或目标混在一起时先拆开，不要用一个大需求包住所有诉求。

3. 形成产品设计

基于现有产品与系统上下文给出：

• 用户流程与关键触点
• 信息结构、页面或功能结构
• 业务规则、对象状态与状态转换
• 角色与权限差异
• 正常、空、异常和边界场景
• 与现有能力的复用、替换或兼容关系

只描述产品行为和体验，不指定技术架构、代码分层、库或实现方式；这些进入 /p。

4. 拆分工作项

按可独立交付的产品价值纵向拆分，不按前端、后端、测试等工程工种横向拆分。

每个工作项必须：

• 对应一个清晰的用户或业务结果
• 能独立说明范围、非目标和验收标准
• 标明父工作项、依赖和与其他工作项的关系
• 小到能进入一次可控的研发迭代

使用 docs/templates/meegle-work-item.md 的结构生成完整草稿。需要多个工作项时，先给拆分总表， 再给每个工作项的完整描述。模板里「影响面」只填上下游和兼容性这类业务可感知的影响；技术影响不在 Meegle 记录。

5. 确认后创建

先展示产品需求、产品设计、拆分关系和工作项草稿，等待产品经理明确确认。

• 有 Meegle 写入能力：确认后创建工作项，回报工作项号、链接、父子关系与依赖。
• 无 Meegle 写入能力：输出可直接复制的草稿，不声称已经创建。

创建后运行 /bl，把新工作项放进全部产品工作项中排序和排期；被选入迭代的工作项再运行 /s。

输出顺序

1. 输入来源与待澄清
2. 产品需求：用户、场景、问题、目标、成功标准、范围与非目标
3. 产品设计：流程、结构、规则、状态、权限和异常场景
4. 工作项拆分总表：名称、价值、父项、依赖、边界
5. Meegle 工作项草稿
6. 创建结果或下一步

规则

• 产品经理保留最终判断。 Agent 未获明确确认不得创建工作项。
• 不在本地复制第二套需求真相。 正式需求进入 Meegle；仓库从 /s 生成 SPEC。
• 不做优先级与排期。 只记录明确的业务截止时间和依赖，整体排序交给 /bl。
• 不做技术方案。 研发可以共同补约束和影响，但要翻译成产品语言；实现设计进入 /p。
• 产出中不得出现代码或实现内容。 包括代码片段、接口/字段/表结构、库与框架名、 架构分层、部署和迁移步骤。需要表达限制时，只说它对用户和业务意味着什么。 例外：做的就是 API/SDK 这类面向开发者的产品时，对外契约本身就是产品行为，该写； 禁的是内部接口、存储字段和实现设计。
• 不处理产品验收。 本 skill 的终点是工作项创建与关联。

Red Flags

• 把领导原话或用户诉求直接改写成需求，没有验证问题
• 产品设计只列功能名，没有流程、规则、状态和异常场景
• 按前端、后端、测试拆工作项
• 每个工作项都依赖其他项，无法独立交付价值
• 没有展示草稿就直接写入 Meegle
• 输入缺失却输出了确定结论
• 产品设计或工作项里写了接口、字段、表结构、技术选型或代码
• 用技术实现难度代替产品判断来决定范围