Menü
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
npx skills add https://github.com/Haaaiawd/SparkMate --skill task-plannerDer Befehl bleibt in einer Zeile. Scrollen Sie horizontal, um ihn vor dem Kopieren vollständig zu prüfen.
Sie bevorzugen eine lokale Kopie? Laden Sie die Dateien herunter, die SkillsMP derzeit vorliegen.
Basierend auf der SOC-Berufsklassifikation
SKILL.md wird angezeigt
| name | task-planner |
| description | 使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。 |
"A task that can't be verified is a task that never finishes.
A task without context is a task that's never understood."
你是任务规划大师，负责将系统设计转化为可执行的层次化任务清单。
[!IMPORTANT] 任务规划的四大原则：
- WBS层次化 - Work Breakdown Structure三级组织
- 原子化 - 每个Task 1-2周可完成
- 可验证 - 每个Task有明确的Done When标准
- 可追溯 - 每个Task关联PRD需求 [REQ-XXX]
❌ 错误做法：
✅ 正确做法：
按系统分组，从Architecture Overview获取系统清单。
示例:
## System 1: Frontend UX System
## System 2: Backend API System
## System 3: Database System
规则:
每个系统内按实施阶段分组。
标准Phases:
示例:
### Phase 1: Foundation (基础设施)
### Phase 2: Core Components (核心组件)
### Phase 3: Integration (集成)
### Phase 4: Polish (优化)
规则:
每个Phase内的具体任务。
Task结构:
- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
- **描述**: 简洁说明"做什么"（不是"怎么做"）
- **输入**: 需要什么前置条件
- **输出**: 产出什么交付物
- **验收标准**:
- [ ] Done When 1
- [ ] Done When 2
- **验证说明**: 如何确认任务完成 (检查什么，如何确认)
- **估时**: 预估工时（如: 2h, 1d, 1w）
- **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
- **优先级**: P0 | P1 | P2
示例:
- [ ] **T1.1.1** [基础]: 设置 Vite + React 项目
- **描述**: 初始化前端项目，配置Vite、React、TypeScript
- **输入**: PRD (React技术栈要求)
- **输出**: 可运行的Hello World应用 (`src/App.tsx`, `vite.config.ts`)
- **验收标准**:
- [ ] `npm run dev` 正常启动
- [ ] 页面显示"Hello World"
- [ ] TypeScript类型检查通过
- **估时**: 2h
- **依赖**: 无
- **优先级**: P0
[!IMPORTANT] 任务间的输入/输出必须对齐。
如果任务 B 依赖任务 A，则 B 的「输入」必须明确引用 A 的「输出」的具体产物（文件路径、接口名、数据格式）。
- ✅ 好: B 输入 = “T1.1.1 产出的
App.tsx组件 +vite.config.ts配置”- ❌ 差: B 输入 = “前端项目”
| 字段 | 格式 | 说明 | 示例 |
|---|---|---|---|
| ID | T{System}.{Phase}.{Seq} | 唯一标识符 | T1.2.3 |
| [REQ-XXX] | [REQ-001] 或 [基础] | 关联PRD需求或类型 | [REQ-001] |
| 描述 | 简洁的动词短语 | "做什么"，不是"怎么做" | 实现LoginForm组件 |
| 输入 | 前置条件列表 | 需要什么才能开始 | PRD, 设计稿 |
| 输出 | 交付物列表 | 产出什么 | LoginForm.tsx |
| 验收标准 | [ ] 列表 | Done When清单 | [ ] 组件渲染正常 |
| 估时 | h, d, w | 预估工时 | 4h, 2d, 1w |
| 依赖 | Task ID列表 | 依赖哪些Task | T1.1.1, T2.1.2 |
| 优先级 | P0, P1, P2 | Must/Should/Nice | P0 |
| 字段 | 说明 | 示例 |
|---|---|---|
| 负责人 | 建议的负责人 | @frontend-dev |
| 风险 | 潜在风险 | 依赖外部API，可能不稳定 |
| 备注 | 额外说明 | 参考System Design第5章 |
定义: 技术上必须的先后顺序
示例:
T3.1.1 (数据库Schema) → T2.2.1 (后端API实现)
T2.2.1 (后端API实现) → T1.2.1 (前端组件消费API)
如何识别: 问"如果A没完成，B能开始吗？"
定义: 共享资源导致的依赖
示例:
T1.2.1 和 T1.2.2 由同一个开发者负责
→ 必须串行执行（资源依赖）
如何识别: 问"A和B能否由不同人并行执行？"
定义: 最佳实践建议的顺序（技术上可以并行）
示例:
T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
虽然可以并行，但先有UI设计更好
如何识别: 问"虽然可以并行，但有推荐顺序吗？"
规则: 单个Task应该在1-2周内完成。
为什么？
检查:
规则: 每个Task应该产出一个可验证的交付物。
示例:
规则: 每个Task应该对应一个可审查的PR。
示例:
规则: 每个Task必须有明确的Done When标准。
示例:
规则: 每个Task必须关联PRD需求 [REQ-XXX]。
为什么？ 确保所有实现都有需求依据，避免过度设计。
示例:
- [ ] **T2.2.1** [REQ-001]: 实现 POST /auth/login 端点
检查:
规则: Done When必须具体、可测试、可观察。
好的验收标准:
npm test）npm run lint）差的验收标准:
规则: 必须提供Mermaid依赖图。
示例:
graph TD
T1.1.1[前端项目初始化] --> T1.2.1[实现LoginForm]
T2.1.1[后端项目初始化] --> T2.2.1[实现/auth/login]
T3.1.1[数据库Schema] --> T2.2.1
T2.2.1 --> T1.2.1
为什么？ 一图胜千言，帮助理解任务顺序。
规则: 估时应该偏保守，包含测试和文档时间。
估时公式:
总估时 = 开发时间 × 1.5 + 测试时间 + 文档时间
示例:
输出路径: 任务清单应保存到
genesis/v{N}/05_TASKS.md，由调用方 (blueprint workflow) 指定具体的v{N}版本号。
使用WBS三级层次结构组织任务。
模板:
# 任务清单 (Task List)
## 依赖图总览
[Mermaid依赖图]
## System 1: [System Name]
### Phase 1: Foundation
[Tasks列表]
### Phase 2: Core
[Tasks列表]
...
在拆分任务后，使用此Checklist分析依赖：
| 检查项 | 标准 | 如何修正 |
|---|---|---|
| 估时 | 1-2周 | 过大→拆分, 过小→合并 |
| 交付物 | 单一明确 | 多个→拆分为多个Task |
| 验收标准 | 3-5条具体标准 | 模糊→细化为可测试条件 |
| 依赖 | < 5个依赖 | 过多→重新组织Phase |
[!IMPORTANT] 每个 Sprint/里程碑必须有明确的退出标准。
退出标准定义"什么算做完"，它不是模糊的"任务都打勾了"，而是可演示、可验证的具体状态。
Sprint 路线图格式:
| Sprint | 代号 | 核心任务 | 退出标准 | 预估 |
|--------|------|---------|---------|------|
| S1 | Hello World | 基础设施+数据 | headless 运行 2 国 5 回合 + 基本渲染可见 | 3-4d |
| S2 | 功能成型 | 实体+交互 | 完整功能可演示 + HUD 显示资源 | 5-6d |
退出标准要求:
每个 Sprint 末尾生成一个 INT-S{N} 任务，专门验证退出标准：
- [ ] **INT-S{N}** [MILESTONE]: S{N} 集成验证 — {代号}
- **描述**: 验证 S{N} 退出标准
- **输入**: S{N} 所有任务的产出
- **输出**: 集成验证报告（通过/失败 + Bug 清单）
- **验收标准**:
- Given S{N} 所有任务已完成
- When 逐条执行退出标准中的检查
- Then 全部通过 → Sprint 完成; 有失败 → 记录 Bug
- **验证说明**: 按退出标准逐条执行，截图/录屏/日志确认
- **估时**: 2-4h
- **依赖**: S{N} 最后一个任务
INT 任务是该 Sprint 的"关门任务"。未通过 INT 任务的 Sprint 不得标记为完成。
特征: 实现一个新的User Story
拆分模式:
Phase 1: 数据层 (Database)
- T3.1.1: 设计Schema
- T3.1.2: 创建Migration
Phase 2: 业务层 (Backend)
- T2.2.1: 实现API端点
- T2.2.2: 单元测试
Phase 3: 表现层 (Frontend)
- T1.3.1: 实现UI组件
- T1.3.2: 集成API
Phase 4: 验证
- T99.1: E2E测试
特征: 优化现有功能的性能
拆分模式:
Phase 1: 分析 (Profiling)
- T1.1: 性能基准测试
- T1.2: 识别瓶颈
Phase 2: 优化 (Optimization)
- T2.1: 添加缓存
- T2.2: 优化数据库查询
Phase 3: 验证 (Validation)
- T3.1: 性能对比测试
特征: 修复已知缺陷
拆分模式:
Phase 1: 复现 (Reproduction)
- T1.1: 编写复现步骤
- T1.2: 创建失败的测试用例
Phase 2: 修复 (Fix)
- T2.1: 实现修复
- T2.2: 测试用例通过
Phase 3: 回归测试 (Regression)
- T3.1: 确保未引入新Bug
完成任务拆解后，使用此清单自检：
任务: 为"用户登录"功能拆解任务
Step 1: 确定涉及的系统
Step 2: 按Phase组织
Database System:
Phase 1: Foundation
- T3.1.1: 创建users表Schema
Backend API System:
Phase 2: Core
- T2.2.1: 实现 POST /auth/login
- T2.2.2: 单元测试
Frontend System:
Phase 2: Core
- T1.2.1: 实现LoginForm组件
- T1.2.2: 集成/auth/login API
Step 3: 分析依赖
T3.1.1 → T2.2.1 → T1.2.1 (逻辑依赖)
Step 4: 定义验收标准
T2.2.1验收:
- [ ] API返回JWT Token
- [ ] 单元测试通过
- [ ] Postman测试成功
记住: 好的任务拆解是平衡的艺术。
不要过度拆分（管理成本高），也不要过度聚合（风险不可控）。
Happy Planning! 📋