stylework-requirement-planninglisted

# StyleWork 需求排期共创 ## Overview 先把一批需求解释成人能讨论的主题地图，回答“这一批在解决什么”，再与用户共创优先级和迭代建议。Skill 只读分析，不修改云效，不修改钉钉，也不修改用户提供的源 Excel；用户最终手工调整。 ## Core Boundaries - 不调用 `stylework-yunxiao-requirement-sync`，不导出、不新建 Sheet、不写回任何系统。 - 不把标题推断写成已确认事实；事实、推断和建议必须分开。 - 不要求批量补录描述、提出方、期望时间、收益数据或完整 PRD 才开始分析。 - 信息不足时仍输出临时建议，并为每个关键判断标注理由、缺失信息、风险和置信度。 - 不替负责人承诺交期，不把建议迭代描述成已经排定。 ## Minimum Input 接受 Excel、CSV、钉钉 Sheet 的只读内容、截图或用户粘贴的需求列表。优先使用已有字段： `标题、负责人、创建者、迭代、技术难度、优先级、客户名称、URL` 描述是可选增强信息，不是启动门槛。若 URL 可用且少量关键需求仅凭标题无法判断，可在用户已经授权查看的前提下，用浏览器只读打开这些需求详情；不要批量修改、评论或改变状态。 ## Workflow ### 1. Establish the evidence ledger 记录： - 已确认字段与用户补充事实； - 从标题或分组推断的主题； - 缺失信息； - 冲突； - 当前排期假设。 标题只能支持初步分类。模糊标题不得被补造成具体业务目标、客户承诺或技术方案。 ### 2. Summarize what the batch is solving 先完成主题聚类，再讨论逐条排期。输出每个主题： - 主题名； - “在解决什么”一句话； - 代表需求； - 数量与当前迭代分布； - 主题性质：用户体验、业务能力、平台基建、可靠性/治理、探索验证或其他； - 判断依据与置信度。 同时标记：重复/高度相似项、依赖、前置能力、可能的能力链和模糊项。不要因标题相似就自动合并，只输出合并候选和需要核对的差异。 ### 3. Invite high-value clarification 在主题摘要后，向用户提出最多 1-3 个批次级高价值问题，优先确认： - 当前领导或阶段重点； - 已承诺客户、固定日期或必须上线事项； - 本月最需要形成的业务结果，或明确不能做的方向。 不要把每条需求的未知项变成几十个问题。若用户暂时不回答、明确要求直接给建议，或上下文已经足够，继续输出临时版，不暂停整个排期。 ### 4. Apply the planning rubric 读取 `references/planning-rubric.md`。依次判断： 1. 外部硬约束与紧迫性； 2. 领导/阶段方向和业务结果； 3. 客户影响范围； 4. 是否是其他需求的前置能力或共同底座； 5. 依赖顺序、技术难度、验证成本和交付风险； 6. 需求清晰度与可执行性； 7. 负责人和迭代负载是否存在明显集中。 技术难度影响拆分和排期顺序，不自动降低业务优先级。高价值高难度项可建议先做验证或拆分前置任务，而不是简单后移。 ### 5. Produce a co-planning draft 按 `references/output-contract.md` 输出： 1. 批次主题地图； 2. 重复、依赖、前置能力和模糊项清单； 3. 建议的