[HINT] Download the complete skill directory including SKILL.md and all related files
| name | ae:work |
| description | 按计划高效执行工作，保持质量并完成功能交付 |
| argument-hint | [计划路径|工作描述] |
按计划高效执行工作，保持质量并完成功能交付。
本技能接收一份工作文档或一段描述工作的提示词，并系统化地执行。核心目标是交付完整功能。
<input_document> #$ARGUMENTS </input_document>
计划文档（输入为路径）→ 跳至阶段 1，并先分析计划中的工作单元、依赖关系、文件范围和验证要求，识别可并行执行的单元。
裸提示词（输入为工作描述）：
| 复杂度 | 信号 | 操作 |
|---|---|---|
| S3 轻量修复 | 明确 bug、单点故障、预估不超过 2 个生产文件 | 记录定位证据、升级判断和无需计划原因后，进入阶段 1；完成准备环境 / worktree 决策后再实现 |
| S3 扩展任务 | 范围明确，但需要多个步骤协作 | 构建任务列表，标注依赖、文件范围和验证要求，进入阶段 1 |
| S4 多步骤实现 | 跨模块、架构决策、需求模糊、10+ 文件 | 停止实现并建议先运行 /ae-plan；纯重构或架构债治理先运行 /ae-refactor |
阅读计划并澄清（若从裸提示词进入则跳过）
Execution note、Deferred to Implementation、Scope Boundaries准备环境（硬性门禁 — 不得跳过）
⛔ 执行阻断规则：以下所有子步骤必须在修改任何项目文件之前完成。未完成时，不得进入阶段 2、不得执行实现、不得修改任何
.ts、.js、.md、.json或其他项目文件。违反此规则等同于流程失败。
2a. 解析 worktree 模式
worktree、current-worktree、auto--no-worktree 映射为 current-worktreeae:lfg 或 ae:task-loop，只接收其透传的模式；调用方未显式传入时由调用方补齐并传入 autoae:work 且未显式传入三值中的任何一个时，必须向用户询问，不得自行推断或默认采用 auto2b. 执行 Git 状态检查（必须实际运行命令）
必须实际运行以下命令并获取输出，不得凭假设跳过：
git status --short
git branch --show-current
git log --oneline -1
记录：当前分支、工作区脏状态（有/无）、最近提交。
2c. 风险评估与用户确认
根据 Git 状态和 worktree 模式，向用户展示风险评估并等待确认：
| 场景 | 必须向用户说明的风险 | 必须提供的选项 |
|---|---|---|
| 默认分支 + 脏工作区 | "当前在默认分支 {branch} 上，工作区有未提交变更。在默认分支做功能开发会污染历史。" | 创建 worktree / 创建功能分支 / 继续当前工作区（需二次确认风险） / 取消 |
| 默认分支 + 干净工作区 | "当前在默认分支 {branch} 上。" | 创建 worktree / 创建功能分支 / 继续当前工作区（需二次确认风险） / 取消 |
| 功能分支 + 脏工作区 | "当前在功能分支 {branch} 上，工作区有未提交变更。" | 创建 worktree / 继续当前工作区 / 取消 |
| 功能分支 + 干净工作区 | "当前在功能分支 {branch} 上。" | 创建 worktree / 继续当前工作区 / 取消 |
用户选择取消时：立即终止 ae:work，只输出取消状态和 worktree_decision: cancelled，不得修改任何文件。
2d. 记录决策
无论用户选择什么，必须在后续所有输出中记录：
worktree_mode：worktree / current-worktree / autoworktree_decision：created / rejected / transferred / cancelled / not_applicablebranch：实际执行的分支名recommendation_basis：推荐依据（auto 模式必须记录）2e. worktree 创建流程（仅当用户选择创建时）
git worktree add 命令参数的明确授权../worktrees/<name>，<name> 使用分支名或任务名净化后的短名docs/ae/handoffs/<timestamp>-worktree-handoff.mddocs/ae/handoff-*.md、A worktree 路径或其他等价路径；写错位置时必须停止并报告流程失败，不得继续实现ae:work 阶段 2-4，只返回/报告 worktree_decision: transferred、B worktree 路径、已迁移产物、交接 Markdown 路径和继续提示词source_session_id、A 的 ctx.worktree、target_worktree、branch、HEAD、授权来源、授权覆盖范围、covered_command_args、final_command_args、创建结果、已迁移产物清单和继续提示词分析任务结构
ae-task-analyzer 工具：
mode:plan，传入计划路径mode:scan，传入任务描述units）、文件冲突矩阵（conflict_matrix）和并行组（parallel_groups）创建待办列表（若已构建或路由为简单则跳过）
选择执行策略
| 策略 | 适用场景 |
|---|---|
| 内联 | 1-2 个小任务，或并行组内没有可并发的多个任务 |
| 串行子代理 | 3+ 有依赖的任务，或所有安全组都只有 1 个任务，无法获得并行收益 |
| 并行子代理 | 任一 is_parallel_safe=true 的并行组包含 2 个及以上任务；同组任务可同轮派发，不同组按 execution_order 串行推进 |
并行安全检查： 由 ae-task-analyzer 工具自动完成。工具输出的 conflict_matrix 列出了所有文件冲突，parallel_groups 标注了每个组是否 is_parallel_safe。若工具未被调用，必须手动构建"文件到任务单元"映射：若文件范围、状态、迁移、配置、公共契约、测试夹具或共享中间产物存在冲突，或任一任务依赖另一任务的未完成输出，则降级为串行。
并行子代理约束： 读取 references/work-subagent-template.md 构建每个子代理的提示。每个子代理只处理分配给自己的文件和任务；不得暂存、提交、运行全量测试套件；不得修改共享配置、锁文件、迁移文件或未分配文件；不得启动服务、浏览器测试、E2E、集成测试，或任何会占用端口、数据库、缓存、固定临时目录等共享资源的命令；遇到跨任务依赖、文件冲突、共享资源需求或需要共享中间产物时，必须停止并报告主代理。
⛔ 执行前验证：在修改任何项目文件之前，必须确认以下清单全部满足。任一项未满足时，停止执行并返回阶段 1 补齐。
- 阶段 1 步骤 2 的 worktree 决策已完成（用户已确认 worktree 模式和分支策略）
- 已实际运行
git status --short、git branch --show-current并记录输出- 用户已确认在当前分支/工作区执行（或已创建新 worktree）
worktree_decision值已确定（created/rejected/transferred/cancelled/not_applicable）如果以上清单有任何一项未满足，不得开始修改文件。先返回阶段 1 步骤 2 完成 worktree 决策。
任务执行循环或并行执行
按阶段 1 选定的策略和 ae-task-analyzer 输出执行任务：
串行执行 — 按优先级处理每个任务。
并行执行 — 按 ae-task-analyzer 输出的 parallel_groups 执行：
references/work-subagent-template.md 构建每个子代理的提示is_parallel_safe=true）的任务在同一轮消息中并发派发（使用 Task 工具）execution_order 顺序依次执行部分失败处理 — 并行组内任一子代理失败时：
所有执行都必须遵循 Execution note 指引。
测试发现 — 变更前查找已有测试文件。新行为添加新测试、变更行为修改测试、删除行为移除测试。
测试场景完整性 — 编写测试前检查计划的测试场景是否覆盖所有适用类别：
| 类别 | 适用时机 |
|---|---|
| 正常路径 | 始终 |
| 边界情况 | 有意义的边界 |
| 错误/失败路径 | 有失败模式 |
| 集成 | 跨层 |
系统级测试检查 — 任务完成前检查：回调/中间件、集成测试覆盖、失败时的孤立状态、跨接口一致性、错误策略。
并行汇总职责 — 并行子代理完成后，主代理必须：
收集所有子代理返回的 JSON 结果
检查 conflicts_found 字段，处理越权文件修改
独立运行 Git diff/status 检查真实修改文件，不只依赖子代理自报的 files_modified
将真实修改文件与每个任务的允许文件比对，确保无跨任务文件冲突或越权修改
修复集成问题
运行统一验证命令
更新最终任务状态
在阶段 3-4 执行 ae-gate
增量提交
仅当用户已明确要求提交时，逻辑单元完成且测试通过后创建提交。不使用"WIP"消息。使用约定式格式。未获授权时只保留工作区变更并汇报建议提交点。
遵循已有模式 — 优先阅读计划引用的文件，精确匹配命名约定。
持续测试 — 每次重要变更后运行测试。
持续简化 — 每 2-3 个单元后审查简化机会。
Figma 设计同步（如适用）— 按照设计规范实现，迭代对比直到匹配。
跟踪进度 — 保持任务列表更新，记录阻碍和发现。
当所有阶段 2 任务完成时，阅读 references/shipping-workflow.md 获取完整交付工作流。
在最终交付前必须调用 ae-gate workflow:work checkpoint:final，传入：
plan_path（如果本次从计划文档执行）validation_commands（本次实际运行的测试、构建、类型检查、lint 等命令）review_status（代码审查状态；未运行时说明原因）git_operations（本次会话执行过的 Git 写操作；没有则传空数组）worktree_decision（创建、拒绝、转移、取消或不适用）git_operation_args 和 git_authorization_evidence；不能只依赖 user_authorized_git_writereview_status 为 passed 或 failed，传入绑定当前 worktree、branch、HEAD 和状态摘要的 review_evidence如果 ae-gate 返回 status: block，先补齐阻断项，不得宣称交付完成。
最终回复必须包含以下分区：已完成、已验证、未验证/无法验证、Git 操作状态、门禁结果、剩余风险。
ae-gate 的门禁结果或证明路径