steve-swanson/execute-work

执行工作

在从 develop 分支创建的一个有意义的分支上自主执行商定的工作。将实现委托给子代理在单独的工作树中完成，然后将它们完成的分支快进合并到该协调分支中，清理环境，并从完成的协调分支向 develop 打开一个待审拉取请求。

调用该技能授权创建本地任务分支、工作树、提交、重置您自己的未发布任务分支、快进合并到协调分支、删除已清理且完全集成的任务工作树和分支、推送完成的协调分支，以及创建其指向 develop 的 PR。无需再为这些操作请求确认。遵循用户的范围和仓库说明，包括显式的仅本地或无 PR 覆盖。合并 PR 和部署不在本技能的授权范围内。保持任何现有的禁止性规定有效。

1. 准备协调分支

阅读已批准的计划、适用的 AGENTS.md 文件以及必需的项目指南。如果工作已定义，则直接执行，无需再进行设计或审批。仅当发现实质性缺失需求时，提出一个聚焦的问题。

检查状态、引用和现有工作树。保留无关的编辑和检出；不要重置、暂存或重新利用它们。当可用时，从其配置的远程获取 develop 并使用该获取的最新提交。如果无法获取，披露此限制并使用现有的本地 develop 引用；如果两者都不存在，请求基础分支。切勿静默替换为其他分支。

在创建任何分支或工作树之前，捕获 git worktree list --porcelain、本地分支名称以及可用的托管工作树附件。在任务清单中维护一个运行拥有的清单：分支、绝对路径、所有者/代理、管理类型和标识、最终提交以及清理状态。包括为此运行创建的每个任务、助手、审查者、重试和后代代理检出，即使已被放弃或不包含任何更改。协调者负责此整个清单的清理。保留预先存在和不相关的分支/工作树；匹配的名称前缀不是所有权证明。

创建一个专用的协调工作树和分支。使用常规分支样式命名：<类型>/<短描述>，小写字母加连字符，例如 feat/store-invitation-recovery。选择适合工作的类型：feat（新行为）、fix（错误修复）、refactor、perf、docs、test、chore（工具或维护）或 ci。如果用户或仓库指定了不同的约定（例如在 AGENTS.md 中），则遵循该约定。名称中不要包含 integration。 记录协调基础提交。在恢复调用时，重用此运行的协调分支/工作树和清单，检查其状态，而不是重新开始。

2. 分解并委派

按可交付成果和文件所有权分解。在可用的代理容量内并行运行独立任务；对依赖项和重叠编辑进行排序。从协调分支的当前最新提交创建每个任务分支/工作树。在依赖项集成后，从更新的最新提交开始依赖任务。

启动实际的子代理，并附带任务要求、相关计划部分、绝对工作树路径、分支、拥有的文件、依赖契约、验收标准和所需检查。每个代理仅在其分配的检出中工作，提交其更改，并报告其提交、检查、剩余关注点以及其创建的任何其他分支/工作树。立即在运行拥有的清单中注册这些内容。协调者独自负责集成和删除工作树。子代理不得递归调用此编排技能或推送其分支。使用显式工作目录或 git -C；代理可以共享一个默认目录。如果委派不可用，报告该限制，而不是静默替换为单独执行。

3. 审查已完成的任务

对照其验收标准检查每个任务的实际差异和提交。与负责代理一起处理失败情况。在集成之前，要求任务检出干净、完成提交以及通过相关检查；准确报告预先存在或环境障碍。不要仅仅因为代理报告完成就合并工作。

4. 通过快进合并串行集成

在变基之前停止对已完成任务分支的写入。对于每个任务，检查其祖先关系与协调分支的 当前 最新提交。并行兄弟分支在第一次合并后出现分叉：在合并之前，将每个剩余未发布的任务分支变基到更新的协调分支上。对照商定的要求解决冲突，保留已集成的行为；在变基或解决冲突后重新运行受影响的检查。

使用记录的绝对路径和分支名称的示例：

git -C "$task_path" rebase "$work_branch"
git -C "$task_path" status --short
# 在 task_path 中运行所需的检查，然后验证祖先关系。
git -C "$work_path" merge-base --is-ancestor HEAD "$task_branch"
git -C "$work_path" merge --ff-only "$task_branch"

在继续之前检查每个命令的结果。如果快进失败，重新检查祖先关系并根据需要再次变基。不要替换为合并提交、压缩、cherry-pick、强制推送或重置协调分支。如果安全解决需要产品决策，则保留两个分支并询问。在每个成功的任务集成及其所需检查之后，立即对该任务执行下面的所需清理。从协调检出中审查合并后的工作；合并后的任务检出不需要用于 PR 审查。对其工作已处理过的、被放弃或被取代的运行拥有助手应用相同的清理。

5. 验证、清理并打开 PR

在最终的协调分支上运行相关的组合检查，并将结果与整个计划进行核对。在完成之前修复集成回归。

所需清理：执行并验证

清理是可交付成果的一部分，不是供用户稍后执行的建议。调用已授权删除此运行中干净、完全集成的任务/助手工作树和分支；不要再次请求这些删除。

1. 停止拥有代理以及向检出写入的任何后台进程。记录分支在 变基后 的最终提交，验证它是当前协调分支最新提交的祖先，并检查已跟踪、未跟踪和忽略的文件。对于没有提交的助手，也验证其最新提交已被包含。与所有者一起处理未完成的工作：在继续之前集成所需的更改并将有价值的本地工件保留在保留的位置。可以通过精确路径删除可丢弃的运行生成缓存或日志；它们不是让一个原本完成的检出无限期保留的理由。

