| name | tapd-story-breakdown |
| slug | tapd-story-breakdown |
| version | 1.0.0 |
| description | TAPD 需求拆分子技能。对大需求进行拆分,输出各子需求的规范需求文档,严格控制
子需求的内容规模,保障研发交付内容可控、易于测试验证。本技能作为
tapd-story-evaluation 的子技能被调用,不独立触发。
|
| metadata | {"requires":{"mcps":["tapd"]}} |
TAPD 需求拆分
概述
对大需求进行拆分,输出各子需求的规范需求文档。拆分的核心目标是严格控制子需求的
内容规模,保障研发交付内容可控,保障研发交付内容易于测试、验证。
输入
| 参数 | 来源 | 说明 |
|---|
| 需求详情 | 主 skill 传入 | 包含需求 ID、名称、描述(规范需求文档)、优先级等 |
| workspace_id | 主 skill 传入 | TAPD 工作空间 ID |
| 背景知识 | 主 skill 传入 | 架构文档、模块文档、安全规范等 |
执行流程
1. 评估是否需要拆分
通读需求描述(规范需求文档),统计其中包含的用户故事数量:
- 如果 ≤ 2 个用户故事 → 输出无需拆分结果,流程结束
- 如果 > 2 个用户故事 → 继续执行拆分
判断依据:每个独立的"作为[角色],我想要[功能],以便于[价值]"对应一个用户故事。
如果需求文档中没有明确的用户故事格式,则根据核心功能点数量判断——超过 2 个独立
功能模块视为需要拆分。
2. 获取需求长 ID
使用 TAPD MCP tapd_id_get 获取需求的 19 位长 ID(如果输入的是短 ID):
调用参数:
workspace_id: <workspace_id>
id: <需求短ID>
type: "story"
记录长 ID,后续子需求文档中需引用。
3. 执行需求拆分
参照 ../references/requirement-splitting-guide.md 中的原则与方法进行拆分。
3.1 分析拆分维度
结合背景知识,从以下维度分析需求的拆分方式:
- 按功能模块拆分:基于接口定义、公共功能库、前端模块、后端模块逻辑划分
- 按业务流程拆分:按用户操作流程分段,识别关键节点和决策点
- 按技术层次拆分:前端交互层、业务逻辑层、数据访问层、外部集成层
选择最合适的拆分维度(或组合使用),确保拆分结果符合 MECE 原则。
3.2 分析子需求依赖关系
明确各子需求之间的依赖关系:
- 强依赖:必须按顺序实现(如 B 依赖 A 的接口)
- 弱依赖:可并行开发(如共用同一数据库表但功能独立)
- 可选依赖:根据配置决定是否实现
3.3 生成子需求文档
参照 ../references/requirement-doc-template.md 为每个子需求输出规范需求文档,
每个子需求文档必须包含:
- 基本信息:子需求名称、父需求短 ID 及 19 位长 ID、优先级
- 依赖信息:依赖的其他子需求 ID 和名称
- 用户故事:不超过 2 个
- 核心功能点:清晰定义输入/输出/处理逻辑
- 验收标准:使用 Given-When-Then 格式
- 边界范围:本子需求包含和不包含的内容
脱敏要求(强制):写入仓库的子需求文档严禁包含个人敏感信息——不写入 owner/处理人/负责人
等真实人名,不写入 TAPD 内网域名链接,引用 TAPD 单据时仅保留数字 ID
(短 ID 与 19 位长 ID)。owner 仅用于 TAPD 单据接口交互,不落入文档正文。
3.4 保存子需求文档
将每个子需求文档保存在 docs/reqs/ 目录下:
- 确保
docs/reqs/ 目录存在,不存在则创建
- 从子需求名称提炼文件名:最少 8 个字,最多 20 个字
- 文件扩展名统一为
.md
- 如果文件名已存在,追加需求短 ID 后缀以区分
命名示例:
| 子需求名称 | 提炼后文件名 |
|---|
| 用户权限管理模块开发 | 用户权限管理模块开发.md |
| 支付接口对接与状态跟踪 | 支付接口对接与状态跟踪.md |
| 前端表单页面交互优化 | 前端表单页面交互优化.md |
跨平台提示:创建目录和写入文件时,使用 Agent 内置的文件操作工具(如
write_to_file),避免依赖特定操作系统的 Shell 命令。路径分隔符统一使用 /,
Agent 工具会自动适配操作系统。
4. MECE 检查
使用"相互独立,完全穷尽"原则对子需求和父需求进行对照检查:
相互独立检查:
- 任意两个子需求之间是否存在功能重叠?
- 是否有同一个功能点被分配到多个子需求?
完全穷尽检查:
- 父需求的所有功能点是否被覆盖?
- 是否有遗漏的用户故事或功能?
如果检查不通过,返回步骤 3 重新拆分(最多重试 2 次,超过则输出当前结果并标注问题)。
5. 输出拆分结果
输出结构化的拆分结果,供主 skill 继续处理:
## 拆分结果摘要
**父需求**:[父需求名称](ID: [短ID] / [19位长ID])
**子需求数量**:N
| 序号 | 子需求名称 | 用户故事数 | 依赖关系 | 本地文件 |
|------|-----------|-----------|---------|---------|
| 1 | xxx | 2 | 无 | docs/reqs/xxx.md |
| 2 | yyy | 1 | 依赖 #1 | docs/reqs/yyy.md |
| 3 | zzz | 2 | 依赖 #1 | docs/reqs/zzz.md |
**MECE 检查**:✅ 通过
错误处理
| 错误场景 | 处理方式 |
|---|
TAPD MCP tapd_id_get 调用失败 | 使用已有的短 ID 继续,在文档中标注"长 ID 待补充" |
| MECE 检查不通过 | 重试拆分(最多 2 次),仍不通过则标注问题并输出 |
| 文件保存失败 | 将文档内容输出到控制台,提示用户手动保存 |
参考文件
| 文件 | 用途 | 何时读取 |
|---|
../references/requirement-splitting-guide.md | 拆分原则与方法 | 执行拆分前 |
../references/requirement-doc-template.md | 子需求文档模板 | 生成子需求文档时 |