SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场wtf.loop

wtf.loop

编程与开发

查看项目

更新于 10-16 02:24

技能介绍

用途

wtf.loop 用于在规格树（Epic → Features → Traces）已完整定义后，让开发者通过一句“go”自主执行某个 Epic 或 Feature 下的全部 Trace。它的调度单元是 Trace，而不是 Feature 或 Epic。

主要能力

  • 对每个 Trace 串联执行：wtf.implement-trace → wtf.verify-trace → wtf.create-pr。
  • PR 合并后，通过无头 wtf.refine 重新调整父 Feature 的 Trace Plan。
  • Feature 的 Skeleton 先单独运行；其余 Trace 按文件冲突图调度，不共享文件的 Trace 可同时运行。
  • Trace 分支基于其所依赖的 Trace 分支创建，不等待合并，PR 堆叠由 GitHub 处理。
  • Feature 之间在跨 Feature 冲突图允许时并行运行。
  • 仅将必须由人做出的决策暴露出来。

前置条件

开始前必须满足：

  • 每个目标 Feature 都有 Trace Plan，且其 Trace issue 已存在（wtf.feature-to-traces 完成）。
  • 每个 Trace Plan 以恰好一个 Skeleton 开头。
  • 每个 story 的 Scenario Claims 完整划分该 story 的场景——全覆盖、无重叠。
  • 所有 Trace 均已设计（wtf.design-trace 完成，存在 designed 标签），或用户明确豁免。

任一前置条件不满足时，会作为 gate 暴露（步骤 2），不会静默停止。

交付模式

交付模式按 ../references/branch-setup.md 解析一次，并尊重 Feature 正文中声明的按 Feature 覆盖。

  • staged：Trace PR 合并进 feature 分支；Trace Plan 用尽后，feature PR 合并进 main。
  • trunk：Trace PR 直接合并进 main，不存在 feature 分支；最后一个 Trace PR 通过 Closes #<feature_number> 关闭 Feature。

使用方式（流程）

  1. GitHub CLI 设置：运行 ../references/gh-setup.md 的步骤 1–2（安装 + 认证）。若 gh 未安装或未认证则停止。检查所需扩展：yahsan2/gh-sub-issue（层级遍历）、xiduzo/gh-issue-dependency（依赖排序），缺失则先安装。

  2. 识别目标并构建依赖图：通过 AskUserQuestion 询问要执行什么（每个 open Feature 一个选项，或一个 Epic 的全部 features 选项，或恢复上次运行）。获取层级（gh issue view、gh sub-issue list），读取每个 Feature 正文中的有序 Trace Plan、带规范 Gherkin 的 stories 及交付覆盖。构建带父级上下文的完整节点列表，遍历完整传递闭包，构建有向依赖图（blocks / blocked_by / rolls_up），将 Trace 折叠为 Feature 单元，并把依赖边分类为内部或外部。

  3. 预检校验：按 references/pre-flight-validation.md 运行四项检查（规格完整性、矛盾扫描、代码库现实、依赖校验），尽可能并行。依赖校验步骤产出步骤 3 和 4 使用的 phases → sub_phases → units 结构。

  4. 提出执行计划并等待批准：以依赖排序的计划形式呈现，在人工明确批准前不开始任何实现。通过 AskUserQuestion 提供选项：Approve（开始循环）、Remove a unit（移除单元）、Change the order（更改顺序）、Decline（停止）。仅在明确“Approve”后才继续。

  5. 执行每个 Trace：按 references/trace-execution.md 运行逐 Trace 序列：a. 合并 + 依赖 gate，b. 实现，c. 验证，d. 打开 PR + 流水线 + 合并，e. 通过无头 refine 重新瞄准，f. 计划对账，g. 进度更新。所有 Agent 调用应用 ../references/subagent-protocol.md。将 NEEDS_INPUT 块和重新瞄准的集合变更提议收集到待处理 gate 列表，按 Feature 分组批量呈现。

  6. Feature 完成（感知交付模式）：当 Trace Plan 用尽时按 Feature 单元运行。staged 交付下，从 feature 分支向 main 打开 PR，需先确认两个信号（合并的 PR 列表、Trace Plan 全部勾选）；trunk 交付下无 feature PR，最终 Trace PR 携带 Closes #<feature_number>。

  7. 总结：打印最终摘要，包括完成的 Trace 数、跳过的 Trace 数、应用的重新瞄准数、合并的 PR 列表、Feature PR 或已关闭的 Feature。若有 Trace 被跳过，列出原因并建议后续操作。

人工介入 gate

循环仅在以下情况暂停并请求人工输入：规格矛盾（Trace claim 与 Feature 场景、Feature 与 Epic）、Scenario Claims 未划分 story、Trace Plan 缺失或 Skeleton 缺失/非首位、代码库不匹配、内部循环依赖、外部阻塞未合并/关闭、运行中内部阻塞被跳过或未合并、重新瞄准提议增删场景或 story、声称的场景未被测试套件覆盖、覆盖的测试失败、PR 流水线检查失败、feature PR 前存在待处理 trace PR（staged）。

适用场景

适用于已具备完整规格树、希望自主批量执行 Trace 的开发工作流，尤其是需要按依赖与文件冲突并行调度、并堆叠 PR 的场景。

限制

  • 依赖 GitHub CLI 及两个扩展（gh-sub-issue、gh-issue-dependency）。
  • 需要满足全部前置条件，否则会作为 gate 暴露。
  • 在多种需要人工决策的情况下会暂停，不会静默继续。
  • 关于收费、价格、平台支持范围等事实，资料中暂未提供。