chrislacey89/execute

execute 是做什么的？

执行一个完整的工作单元：规划它、构建它、验证实际结果、提交它。

调用位置

这是一个主要的流水线技能，在 /prd-to-issues 产生了具体切片后使用，或者当用户已经有一个明确范围的实现任务时使用。

当工作已准备好构建、验证和提交时，使用 /execute。

当切片在实现过程中仍然需要主动的用户判断、监督或验收决策时，使用 HITL（人机交互）/execute。仅当下一个切片已在 GitHub 中持久化、无阻塞、且在其 issue、边界图以及任何链接的研究工件（存档文件或 spike issue）或 docs/solutions/ 上下文中清晰可读时，才使用 AFK（无人值守）/execute。

对不持有任何上下文的读者来说是可读的——这就是 AFK 迭代的定义。/prd-to-issues 第 4 节的上下文完整性检查是此条件的门控：它要求每个 AFK 切片在提交 issue 之前携带一个 ### Context 块，或明确的空声明。一个标记为 AFK 但没有该块的切片从未针对此条件进行检查，仅仅是假设它满足条件。将此视为以 HITL 运行切片，或将其发回 /prd-to-issues 的理由，而不是可以随意放行的形式要求。

请参阅下面的步骤 0：先决条件，了解强制的 Ralph 自动检测和 TDD 标记门控。

当问题或形状仍未解决时，不要用它来替代 /shape、/research 或 /write-a-prd。一旦实现完成并准备好审查，不要用它替代 /pre-merge。

工作流

0. 先决条件

分支隔离门控。 在任何实现工作之前，确保你在为此特定任务创建的干净分支上工作——而不是之前工作遗留下来的功能分支。

已提供隔离——请退出（在编号规则之前先检查此项）。 有些环境在 /execute 运行之前就为会话提供了一个专用的、隔离的工作树+分支——Conductor 工作区、GitHub Codespaces、devcontainers 以及类似的主机各自提供“一个工作区 = 一个分支，从基础自动分叉”，并且设置脚本已运行。在这种情况下，流水线不拥有配置权：在此处创建工作树会将其嵌套在主机的工作树内部，并且主机的分支（以工作区而非任务命名）不是“陈旧的”。读取环境的信号，并将工作树的控制权让给已经拥有它的人（Norman——读取世界的信号，而不是携带流水线总是自行配置的脑内假设；Meadows——每个库存一个参与者，因此流水线推迟而不是增加一个竞争管理器）。

从 .claude/settings.json 的 worktree.provisioning 解析配置模式——"host" | "pipeline" | "auto"，当键不存在时默认使用 "auto"（镜像现有的 research.storage 先例）：

• host——隔离由主机拥有。无条件退出。
• pipeline——流水线负责配置。跳过退出并运行下面的编号门控。
• auto（默认）——如果任一信号触发则退出：
  • 一个主机环境变量描述此树——下面的块打印 host_owned=yes。这是最便宜的、主要的区分器：流水线唯一的检测机制是 Bash，并且这些变量在代理的 shell 中可见。仅凭存在还不够：CONDUCTOR_WORKSPACE_PATH 由在 Conductor 下启动的任何 shell 继承，并且可以命名不同仓库的工作区，因此只有当它包含当前顶级目录时才计数。（不要通过 cwd 中的 .conductor 目录来检测——Conductor 将其保存在 $CONDUCTOR_ROOT_PATH 下，而不是工作区。）
  • 当前工作树不是仓库的主工作树——git rev-parse --show-toplevel 与 git worktree list --porcelain 中的第一个路径不同。

