# Stylework Requirement Planning

> StyleWork 需求排期共创 / 需求优先级讨论：当用户给出云效导出、钉钉 Sheet、Excel、截图或一批需求标题，希望先汇总这一批在解决什么，再识别重复、依赖、前置能力和模糊项，并结合领导重点、客户承诺、阶段方向、技术难度与容量讨论建议迭代和优先级时使用。适用于信息不完整但仍需要临时排期建议的场景。只读分析，不用于导出到钉钉、自动修改云效/钉钉、替用户作最终排期决定或承诺交期。

- Skill: `pangkaifeng/stylework-requirement-planning` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add pangkaifeng/stylework-requirement-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pangkaifeng/stylework-requirement-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: PANGKAIFENG (https://skillmd.com/u/pangkaifeng)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pangkaifeng/stylework-requirement-planning

---


# 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. 建议的迭代重点与负载观察；
4. 逐需求当前/建议迭代与当前/建议优先级；
5. 理由、依赖、风险、缺失信息和置信度；
6. 本轮最值得用户调整或确认的 1-3 个决策。

对 `26.8.1` 这类迭代解释为 2026 年 8 月第 1 周。若迭代日历与此不同，采用用户给出的团队定义。

### 6. Revise with user direction

用户补充重点方向或澄清需求后：

- 明确列出哪些建议发生变化及原因；
- 保留未变化项，不整表重写得难以比较；
- 更新置信度与剩余风险；
- 输出新的建议草案，仍不执行外部写入。

## Confidence Rules

- 高：有明确描述、外部承诺或可验证依赖，且建议直接由证据支持。
- 中：标题和现有字段较清楚，但业务收益、容量或依赖仍有一项关键假设。
- 低：主要依赖模糊标题推断，或缺少会显著改变排期的事实。

低置信度不等于不建议；它表示用户应优先复核。

## Definition of Done

- 先解释整批需求在解决什么，再进入逐条排期。
- 重复、依赖、前置能力和模糊项均已显式标记。
- 问题不超过 1-3 个批次级高价值问题，没有要求团队批量补录大量字段。
- 信息不足的项仍有临时建议，且理由、缺失信息、风险和置信度完整。
- 当前值与建议值分开，事实与推断分开。
- 全程只读，没有修改云效、钉钉或源文件。

## Resource Guide

- `references/planning-rubric.md`：优先级、迭代、依赖、难度和置信度的判断规则。
- `references/output-contract.md`：批次摘要、逐需求建议和变更对比模板。
- `evals/evals.json`：触发、非触发与信息稀疏回归场景。