/lfg · Compound Engineering 技能

重要：您必须按顺序执行以下每个步骤。不要跳过任何必需的步骤。不要跳到编码或实现。计划阶段（步骤 1）必须在任何工作开始之前完成并验证。违反此顺序会产生不良输出。

调用下面引用的任何技能时，请根据主机平台提供的可用技能列表解析其名称，并使用该确切条目。某些平台在插件命名空间下列出技能（例如 compound-engineering:ce-plan）；其他人列出了裸名。调用不在列表中的简短猜测将会失败 - 在调用技能/任务工具之前始终逐字匹配列出的条目。

使用 $ARGUMENTS 调用 ce-plan 技能。

门：停止。如果 ce-plan 报告该任务是非软件任务，无法在管道模式下处理，请停止管道并通知用户 LFG 需要软件任务。否则，验证 ce-plan 工作流是否在 docs/plans/ 中生成了计划文件。如果未创建计划文件，请使用 $ARGUMENTS 再次调用 ce-plan。在书面计划出现之前，请勿继续执行步骤 2。 记录计划文件路径 — 它将在步骤 3 中传递给 ce-code-review。

调用ce-work 技能。

门：停止。验证实施工作是否已执行 - 文件的创建或修改超出了计划。如果未更改代码，请勿继续执行步骤 3。

使用 mode:agent plan:<plan-path-from-step-1> 调用 ce-code-review 技能。

传递步骤 1 中的计划文件路径，以便 ce-code-review 可以验证需求完整性。阅读该技能发出的可行的发现摘要。

应用并保留审核修复（在步骤 3 之后、剩余移交之前需要）

加载 references/review-followup.md 并在那里执行步骤 4（存在更改时机械应用 + 提交/推送）。当合格的审核修复仅保留在未提交的工作树中时，请勿继续执行步骤 5、运行浏览器测试或输出 DONE。

自主剩余切换（仅当步骤 3 报告步骤 4 中未应用的一项或多项可操作 downstream-resolver 结果时；在报告 Actionable findings: none. 时跳过）

不提示用户。这一步包含了自动驾驶合约：残差必须在 DONE 之前变得持久，但代理永远不会停止询问。

在非交互模式加载references/tracker-defer.md。传递步骤 3/4 中剩余的可操作结果（或摘要被截断时的运行工件）。
1. 收取结构化回报：{ filed: [...], failed: [...], no_sink: [...] }。
2. 从结构化返回中编写 ## Residual Review Findings markdown 部分：
  - 对于 filed 中的每一项：包含严重性、文件：行、标题以及跟踪票证 URL 的链接的项目符号。
  - 对于 failed 中的每一项：包含严重性、文件：行、标题和失败原因的项目符号（例如 Defer failed: gh returned 401 — tracker unavailable）。
  - 对于 no_sink 中的每一项：逐字内嵌严重性、文件：行和标题的项目符号，以便 PR 正文或后备文件是持久记录。 4、检测当前分支的开放PR，不提示：

      gh pr view --json number,url,body,state
      ```

5. 如果存在开放的 PR，则直接使用 `gh` 更新；不要加载任何确认驱动的 PR 更新技能。附加或替换当前 PR 正文中的 `## Residual Review Findings` 部分，将新正文写入操作系统临时文件，然后运行：

```bash
      gh pr edit PR_NUMBER --body-file BODY_FILE
      ```

6. 如果不存在打开的 PR，请在 `docs/residual-review-findings/<branch-or-head-sha>.md` 处创建一个跟踪后备文件，其中包含组合部分和源 PR 审查运行上下文。仅暂存该文件，使用 `docs(review): record residual review findings` 提交它，然后推送当前分支。如果存在上游，则运行 `git push`。如果不存在上游，则动态解析可写远程：首选 `origin`（如果存在），否则使用 `git remote` 并选择第一个配置的远程。然后运行 `git push --set-upstream <remote> HEAD`。这是耐用的无 PR 水槽。在更新现有 PR 正文或推送此回退文件提交之前，不要输出 DONE。如果两条路径都失败，则停止并报告失败的命令；不要默默地继续。

一旦残差被持久记录，切勿因跟踪器归档失败而阻止 DONE。仅当结果出现在 PR 正文或推送的后备文件中时，`no_sink` 结果才是成功。

6. 使用 `mode:pipeline` 调用 `ce-test-browser` 技能。

7. 调用 `ce-commit-push-pr` 技能。

这将提交所有剩余的更改、推送分支并打开拉取请求。如果步骤 5 已打开 PR（使用 `gh pr view --json number,url,state 2>/dev/null` 检查），请跳过 PR 创建，但仍提交并推送任何未提交的更改。

8. **CI 监视和自动修复循环**（仅当当前分支存在开放 PR 时）

检测PR；如果不存在或 `gh` 不可用，则完全跳过此步骤并继续步骤 9。

```bash
   gh pr view --json number,url,state

对于最多 3 次修复迭代，请重复：

1.等待CI完成：

      gh pr checks --watch
      ```

如果命令退出 0，则所有检查都通过。跳出循环并继续执行步骤 9。

如果它以非零值退出，则一项或多项检查失败。继续(2)。

2. 识别失败的检查并提取其失败日志。使用 `gh pr checks --json name,state,conclusion,workflow,link` 枚举失败，然后针对每个失败检查读取运行日志：

```bash
      gh run view <run-id> --log-failed
      ```

其中 `<run-id>` 是从检查的详细信息 URL 或工作流程运行中解析的。

3. 阅读故障日志，确定根本原因，并在工作树中应用修复。不要削弱、跳过或嘲笑失败的断言以使其通过——修复实际问题。如果失败是一个没有修复路径的片状测试，请将其记录为下面的剩余结果，而不是在不更改代码的情况下重试。

4. 仅暂存您更改、提交和推送的文件：

```bash
      git add <changed-files>
      git commit -m "fix(ci): <one-line summary of the failure repaired>"
      git push
      ```

5. 使用下一次尝试计数器返回迭代 (1)。

GATE：尝试 3 次失败后停止迭代。如果 3 个修复周期后 CI 仍然为红色：

- 编写 `## CI Failures Unresolved` markdown 部分，列出每个剩余的失败检查、失败摘要和运行/检查 URL。
   - 在 PR 正文中附加或替换此部分，将新正文写入操作系统临时文件，然后运行：

```bash
     gh pr edit PR_NUMBER --body-file BODY_FILE
     ```

- 不要继续循环。自动驾驶合约是“让残差持久，然后退出”。继续执行步骤 9。

9. 完成后输出 `<promise>DONE</promise>`

现在从步骤 1 开始。请记住：先计划，然后工作。永远不要跳过计划。