Atomic Tasks Skill 提供了一套创建结构化、原子化任务的模式，遵循“一个任务 = 一次提交 = 一件事”的原则。
一、用途 该技能用于把工作拆分为细粒度、可验证的任务单元，帮助在规划与执行阶段保持任务边界清晰、可独立验证、可安全提交、便于回滚。
二、核心原则：原子性 每个任务应当是：
- 自包含：完成单一逻辑工作单元；
- 可独立验证：能够在隔离状态下测试/验证；
- 可安全提交：单独提交后代码库仍可工作；
- 便于回滚：可被还原而不破坏其他任务。
三、任务属性 任务包含以下属性（是否必需如下）：
- id：唯一标识（TASK-XXX），必需；
- status：当前状态（pending/in_progress/completed/blocked），必需；
- name：简短描述性名称，必需；
- description：该任务要完成的内容，必需；
- depends：所依赖的任务 ID，非必需；
- files：要创建/修改的文件，必需；
- actions：要采取的具体步骤，必需；
- verify：如何验证完成，必需；
- done：完成标准，必需；
- commit：Conventional commit 提交信息，必需。
四、任务粒度指南 过大（需要拆分）：涉及超过 5 个文件；超过 5 个动作；耗时超过 30 分钟；混合多个逻辑关注点；提交信息需要多次使用“and”。 过小（需要合并）：仅重命名变量；无逻辑的单行改动；无法有意义地验证；会在 git 历史中造成噪声。 刚好合适：通常修改 1-3 个文件；2-5 个清晰动作；单一职责；有明确验证步骤；提交信息简洁。
五、任务状态流转 pending ─── in_progress ─── completed；in_progress 可进入 blocked（外部依赖）；pending 可进入 skipped（不再需要）。
六、依赖管理 依赖类型包括：代码依赖（任务 B 需要任务 A 的代码）、Schema 依赖（任务 B 需要任务 A 的数据库改动）、配置依赖（任务 B 需要任务 A 的配置）、知识依赖（任务 B 需要任务 A 收集的信息）。 依赖规则：不允许循环依赖；尽量减少依赖链（优先可并行任务）；记录依赖存在的原因；若被阻塞任务耗时过长需重新评估。
七、验证模式 自动化验证示例： <verify> <step>npm test -- [test-pattern]</step> <step>npm run build</step> <step>npm run lint -- [file]</step> </verify> 手动验证示例： <verify> <step>Visually confirm [UI element] appears</step> <step>Manual test: [test scenario]</step> </verify> 组合验证示例： <verify> <step>npm test -- auth</step> <step>Manual: Login with test credentials</step> <step>Check logs for errors</step> </verify>
八、完成标准模式 功能任务： <done> <criterion>Feature is accessible via [entry point]</criterion> <criterion>Tests cover happy path and error cases</criterion> <criterion>No new lint warnings introduced</criterion> </done> Bug 修复任务： <done> <criterion>Original issue no longer reproduces</criterion> <criterion>Regression test added</criterion> <criterion>Related functionality still works</criterion> </done> 重构任务： <done> <criterion>All existing tests still pass</criterion> <criterion>No functional changes detected</criterion> <criterion>[Quality metric] improved</criterion> </done>
九、提交信息约定 遵循 Conventional Commits： <type>(<scope>): <description>
[optional body]
[optional footer] 类型包括：feat（新功能）、fix（Bug 修复）、refactor（代码重构）、test（新增/更新测试）、docs（仅文档）、chore（维护任务）、style（格式调整）、perf（性能改进）。 示例：feat(auth): add login endpoint；fix(cart): prevent negative quantities；refactor(api): extract validation middleware；test(user): add registration edge cases。
十、任务拆解流程
- 从目标开始：最终结果是什么？
- 识别主要组件：需要哪些不同部分？
- 检查依赖：必须按什么顺序进行？
- 评估每个组件大小：每个是否原子化？
- 必要时拆分：把大组件拆小。
- 定义验证：如何知道每个任务已完成？
- 编写提交信息：强制明确目的。
十一、需要避免的反模式 The Kitchen Sink（大杂烩）：过多不相关改动，例如 <task id="TASK-001"><name>Add auth and update styling and fix bugs</name>...</task>。 The Invisible Task（不可见任务）：无法验证，例如 <task id="TASK-001"><name>Improve code quality</name><verify></verify></task>。 The Dependency Chain（依赖链）：过长的顺序链，例如 TASK-001 → TASK-002 → TASK-003 → TASK-004 → TASK-005。 The Vague Action（模糊动作）：不可执行，例如 <actions><action>Make it better</action><action>Fix the thing</action></actions>。
十二、与工作流集成 PLAN 阶段：使用 XML 格式创建所有任务；验证跨计划一致性；确立执行顺序。 EXECUTE 阶段：一次处理一个任务；标记状态流转；每次之后运行验证；成功后提交。 VERIFY 阶段：复查所有已完成任务；运行集成验证；确认满足完成标准。 完整 XML schema 参考见 xml-format.md。