# host-signal：主机环境变量是否描述了此树，还是仅仅描述了这个 shell？
host_owned=no
top=$(cd "$(git rev-parse --show-toplevel)" && pwd -P)
if [ -n "${CONDUCTOR_WORKSPACE_PATH:-}" ]; then
  ws=$(cd "$CONDUCTOR_WORKSPACE_PATH" 2>/dev/null && pwd -P) || ws=
  if [ -n "$ws" ]; then
    case "$top/" in "$ws"/*) host_owned=yes ;; esac
  fi
fi
if [ -n "${CODESPACES:-}" ] || [ -n "${REMOTE_CONTAINERS:-}" ]; then host_owned=yes; fi
echo "host_owned=$host_owned"

CODESPACES 和 REMOTE_CONTAINERS 没有要比较的路径，因此仅检测其存在；它们具有容器作用域，因此一个看到它们的 shell 就在描述其仓库的容器内部。相同的块出现在 /closeout、/lfg 和 /init-pipeline 中，字节完全相同，由包自身仓库中的 scripts/test-host-signal-containment.sh 固定。

退出时：跳过工作树创建和 EnterWorktree，在当前分支上原地工作。 下面的编号规则已经满足——特别是规则 3 不适用（主机配置的分支既不是基础分支也不是任务命名分支，但它不是陈旧的；不要嵌套工作树，也不要停止）。主机已经预置了 git 忽略的配置和依赖项，因此大部分“工作树设置检查清单”仅供信息参考——如果命令失败，请逐项检查 .env.local/依赖项，但不要重新配置。其 git-hooks 项是例外，仍然适用。 主机配置跟踪的文件以及依赖项；git hooks 位于 .git/hooks 中，这是每个工作树独有的且未跟踪的，因此主机配置的工作区通常没有这些 hooks。即使在退出时也要检查该项。继续执行 issue-shape 门控。

此退出故意与 /closeout 的拆除检查不对称。流入只需要回答“我已经被隔离了吗？”——通用检测（顶层目录 ≠ 主目录）和环境变量提示都可以解决这个问题。流出问题——“谁负责拆除？”——更严格，不能仅依赖通用启发式，因为流水线创建的工作树也满足顶层目录 ≠ 主目录；/closeout 仅依赖于显式设置或主机环境变量。

1. 检查当前分支：git branch --show-current
2. 如果当前分支是基础分支（例如 main、prod、master），为此任务创建一个新的功能分支。
3. 如果当前分支是一个不同的功能分支（不是基础分支，也不是为此任务命名的分支），你正处于之前工作的陈旧分支上。不要在此提交新工作。例外： 如果当前分支是此任务 Consumes from #N 声明中命名的同级切片分支，你打算故意从其分叉以进行堆叠 PR 切片——继续。例外（主机配置）： 如果上面的退出检查触发了，此分支是主机的隔离工作区分支——它不是陈旧的；原地工作。

要创建隔离分支，使用以下方法之一（按偏好顺序）：

• Worktrunk（如果 wt 可用）：wt switch --create <branch-name>——从适当的基础创建一个新的工作树 + 分支并切换到它，提供完整的文件系统隔离。使用 /worktrunk 技能获取指导。
• Plain git：git checkout <base> && git checkout -b <branch-name>——在当前工作目录中从适当的基础创建一个新分支。

适当的基础默认是仓库自身的基础分支——无论 bash "$SC" base-ref --name 打印什么，其中 SC 设置为此技能的 references/sidecar.sh。不要假设 main。对于具有未合并的 Consumes from #N 依赖关系且该依赖关系产生此切片导入的符号的切片，则从该同级切片的分支分支，以便堆叠 PR 可以以同级 PR 为目标（Hammant Trunk-Based Development 第 13 章：每个故事多个 PR；同级 PR 仍必须在 2 天内合并到仓库的基础分支）。

从任务派生分支名称：例如 issue-5-landing-page、landing-page 或 issue slug。不要重复使用之前工作的分支名称。

将会话进入工作树（当你创建了工作树时）。 创建工作树与会话在其中运行不同——wt switch --create 在每个命令后都会将 shell cwd 重置回项目根目录，因此没有进一步步骤，会话将锚定在原始检出点，报告的 cwd 会错误地反映工作发生的位置。创建工作树后，使用 harness EnterWorktree 工具进入它，以便会话的工作目录真正是工作树：

• 调用 EnterWorktree { path: <absolute-worktree-path> }。该路径必须已经出现在此仓库的 git worktree list 中（会出现，因为你刚刚创建了它）。这会将会话持久切换到工作树中。
• 将创建步骤保持完全如上所述——wt switch --create / git worktree add 运行 worktrunk pre-start hooks，这些 hooks 会预置 .env.local 和依赖项。EnterWorktree 仅切换 cwd；它不运行那些 hooks。先创建（以预置 env/依赖项），然后进入。
• 这使知识存在于世界中，而不是头脑中：cwd 真实地反映了编辑和提交的位置（观察中的操作员可以看到它），并且没有每个命令的 cd 前缀需要记住——消除了一个未加前缀的命令写入错误树的情况。
• Plain git 选项（git checkout -b，无工作树）在当前检出中创建分支——没有工作树可以进入，因此跳过 EnterWorktree 并原地工作。

AFK / 无头回退。 如果 EnterWorktree 不可用（无头运行、AFK Ralph、cron），回退到 cwd-前缀纪律：shell cwd 在每个 Bash 命令后重置为项目根目录，因此为此会话中的每个 Bash 调用加上前缀 cd <absolute-worktree-path> &&。仅在 harness 工具真正不可用时使用此方法——这是旧版变通方法，为没有本地机制的环境保留。

此工作树的拆除由流水线尾部的 /closeout 负责——PR 合并后，/closeout 将 shell 重新锚定到基础检出，移除工作树，并清理已合并的分支。/execute 是工作树生命周期的流入侧；/closeout 是流出侧。下面的步骤 6 清理仅移除 .tdd-* 标记——它故意不移除工作树。

创建工作树后，进行设置。 新的工作树会继承跟踪的文件，但不会继承 git 忽略的文件（.env.local、每个工作树的依赖项、构建缓存）。两种路径：

首选——通过 worktrunk hooks 一次性配置（项目中的 .config/wt.toml）：

[pre-start]
copy = "wt step copy-ignored"
install = "pnpm install"

pre-start hooks 是阻塞的——工作树在它们完成之前不会报告为就绪。为两者使用 pre-start（而不是 post-start），因为 post-start 在后台运行，而需要 .env.local 或 node_modules 的后续命令将与 hook 竞争。完整方法请参见 /worktrunk。项目只需执行一次。

回退——手动设置（用于普通的 git worktree add）（无 worktrunk）：

• cp <source-repo>/.env.local <worktree>/.env.local（以及项目使用的任何其他 git 忽略的配置）。
• 从工作树运行项目的安装命令（pnpm install、npm ci、pip install -r requirements.txt 等）。

工作树设置检查清单（DO-CONFIRM——执行每个步骤，然后在继续之前验证）。 无论工作树如何创建，都适用：

• Git 忽略的配置已复制——.env.local（以及任何其他 .env.*、*.local 或项目特定的忽略配置）存在于工作树中
• 依赖项已安装——安装命令（pnpm install、npm ci 等）在工作树中运行且无错误
• 会话在工作树内部——pwd 报告工作树路径，因为你通过 EnterWorktree { path } 进入了它（而不是项目根目录）。仅在 AFK/无头回退中，此项改为意味着 cd <absolute-worktree-path> && 前缀被应用于每个 Bash 调用
• $CLAUDE_PROJECT_DIR 作用域正确——如果项目在脚本中引用了此环境变量，请验证它解析到工作树路径，而不是主仓库
• 本地 git hooks 已安装且其 manager 在 PATH 上——ls "$(git rev-parse --git-dir)/hooks/" | grep -v '\.sample$' 列出了内容，并且仓库声明的 manager（lefthook、husky、pre-commit 等）可以解析。Hooks 位于 .git/hooks 中，这是每个工作树独有的且未跟踪的，因此新的工作树不会继承任何 hooks——而失败在最坏的方向上是无声的：每个提交都成功，并且仓库在提交时记录的每个保证根本就没有运行。如果 manager 不存在，要么安装它（lefthook install），要么在步骤 6 的审查说明中记录本地门控在此分支上未激活，这样没有人将绿色本地运行视为合并门控
• 分类标记不存在——.claude/.tdd-active、.claude/.tdd-skipped 和 .claude/.lfg-active 在工作树中不存在（全新状态；步骤 3 会创建一个）
• 审查后锁标记不存在——.claude/.review-stamped 和 .claude/.fix-findings-active 不存在。两者都属于上一个分支的审查：/pre-merge 第 4 阶段写入第一个，/fix-findings 写入第二个，并且 /closeout 和 /fix-findings 分别在该分支结束时移除它们。泄漏的 .review-stamped 会在此切片开始之前拒绝每个实现写入；泄漏的 .fix-findings-active 会为整个切片保持锁定打开，这是无声的方向。删除你发现的任何一个——你正处于一个从未进行过审查的分支的开始，因此两者都不能描述这个分支

Issue-shape 和阻止程序门控。 如果任务是 GitHub issue，在实现之前确认它是一个可处理的切片：不是未分解的 PRD，未被阻止，并且未被其他人的开放 PR 关闭。一次 GraphQL 读取可以回答所有三个问题，并且块做出决定——不要凭肉眼判断其中任何一个：

N=<n>
VERDICT_JQ='
def lines: split("\n")[];
[inputs][0] | if (.errors // [] | length) > 0 then "unknown" else
.data.repository.issue as $i
| if $i == null or $i.number != $n or (($i.title // "") == "")
     or ($i.bo

…

[为翻译而截断]