create-tasks

创建任务

创建结构完善的任务，提供大量上下文，让未参与讨论的工程师无需任何先验知识、也无需提问，就能实现任务。

创建任务时，应遵循应用这些技能的项目所使用的工具和文档惯例。如果惯例不明确，请向用户确认，然后将其记录下来。

工程师需要了解的内容

每个任务都必须说明：

• 要构建什么（交付成果）
• 为什么重要（背景）
• 必须遵循的关键决策和原则
• 验收标准
• 依赖项
• 相关代码/模式
• 如何验证其有效

创建任务前：先拆分

🚨 在验证任务规模之前，绝不要创建任务。 PRD 中的交付成果不一定就是一个任务，也可能是需要拆分的史诗级任务。

通过示例映射梳理需求

🚨 绝不要逐字照搬 PRD 条目。 使用示例映射，将其转化为可执行的规范。

卡片	要做什么
🟡 故事	用一个具体句子说明交付成果
🔵 规则	列出每条业务规则/约束（每个任务最多 3-4 条）
🟢 示例	针对每条规则：正常情况 + 边界情况 + 错误情况
🔴 问题	找出未知事项 → 先解决问题或进行探索性任务

示例（🟢）就是验收标准。使用 Given-When-Then 格式编写：

Given [context/precondition]
When [action/trigger]
Then [expected outcome]

边界情况检查清单——针对每条规则，系统地考虑：

类别	检查内容
输入	空、null、空白、边界值、格式无效、特殊字符、Unicode、过长
状态	并发更新、竞态条件、无效顺序、已存在、不存在
错误	网络故障、超时、部分失败、权限无效、超出配额

示例： PRD 写道：“用户可以搜索产品”

识别出的规则：（1）按标题搜索，（2）分页，（3）空状态

仅针对规则 1，考虑边界情况后可得：

• Given 存在产品 → When 搜索 → Then 返回结果（正常情况）
• Given 没有匹配项 → When 搜索 → Then 返回空集合
• Given 搜索词为空 → When 提交 → Then 显示验证错误，还是返回所有产品？（🔴 问题！）
• Given 搜索词包含特殊字符 → When 搜索 → Then 安全处理

拆分信号（任务太大）

如果符合以下任意一项，立即停止并拆分：

• ❌ 无法用具体、以行动为导向的标题描述
• ❌ 预计需要超过 1 天
• ❌ 标题中需要使用“和”或列出多个事项
• ❌ 验收标准分为多个类别
• ❌ 按层横向拆分（先做所有数据库，再做所有 API，最后做所有 UI）
• ❌ PRD 称其为“完整实现”或“完整系统”

SPIDR 拆分技巧

需要拆分时，使用以下技巧：

技巧	按什么拆分	示例
Paths（路径）	不同的用户流程	“使用银行卡付款”与“使用 PayPal 付款”
Interfaces（界面）	不同的 UI/平台	“桌面端搜索”与“移动端搜索”
Data（数据）	不同的数据类型	“上传图片”与“上传视频”
Rules（规则）	不同的业务规则	“基础验证”与“高级验证”
Spikes（探索）	未知领域	在“实现付款”之前先“研究支付 API”

仅使用垂直切片

每个任务都必须是一个垂直切片——贯穿实现某一项具体功能所需的所有层：

✅ VERTICAL (correct):
"Add search by title" → touches UI + API + DB for ONE search type

❌ HORIZONTAL (wrong):
"Build search UI" → "Build search API" → "Build search DB"

任务命名

格式

[动作动词] [具体对象] [结果/约束]

良好的名称

• “为产品搜索添加价格范围筛选”
• “实现带电子邮件验证的 POST /api/users 端点”
• “在主页上显示产品推荐”
• “启用交易历史记录的 CSV 导出”
• “验证结账表单中的必填字段”

应避免的模式

🚨 绝不要使用这些模式——它们描述的是 Epic，而不是任务：

模式	为什么不合适
“完整实现 X”	把 Epic 伪装成任务
“构建 X 系统”	过于笼统，没有具体交付物
“完成 X 功能”	范围未定义
单独写“实现 X”	缺少具体细节
“X 和 Y”	把两个任务合并在一起
“搭建 X 基础设施”	横向切分

如果你发现自己写出了这些内容，停下来并应用 SPIDR。

任务规模验证（INVEST）

创建前，每个任务都必须通过 INVEST 验证：

标准	问题	不通过 = 拆分
Independent（独立）	它能单独交付价值吗？	依赖其他未完成任务
Negotiable（可协商）	范围可以讨论吗？	固定不变，非全即无
Valuable（有价值）	用户/利益相关者能看到好处吗？	只有技术层面的好处
Estimable（可估算）	你能有把握地估算工作量吗？	“呃……也许需要 3 天？”
Small（小型）	能在 1 天内完成吗？	超过 1 天
Testable（可测试）	有明确的验收标准吗？	标准模糊或缺失

硬性限制

• 最多 1 天的工作量——如果更久，就拆分
• 必须是纵向切片——针对一件事覆盖所有层
• 必须可演示——完成后可以展示其运行效果

任务模板

## Deliverable: [What user/stakeholder sees]

### Context
[Where this came from and why it matters. PRD reference, bug report, conversation summary—whatever helps engineer understand WHY. You MUST provide the specific file path or URL for any referenced files like a PRD of bug report - don't assume the engineer knows where things are stored]

### Key Decisions and principles
- [Decision/Principle] — [rationale]

### Delivers
[Specific outcome in user terms]

### Acceptance Criteria
- Given [context] When [action] Then [outcome]

### Dependencies
- [What must exist first]

### Related Code
- `path/to/file` — [what pattern/code to use]

### Verification
[Specific commands/tests that prove it works]

流程

1. 先切分——应用示例映射法。如果任务有超过 3-4 条规则，或出现拆分信号，则使用 SPIDR 将其拆分。
2. 梳理验收标准——针对每条规则，使用检查清单生成正常路径、边缘情况和错误情况。以 Given-When-Then 的形式编写。提出待确认的问题。
3. 命名——编写具体、以行动为导向的标题。如果做不到，说明任务还不够清晰。
4. 验证规模——必须通过 INVEST。最多 1 天。必须是纵向切片。
5. 收集上下文（来自 PRD、对话、错误报告等）
6. 确定影响实现的关键决策
7. 在代码库中查找相关代码/模式
8. 指定验证命令
9. 使用模板输出任务

检查点

最终确定任何任务之前，验证以下所有事项：

检查项	问题	如果否
规模	工作量是否 ≤1 天？	使用 SPIDR 拆分
名称	标题是否具体且以行动为导向？	使用公式重写
纵向切片	是否针对一件事覆盖所有层？	重构为纵向切片
INVEST	是否通过全部 6 项标准？	修正未通过的标准
上下文	工程师能否无需提问就开始实现？	补充缺少的信息

🚨 如果 PRD 写着“完整实现”或类似内容，就必须拆分。创建这样的任务属于严重失误。