获取任务 (Get Tasks)
概述
get-tasks 将一份已批准的 PRD 转换为一组可执行的任务。每个任务都写入自己的文件，大小适合一个专注的会话，按依赖顺序排列，并附带验收标准、验证步骤、阻塞列表和回滚程序。
这个技能存在的理由是：PRD 不是计划。PRD 说明系统做什么以及为什么做。它没有说明工作顺序、哪些可以并行构建、风险在哪里，或者如何证明一个切片已完成。直接将 PRD 转换为代码会导致要么是一个英勇的单次通过变更，要么是一个会在中途崩溃的任意顺序。
get-tasks 提供了缺失的层次。它读取 PRD，映射真实的依赖结构，将工作切割成垂直切片，并将每个切片写成一个独立的工件，代理（或人类）无需重读整个 PRD 即可接手。
该技能源自三个来源：
- 依赖优先的分解和垂直切分 — 构建依赖图，垂直切片而非水平切片，为每个任务设定大小，并放置检查点。这确保了顺序正确。
- 验证驱动的执行 — 每个任务声明如何通过多种验证类型进行验证，而不仅仅是“测试通过”，并且包含一个步骤失败时的重新计划程序。
- 阻塞边界和跟踪子弹 — 每个任务明确声明什么阻塞它，因此任何阻塞项已完成的任务可以立即开始。
输出是一个任务文件目录：tasks/<名称>/task-01.md、task-02.md，依此类推，按依赖顺序编号，外加 tasks/<名称>/plan.md 索引它们。阻塞任务获得较小的编号。
本技能的范围
get-tasks 故意设计得很全面。它吸收了几个较窄技能各自部分完成的内容，这样用户只需一个技能即可从已批准的 PRD 获得一个可追踪、可执行的计划。这里的所有内容都与这个单一任务相关：
| 关注点 | 处理位置 |
|---|---|
| 读取 PRD 并提取承诺 | 阶段 1 |
| 依赖结构和排序 | 阶段 2 |
| 垂直切分和跟踪子弹 | 阶段 3 |
| 大规模重构（扩展、迁移、收缩） | 阶段 3 |
| 每任务规范 | 阶段 4 |
| 大小和拆分规则 | 阶段 5 |
| 检查点和关卡 | 阶段 5 |
| 并行化分类 | 并行化分类 |
| 人类可读的计划摘要、风险、决策 | 阶段 6 |
| 追踪器 vs. 文件目标 | 任务列表目标 |
| 写入前用户批准 | 阶段 7 |
| 写入、同步和验证工件 | 阶段 8 |
| 处理失败和重新规划 | 任务失败时重新规划 |
它故意很长。长度就是重点：一个遗漏了任何这些隐式方面的分解会产生看起来完成但实际并非如此的任务。如果你倾向于直接跳到模板，请改为阅读阶段 2、3 和 5——这些是分解实际上失败的地方。
该技能不做的事情：它不编写代码，不运行任务，也不替代 PRD。它将一个文档转换为一组文档。
何时使用
在以下情况下使用本技能：
- 存在 PRD、规格说明或需求文档，并且工作需要变成可执行的任务
- 用户说“获取任务”、“分解 PRD”、“pecah jadi task”、“bikin task list”或“将其转换为任务”
- 某个任务感觉太大而无法开始，需要分解
- 你需要估算范围、安排工作顺序或找出哪些可以并行运行
- 你即将实现一些涉及多个文件且没有现存任务列表的功能
何时不使用：
- 尚不存在 PRD——先运行
get-prd，然后再回来 - 无论以何种标准衡量，变更都是一个单一任务（一个文件、一个明显的编辑）——直接做就好
tasks/中已存在完整的任务分解，并且你已经准备好实现——直接按顺序执行任务即可
流程
get-tasks 分为九个阶段运行。每个阶段都有一个退出条件。在退出条件满足之前，不要进入下一个阶段。
0. 定位 PRD -> 哪个文档是源？
1. 读取并提取 -> PRD 向我们承诺了什么？
2. 依赖图 -> 什么依赖于什么？
3. 垂直切片 -> 跟踪子弹，而非水平层
4. 编写每个任务 -> 每个任务一个文件，完全指定
5. 排序、大小、检查点 -> 序列、大小和验证关卡
6. 编写计划文档 -> 人类可读的摘要，索引任务
7. 询问用户 -> 粒度、阻塞边界、合并或拆分
8. 写入并验证 -> 文件写入磁盘，待办事项同步，验证器通过
任务分解的通用原则
- 自然语言节奏： 以用户使用的语言（印度尼西亚语或英语）呈现分解和对话式摘要，同时保持文件名、git 术语和代码令牌为标准形式（
task-01.md、branch、commit、TDD）。 - 自主执行就绪：
tasks/<feature>/task-*.md中生成的每个任务文件必须完全自包含。任何编码代理只需阅读单个任务文件，就知道要编辑哪些文件、运行哪些测试以及必须满足什么完成定义，无需猜测。 - 垂直切片优于水平层： 切勿创建纯粹是“设置后端”或“设置前端”且无法端到端验证的任务。垂直切片（例如“带有 UI 触发器的 SKU 端点存储与查询”），以便每个任务都能交付可测试的价值。
规划是只读的。 阶段 0 到 7 生成文档和问题，而不是代码。在这些阶段中，不要创建、编辑或删除任何源文件。在用户批准之前，tasks/ 下的任务文件写入是唯一允许的文件系统更改。如果你在分解工作时发现自己正在修复 bug 或添加函数，请停止：这属于批准后的实现，并且属于你尚未编写的任务。
阶段 0：定位 PRD
在做任何其他事情之前，先找到源文档。
- 先按惯例查找。
get-prd保存到docs/prd/<name>.md。首先在那里查找。 - 然后进行更广泛的搜索。 如果
docs/prd/为空，查找用户指定的 PRD。接受 issue 正文或粘贴的需求文档——该技能不受格式限制，只有阶段 1 的提取假定 PRD 部分名称。 - 如果存在多个候选项，不要猜测。列出它们并询问哪个主导这项工作。
- 如果不存在，停止并说明。不要编造需求。引导用户使用
get-prd进行完整的访谈到 PRD 的步骤。
记录你正在使用的确切路径。每个后续阶段都引用它。
对于多模块计划，如果 PRD 按模块 ID 拆分（docs/prd/identity.md、docs/prd/billing.md），确认此分解涵盖哪个模块。每个模块一个分解，按照能力映射声明的构建顺序。
退出条件： 一个源文档被识别，并且其路径已记录在案。
阶段 1：读取并提取
完整阅读 PRD。然后明确提取推动分解的材料：
| PRD 部分 | 你从中提取的内容 |
|---|---|
| 目标 | 每个任务最终服务的最终状态 |
| 用户故事 | 必须可行的可观察行为，候选验收标准 |
| 技术决策 | 模块、接口、架构变更、契约——这些定义了任务之间的真实边界 |
| 项目结构 | 工件存放在哪里，这限制了“可能涉及的文件” |
| 命令 | 每个任务将引用的具体验证命令 |
| 测试策略 | 这里什么算作一个好的测试，以及测试属于哪里 |
| 边界 | 始终 / 先问 / 从不 — “从不”项目成为每个任务的硬约束 |
| 范围外 | 明确的非目标；这里没有任何东西成为任务 |
| 成功标准 | 最终关卡；最后一个检查点对照它进行验证 |
规则：
- 现在不要开始切片。 先提取，后分解。边读边切片会产生由你恰好阅读文档的顺序决定的形状的任务。
- 将模糊项目转换为可检查的陈述。 如果 PRD 说“仪表板应该很快”，则任务的验收标准是一个数字，如果 PRD 没有给出数字，则将其作为阻塞项提出，而不是默默选择一个。
- 标记差距。 如果某个必需部分缺失或为空，请指出。缺失的测试策略意味着每个任务的验证块将在以后被发明；现在就提出来。
- 永远不要编造需求。 如果 PRD 没有说明，那就不是一个任务。
退出条件： 提取表已填充，并且任何差距都已向用户提出。
阶段 2：映射依赖图
在编写任何任务之前，先映射什么依赖于什么。这是决定顺序并防止最昂贵错误类型（在其生产者存在之前构建消费者）的阶段。
绘制图形。具体，而非抽象：
数据库架构
|
+-- API 模型和类型
| |
| +-- API 端点
| | |
| | +-- 前端 API 客户端
| | |
| | +-- UI 组件
| |
| +-- 验证逻辑
|
+-- 种子数据和迁移
规则：
- 边从生产者指向消费者。 箭头表示“目标首先需要源”。
- 没有循环。 如果两个东西彼此需要，它们是一个任务，或者它们之间的接口必须首先定义为自己的任务。
- 接口是边界。 当两个任务在契约（类型、端点形状、架构）处相遇时，在较早的任务中定义契约，并在较晚的任务中消费它。永远不要两个任务独立发明它。
- 找到前沿。 前沿是其所有阻塞项都已完成的任务。它是现在可以开始的任务。对于线性链，前沿是一个任务宽；对于一个大型项目，它可能是几个。
- 命名并行机会和硬序列。 独立的切片可以并行运行。迁移、共享状态更改以及任何触及同一契约的事情必须是顺序的。
退出条件： 存在一个依赖图，具有清晰的前沿，并且没有循环。
阶段 3：垂直切片
将工作切割成跟踪子弹：贯穿该功能所需的每一层的狭窄但完整的路径。
水平切片是默认错误。 它看起来整洁，但在最后一个任务之前产生不了任何可运行的东西：
错误（水平）：
任务 1：构建整个数据库架构
任务 2：构建所有 API 端点
任务 3：构建所有 UI 组件
任务 4：连接所有内容
在任务 3 结束时，没有任何东西能工作。没人能演示任何东西。任务 1 中的错误假设在任务 4 中被发现。
垂直切片在每一步都产生可工作的软件：
正确（垂直）：
任务 1：用户可以创建账户（注册的架构 + API + UI）
任务 2：用户可以登录（登录的身份验证架构 + API + UI）
任务 3：用户可以创建任务（创建的任务架构 + API + UI）
任务 4：用户可以查看任务列表（列表视图的查询 + API + UI）
一个好的切片的规则：
- 它贯穿行为需要的每一层——数据、逻辑、接口、测试。
- 它本身是可演示或可验证的。 如果你无法描述如何确认它工作，那它就不是一个切片。
- 它适合一个专注的会话——大致一个全新的上下文窗口。
- 它交付行为，而非结构。 “添加 users 表”不是一个切片；“用户可以注册”才是。
大规模重构是例外。 大规模重构是一个机械变更（重命名列、重新类型化共享符号），其影响范围遍及整个代码库，因此任何垂直切片都无法保持绿色。不要强行将其放入跟踪子弹。将其排序为扩展、迁移、收缩：
- 扩展 — 在旧形式旁边添加新形式，这样什么都不会破坏。
- 迁移 — 按影响范围分批（按包、按目录）迁移调用点，每个批次是一个自己的任务，被扩展阻塞，由于旧形式仍然存在，批次之间保持构建绿色。
- 收缩 — 一旦没有调用者剩余，删除旧形式，在一个被每个迁移批次阻塞的任务中完成。
即使批次无法单独保持绿色，也保持相同的序列，但让它们共享一个集成分支，该分支阻塞一个最终的集成和验证任务，其中承诺绿色。
退出条件： 每项工作恰好属于一个任务，并且每个任务是一个垂直切片或声明的大规模重构步骤。
阶段 4：编写每个任务
将每个任务写为它自己的文件。始终每个任务一个文件——绝不是包含所有任务的单个组合文档。
输出路径： tasks/<名称>/task-NN.md，其中 <名称> 与 PRD 的名称匹配（因此位于 docs/prd/billing.md 的 PRD 产生 tasks/billing/task-01.md）。从 01 开始编号，按依赖顺序——阻塞项获得较小的编号。
任务文件模板：
# Task NN：<短描述性标题>
**来源：** docs/prd/<名称>.md — <此任务实现的 PRD 部分>
**构建内容：** 此任务使其工作的端到端行为，从用户的角度来看。不是逐层实现列表。如果你无法将其描述为用户或调用者可以观察到的行为，请重新调整任务。
## 验收标准
- [ ] <特定的、可测试的条件>
- [ ] <特定的、可测试的条件>
每个标准必须可由未编写该任务的人检查。“正常工作”不是标准。“用户可以使用电子邮件和密码注册，并被重定向到仪表板”才是。
## 验证
- [ ] 测试通过：<存储库的聚焦测试命令或要首先编写的新测试>
- [ ] 构建成功：<存储库的构建命令>
- [ ] 输出匹配：<预期的模式或必须存在的工件>
- [ ] 无回归：<完整套件或相关子集>
- [ ] 质量与安全：<输入验证、身份验证边界、遵循标准实践>
...（由于原文被截断，此处省略部分内容）
...（继续模板的其余部分）
退出条件： 每个任务都有自己的文件，已填充。
注意：由于原始输入被截断，翻译后的 skillMarkdown 也相应地包含截至提供的部分。完整的技能文档将包括剩余的阶段（阶段 5-8）、并行化分类和重新规划部分。