2. 对于普通的 Git 工作树，使用记录的精确路径和名称执行以下操作，在继续之前检查每个结果：

   git -C "$work_path" merge-base --is-ancestor "$task_tip" "$work_branch"
   git -C "$task_path" status --porcelain --untracked-files=all
   git -C "$work_path" worktree remove "$task_path"
   git -C "$work_path" branch -d "$task_branch"
   

   工作树的删除不会删除其分支。两个操作都是必需的。同时删除没有剩余工作树的运行拥有分支。切勿使用强制删除、git branch -D、广泛的目录删除或丢弃未知编辑。诊断失败的命令并在范围内修复常规清理问题，而不是静默跳过。

3. 对于应用管理的工作树，使用其管理 API 而不是直接删除目录。在 Codex 中，使用 list_artifacts 解析确切的拥有工作树标识，然后使用 archive_worktree；检查结果并重新列出以确认其不再活动。之后在其仍然存在的情况下使用 git branch -d 删除其运行拥有的本地分支。存档快照或应用附件不能替代检查 Git 注册和分支删除。

4. 仅在验证其确切路径不存在、git worktree list --porcelain 不再注册、本地引用中不存在其分支以及任何托管附件不再活动后，才将清单条目标记为已清理。如果 Git 指示分支仍被检出，请检查其他检出。不要将成功的删除请求或代理的报告视为证据。

5. 在最终响应之前，在 PR 创建或任何后期审查工作之后，重复 Git 分支/工作树和托管附件清单。将它们与基线以及运行拥有的清单进行比较；解释代理报告中遗漏的新条目，而无需删除不相关的并发工作。协调分支/工作树必须是 唯一剩余的运行拥有的分支/工作树。保留它用于 PR 和测试，同时保留预先存在或不相关的检出。即使 PR 创建被阻止或跳过，以及失败/中断时在安全的情况下交出控制权之前，也始终需要此最终审核。

如果清理无法安全完成，继续清理其他符合条件的条目并报告 清理受阻，包括每个保留的分支/路径、确切失败的操作或有价值/未合并的工作，以及解决它所需的最小操作。当运行拥有的临时分支/工作树仍然存在时，不要报告整个工作流已完成。持续处理常规清理，而不是在成功合并、通过测试或创建 PR 时结束。

推送并打开 PR

保留协调分支/工作树及其所有已提交的工作，以备审查。在集成和所需验证成功后，检查最终差异并将协调分支推送到目标仓库的远程。创建一个指向 develop 并以此为基准、协调分支为头部的待审 PR；仅当用户明确要求时才使用草稿。在创建之前，检查此头部/基准是否已存在开放的 PR，包括在创建结果不确定的情况下，并重用或更新它，而不是创建重复。

遵循仓库 PR 模板、标题约定和工单链接要求。描述最终行为、检查及其结果以及具体的手动测试步骤。这些步骤必须描述对产品的实操和/或检查持久状态，而不是另一个仓库测试命令列表。优先使用本地 Git 进行推送，使用可用的仓库连接器进行 PR 创建；适当时候使用经过身份验证的 CLI。验证 PR 的实际基准、头部和发布的提交与完成的协调分支一致。当工件附件工具可用时，将每个创建的 PR 附加到当前聊天。保持 PR 开放以供审查。

如果推送或 PR 创建受阻，保留完成的协调分支/工作树，并报告确切的阻止因素和剩余操作。在未确认 URL 的情况下不要声称存在 PR，也不要通过强制推送绕过拒绝。

完成报告

最终响应必须以精确的协调分支名称和绝对工作树路径开头。包含一个指向已确认 PR 的 Markdown 链接，或说明 PR 创建为何被阻止或显式跳过，然后包括：

• 现在可用的功能： 已完成的行为以及任何剩余范围。
• 已运行的检查： 确切的命令和实际结果，指出已跳过或受阻的检查。
• 如何测试： 一个简短的、编号的、用户可执行的、从协调工作树开始的验证过程。这与自动化检查分开，不能通过重复 pnpm test、lint、build 或类似命令来满足。包括下列各项（如适用）：
  • 设置：环境/应用 URL、登录和角色、服务、种子或夹具数据、记录 ID 以及工作目录；
  • 主要产品流程：确切的屏幕或端点、真实输入和 UI 操作、要触发的行为以及预期的可见结果；
  • 相关的边缘或回归流程：当这些情况重要时，针对无效、空、重复、受限或先前已完成的数据；
  • 对于写入或转换数据的更改，进行持久状态验证：提供只读的数据库/API 检查，包含表或资源、过滤器或标识符、要检查的字段/状态以及预期结果。将用户操作与存储的记录联系起来，而不仅仅是说“检查数据库”。 例如，一个勘探更改应该说明：为指定区域和半径创建一个区域扫描，找到一个特定地点，确认其必需属性，完成审查/外联操作，并在应用程序和相关记录中验证生成的审查或外联状态。为其他产品工作流使用相同级别的具体性。 将自动化命令保留在 已运行的检查 下。将每个手动步骤标记为已执行或建议；如果应用程序或数据库不可用，说明确切的阻碍因素和运行它所需的最小设置。数据库检查是只读的，除非批准的工作明确授权测试数据变更。
• 清理和阻碍因素： 已验证的已删除或已归档的临时工作树数量以及已删除的本地分支；最终审计中剩余的运行拥有分支/工作树（通常是协调者）。列出每个受阻的临时分支/路径及其确切原因；包括任何不完整的推送或 PR 步骤。

保持进度更新简洁，并以一个可在两分钟内完成的、具体的下一个操作结束。