用途
ai-factory.task 用于为一项功能或任务创建一个分步、可执行的实现计划，并将工作拆解为可通过任务系统跟踪的具体任务。当用户表达「plan」等规划意图时使用该技能。
主要能力
- 加载项目上下文：优先读取 .ai-factory/DESCRIPTION.md（若存在），以了解技术栈（语言、框架、数据库、ORM）、项目架构、编码约定，以及日志、错误处理等非功能性要求，并在探索代码库、编写任务描述和规划文件结构时使用这些上下文。
- Git 检查与计划文件确定：检查是否为 git 仓库（git rev-parse --is-inside-work-tree 2>/dev/null || git init）。若由 /ai-factory.feature 调用，使用传入的计划文件名（例如 .ai-factory/features/feature-user-auth.md）；若直接调用 /ai-factory.task，则始终使用 .ai-factory/PLAN.md。不检查当前分支。直接任务规划使用临时计划文件 .ai-factory/PLAN.md。
- 需求分析：从 $ARGUMENTS 中识别需实现的核心功能、需变更的组件与文件、任务之间的依赖关系，以及需要处理的边界情况。
- 澄清提问：若需求存在歧义，会在创建计划前提出具体问题（如范围、实现方式）。
- 测试偏好确认：若未从 /ai-factory.feature 指定，会询问是否在计划中包含测试任务。若用户选择「否」，则不会创建任何测试相关任务、不在任务描述中提及测试、也不添加「写测试」步骤。
- 代码库探索：在规划前查找相关文件与模式，确定需要修改的位置，并遵循既有约定。
- 创建任务计划：使用 TaskCreate 创建清晰、可执行的任务，包含任务主题、描述和涉及文件。
- 设置依赖关系：使用 TaskUpdate 设置 blockedBy 关系，保持依赖链合理。
- 保存计划文件：将计划写入确定的计划文件，包含分支、创建日期、设置（测试、日志、文档）、提交计划（5 个以上任务时）和按阶段划分的任务清单。保存前确保目录存在（mkdir -p .ai-factory/features，仅在保存到 features/ 时）。
- 确认计划：向用户展示计划保存位置，并提示使用 /ai-factory.implement 开始执行。
任务创建格式
使用 TaskCreate，包含 subject（任务主题）、description（描述，含具体要求与文件路径）和 activeForm（进行中描述）。
使用方式
- 直接调用 /ai-factory.task，用于临时任务的快速规划，计划文件为 .ai-factory/PLAN.md。
- 由 /ai-factory.feature 调用，计划文件为按分支命名的特性文档。
- 计划完成后，运行 /ai-factory.implement 开始执行；使用 /tasks 或 TaskList 查看任务。
提交计划规则
- 5 个及以上任务：每 3-5 个任务添加提交检查点。
- 少于 5 个任务：最后单次提交，无需提交计划。
- 将逻辑相关的任务归为一组提交，提交信息建议遵循 conventional commits。
日志要求
每个任务描述都必须包含日志要求，例如需记录的内容（输入、输出、状态变化、错误）、日志格式建议（尽可能使用结构化 JSON）、关键检查点等。日志应支持按级别记录（DEBUG/INFO/WARN/ERROR）、通过环境变量（如 LOG_LEVEL）控制、注意文件日志轮转，并可在生产环境中无需改代码即可降低日志量。
适用场景
适用于需要把功能或任务拆解为可跟踪实施步骤的开发规划场景，例如为 API 功能（如添加商品搜索 API）制定包含服务层、端点、查询参数解析、分页等任务的计划。
限制与规则
- 用户选择不测试时，绝不添加测试任务。
- 不创建报告类任务（如最后的总结/报告）。
- 每个任务应有明确交付物，粒度适中，按依赖顺序排列，包含文件路径。
- 直接调用时始终使用 .ai-factory/PLAN.md；分支命名文件仅来自 /ai-factory.feature。
- 计划完成后可建议清理上下文（/clear、/compact 或继续）。
- 计划文件处理：.ai-factory/PLAN.md 为快速任务的临时计划，完成后 /ai-factory.implement 会询问是否删除；分支命名文件为特性工作的永久文档，不会被建议删除。
- 本文档未提供收费、价格或具体平台支持等信息。