to-issues — 任务拆分
- 触发方式:
/to-issues或关键词「拆分任务」「create issues」「break down」 - 适用场景: 将计划/PRD/需求拆分为独立可执行的开发任务
- 不适用场景: 需求本身还不明确、无书面计划
功能概述
to-issues 将计划、PRD 或需求文档拆分为独立可抓取的开发任务。它使用 tracer-bullet（曳光弹）垂直切片策略，确保每个 Issue 都是完整的、可独立交付的用户价值单元。
触发条件
以下情况会自动触发 to-issues：
- 提到「拆分成任务」「创建 Issue」「分解工作」
- 有明确的计划/PRD 需要落地
- 使用
/to-issues命令
使用示例
示例 1：PRD 拆分为任务
/to-issues 将这个用户认证系统的 PRD 拆分为开发任务Claude 会生成：
#1 [P0] 数据库迁移：创建 users 和 sessions 表
#2 [P0] POST /api/register — 邮箱注册接口
#3 [P0] POST /api/login — 登录接口，返回 JWT
#4 [P1] 密码重置流程 — 发送邮件 + 重置接口
#5 [P1] 登录页面 UI
#6 [P1] 注册页面 UI
#7 [P2] OAuth 登录（Google + GitHub）
#8 [P2] 会话管理和刷新 Token示例 2：按优先级拆分
/to-issues 按 MVP → V1.0 → V2.0 三个阶段拆分这个电商系统的任务示例 3：修复任务拆分
/to-issues 把性能优化计划拆分为可并行的独立任务示例 4：垂直切片
/to-issues 使用垂直切片方式拆分用户中心模块，确保每个任务都能独立演示拆分原则
- Tracer-bullet 切片 — 每个任务贯穿完整的技术栈，而不是按层拆分
- 独立可交付 — 每个 Issue 完成后可以独立演示/测试
- 大小适中 — 1-3 天的开发量
- 依赖最小化 — 尽量让任务可并行执行
- 优先级明确 — 每个任务标注 P0-P4 优先级
注意事项
- 拆分结果不是最终方案 — 需要团队 Review 确认
- 垂直切片 > 水平分层 — 避免拆成「做所有 API」「做所有 UI」
- 每个 Issue 需要明确的验收标准（Acceptance Criteria）
- 依赖关系过重可能意味着需要调整架构设计