wtf.loop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Loop

循环

Autonomously execute a fully-specified Epic or Feature. Core value: once the spec tree is complete (Epic → Features → Tasks), the developer says "go" and the system chains

wtf:implement-task → wtf:verify-task → wtf:create-pr

for every Task in dependency order — surfacing only the decisions a human must actually make.

自主执行完全指定的Epic或Feature。核心价值：一旦规格树（Epic → Features → Tasks）完成，开发者只需发出“go”指令，系统就会按依赖顺序为每个Task串联执行

wtf:implement-task → wtf:verify-task → wtf:create-pr

流程——仅将人类必须做出的决策呈现出来。

Pre-conditions

前置条件

Before starting, the following must be true:

All Tasks under the target Feature(s) have been written (
```
wtf:write-task
```
complete)
All Tasks have been designed (
```
wtf:design-task
```
complete,
```
designed
```
label present) — or the user explicitly waives this
No Task is missing Gherkin scenarios or Contracts

If any pre-condition fails, surface it as a gate (step 2) rather than stopping silently.

开始前必须满足以下条件：

目标Feature下的所有Task已编写完成（
```
wtf:write-task
```
执行完毕）
所有Task已完成设计（
```
wtf:design-task
```
执行完毕，存在
```
designed
```
标签）——或用户明确豁免此要求
所有Task均未缺失Gherkin场景或Contracts

如果任何前置条件未满足，需将其作为关卡（步骤2）呈现，而非静默终止。

Process

流程

0. GitHub CLI setup

0. GitHub CLI 配置

Run steps 1–2 of

../references/gh-setup.md

(install check and auth check). Stop if

gh

is not installed or not authenticated.

Verify that the following extensions are available — they are required for dependency ordering and hierarchy traversal:

bash

gh extension list

Required:

```
yahsan2/gh-sub-issue
```
— hierarchy traversal
```
xiduzo/gh-issue-dependency
```
— dependency ordering
```
MeroFuruya/gh-dep
```
— dependency graph

If any are missing, install them before proceeding.

执行

../references/gh-setup.md

中的步骤1-2（安装检查和授权检查）。如果

gh

未安装或未完成授权，则终止流程。

验证以下扩展是否可用——它们是依赖排序和层级遍历的必需组件：

bash

gh extension list

必需扩展：

```
yahsan2/gh-sub-issue
```
—— 层级遍历
```
xiduzo/gh-issue-dependency
```
—— 依赖排序
```
MeroFuruya/gh-dep
```
—— 依赖图

如果缺少任何扩展，请先安装再继续。

1. Identify the target and build the dependency graph

1. 确定目标并构建依赖图

Call

AskUserQuestion

with:

```
question
```
: "What do you want to execute?"
```
header
```
: "Target"
```
options
```
pre-filled from open issues labeled
```
epic
```
or
```
feature
```
:
- ```
[{label: "Feature #<n> — <title>", description: "Execute all Tasks under this Feature"}, ...]
```
- Include an "Epic — all features" option if an Epic is available.
- Include
```
{label: "Resume a previous run", description: "Pick up where the loop left off for an in-progress Feature"}
```
  — when selected, fetch open tasks under the chosen Feature that are not labeled
```
implemented
```
  or
```
verified
```
  , and skip straight to step 4 starting from the first unfinished task. Print which tasks will be skipped (already done) and which will run.

Fetch the hierarchy:

If a Feature is selected:

bash

gh issue view <feature_number>
gh sub-issue list <feature_number>

If an Epic is selected:

bash

gh issue view <epic_number>
gh sub-issue list <epic_number>        # yields feature numbers

调用

AskUserQuestion

，参数如下：

```
question
```
: "你想要执行什么内容？"
```
header
```
: "目标"
```
options
```
从标记为
```
epic
```
或
```
feature
```
的开放议题中预填充：
- ```
[{label: "Feature #<n> — <标题>", description: "执行此Feature下的所有Task"}, ...]
```
- 如果存在Epic，需包含“Epic — 所有功能”选项。
- 包含
```
{label: "恢复之前的运行", description: "从之前中断的位置继续执行进行中的Feature"}
```
  ——选中此选项时，获取所选Feature下未标记为
```
implemented
```
  或
```
verified
```
  的开放Task，直接跳至步骤4从第一个未完成的Task开始执行。打印将跳过的任务（已完成）和将执行的任务。

获取层级结构：

如果选中Feature：

bash

gh issue view <feature_number>
gh sub-issue list <feature_number>

如果选中Epic：

bash

gh issue view <epic_number>
gh sub-issue list <epic_number>        # 返回feature编号

For each feature in parallel:

并行处理每个feature:

gh sub-issue list <feature_number> # yields task numbers


Build the full node list with parent context: `(issue_number, type, feature_number, epic_number)`. Include both Tasks and Features in the node list — features can also have cross-feature dependencies.

**Build the dependency graph:**

For every node (Task and Feature) in the list, fetch its dependency edges in parallel:

```bash
gh issue-dependency list <issue_number>

This returns two sets per issue: what it blocks and what blocks it. Record both directions for every node. Build a directed graph:

nodes:  { issue_number → { title, type, feature, labels } }
edges:  { issue_number → blocks: [issue_numbers], blocked_by: [issue_numbers] }

Classify each dependency as internal or external:

Internal — the blocking issue is within the current run's node list. Execution order must respect this edge.
External — the blocking issue is outside the current run (different feature, already-merged task, upstream work). This issue must already be merged before the loop can start.

Record this classification in the graph — it drives both the execution order (step 3) and the external blocker gate (step 2d).

gh sub-issue list <feature_number> # 返回task编号


构建包含父级上下文的完整节点列表：`(issue_number, type, feature_number, epic_number)`。节点列表需同时包含Task和Feature——Feature也可能存在跨Feature的依赖关系。

**构建依赖图：**

并行获取列表中每个节点（Task和Feature）的依赖边：

```bash
gh issue-dependency list <issue_number>

每个议题会返回两组信息：它阻塞的内容，以及阻塞它的内容。记录每个节点的双向依赖关系，构建有向图：

nodes:  { issue_number → { title, type, feature, labels } }
edges:  { issue_number → blocks: [issue_numbers], blocked_by: [issue_numbers] }

将每个依赖分类为内部或外部：

内部依赖 —— 阻塞当前任务的议题属于本次运行的节点列表。执行顺序必须遵循此依赖边。
外部依赖 —— 阻塞当前任务的议题在本次运行范围之外（不同Feature、已合并的Task、上游工作）。此类议题必须已合并，循环才能开始。

在图中记录此分类——它将驱动执行顺序（步骤3）和外部阻塞关卡（步骤2d）。

2. Pre-flight validation

2. 飞行前验证

Run all checks in parallel. Surface failures as human-in-the-loop gates — do not silently skip.

a. Spec completeness check

For each Task, verify:

```
designed
```
label is present
Gherkin section is non-empty
Contracts section is non-empty

For each Feature, verify:

Acceptance Criteria section is non-empty

For each Epic, verify:

Goal and Bounded Context sections are non-empty

b. Contradiction scan

Read each level of the hierarchy and check for contradictions:

Task Gherkin conflicts with parent Feature ACs (e.g. Task passes a scenario the Feature says should fail)
Task scope leaks outside the Feature's Bounded Context
Duplicate Gherkin scenario names across Tasks in the same Feature
Technical Approach (if present) uses a stack not in
```
docs/steering/TECH.md
```

c. Codebase reality check

For each Task's Impacted Areas and Contracts:

Check that referenced modules, files, or interfaces exist in the codebase
Check that API shapes in Contracts match current code signatures

Use the Agent tool to search the codebase for each referenced path/interface.

d. Dependency validation

Using the dependency graph built in step 1:

Circular dependency check — run a topological sort over the internal edges. If a cycle is detected, list all issues involved and hard stop — do not proceed until the cycle is broken.
External blocker check — for each external blocker, verify it is merged:
bash
```
# Check if the blocking issue is closed (merged via PR):
gh issue view <external_blocker_number> --json state,stateReason \
  --jq '"#\(.number) \(.state) (\(.stateReason))"'
```
An external blocker is resolved only if its state is
```
CLOSED
```
with
```
stateReason: COMPLETED
```
(i.e., closed via a merged PR). If any external blocker is unresolved, list them as blockers — the loop cannot start until they are resolved.
Topological sort — sort all internal nodes into an execution order that respects every
```
blocked_by
```
edge. Group nodes at the same depth into execution phases — tasks within a phase have no dependency between them and could run in parallel.

Gate — surface all findings at once:

If any pre-flight check found issues, present them grouped by type:

Pre-flight findings:
  Contradictions:    [list with issue numbers and description]
  Missing sections:  [list]
  Codebase mismatches: [list]
  Unresolved deps:   [list]
  Circular deps:     [list — HARD STOP if any]

Call

AskUserQuestion

with:

```
question
```
: "Pre-flight found [n] issue(s). How would you like to proceed?"
```
header
```
: "Pre-flight"

options

{label: "Fix before running", description: "Resolve the issues above, then re-run the loop"}

{label: "Proceed with warnings", description: "Acknowledge the issues and run anyway (not recommended for contradictions)"}

— only if no circular deps

{label: "Stop", description: "Exit — I'll address these manually"}

If no findings: continue silently.

并行运行所有检查。将失败结果作为人工介入关卡呈现——不得静默跳过。

a. 规格完整性检查

针对每个Task，验证：

存在
```
designed
```
标签
Gherkin部分非空
Contracts部分非空

针对每个Feature，验证：

验收标准（Acceptance Criteria）部分非空

针对每个Epic，验证：

目标（Goal）和边界上下文（Bounded Context）部分非空

b. 矛盾扫描

读取层级结构的每个层级，检查是否存在矛盾：

Task的Gherkin与父Feature的验收标准冲突（例如，Task通过了Feature中要求失败的场景）
Task的范围超出了Feature的边界上下文
同一Feature下的Task存在重复的Gherkin场景名称
技术方案（如果存在）使用了
```
docs/steering/TECH.md
```
中未列出的技术栈

c. 代码库真实性检查

针对每个Task的影响区域（Impacted Areas）和Contracts：

检查引用的模块、文件或接口是否存在于代码库中
检查Contracts中的API形状与当前代码签名是否匹配

使用Agent工具搜索代码库中的每个引用路径/接口。

d. 依赖验证

使用步骤1中构建的依赖图：

循环依赖检查 —— 对内部依赖边进行拓扑排序。如果检测到循环，列出所有涉及的议题并强制终止——必须先打破循环才能继续。
外部阻塞检查 —— 针对每个外部阻塞，验证其是否已合并：
bash
```
# 检查阻塞议题是否已关闭（通过PR合并）：
gh issue view <external_blocker_number> --json state,stateReason \
  --jq '"#\(.number) \(.state) (\(.stateReason))"'
```
只有当外部阻塞的状态为
```
CLOSED
```
且
```
stateReason: COMPLETED
```
（即通过合并PR关闭）时，才视为已解决。如果存在未解决的外部阻塞，将其列为阻塞项——循环必须在这些阻塞解决后才能开始。
拓扑排序 —— 将所有内部节点排序为遵循每个
```
blocked_by
```
边的执行顺序。将同一深度的节点分组为执行阶段——同一阶段内的任务之间无依赖关系，可以并行执行。

关卡——一次性呈现所有结果：

如果飞行前检查发现任何问题，按类型分组呈现：

飞行前检查结果：
  矛盾项:    [包含议题编号和描述的列表]
  缺失部分:  [列表]
  代码库不匹配: [列表]
  未解决依赖:   [列表]
  循环依赖:     [列表——如果存在则强制终止]

调用

AskUserQuestion

，参数如下：

```
question
```
: "飞行前检查发现[n]个问题。你希望如何处理？"
```
header
```
: "飞行前检查"

options

{label: "修复后再运行", description: "解决上述问题后，重新运行循环"}

{label: "带警告继续", description: "确认问题并继续运行（不建议用于矛盾项）"}

——仅当无循环依赖时可用

{label: "终止", description: "退出——我会手动处理这些问题"}

如果无检查结果：静默继续。

3. Propose the execution plan and wait for approval

3. 提出执行计划并等待批准

Present the dependency-ordered plan as a suggestion derived from the graph. Do not start any implementation until the human explicitly approves it.

Tasks within a phase have no internal dependencies between them; tasks in a later phase depend on at least one task from an earlier phase.

Proposed execution plan — Feature #<n>: <title>
─────────────────────────────────────────────
External blockers: ✅ #<x> merged  ✅ #<y> merged

Phase 1  (no blockers)
  Task #10 — Setup DB schema
  Task #11 — Define API contracts

Phase 2  (blocked by Phase 1)
  Task #12 — Settlement logic       blocked by #10, #11  ·  blocks #13

Phase 3  (blocked by Phase 2)
  Task #13 — Notifications          blocked by #12
─────────────────────────────────────────────
3 phases · 4 tasks

If executing an Epic, also show cross-feature blocking:

Feature #5 — Payment Settlement   (no feature-level blockers)
Feature #6 — Reporting            blocked by Feature #5

Call

AskUserQuestion

with:

```
question
```
: "Here's the suggested execution plan based on the dependency graph. Does this look right?"
```
header
```
: "Plan review"

options

{label: "Approve — start the loop", description: "Execute tasks in this order"}

{label: "Remove a task", description: "Drop one or more tasks from this run — I'll specify which"}

{label: "Change the order", description: "Override the suggested phase ordering — I'll describe the change"}

{label: "Decline — stop", description: "Exit without executing anything"}

If "Remove a task": ask which tasks to drop, remove them from the graph (and re-evaluate whether any remaining tasks lose all their blockers and can move to an earlier phase), then re-present the updated plan and ask again.

If "Change the order": ask the user to describe the desired change. Apply it, check that no

blocked_by

edges are violated by the new order (warn if they are but do not block), re-present the updated plan and ask again.

If "Decline — stop": exit immediately. Nothing has been implemented.

Only proceed to step 4 after an explicit "Approve" answer.

基于依赖图呈现建议的执行计划。在人类明确批准前，不得开始任何实现工作。

同一阶段内的任务之间无内部依赖关系；后续阶段的任务依赖于至少一个前序阶段的任务。

建议执行计划 —— Feature #<n>: <标题>
─────────────────────────────────────────────
外部阻塞: ✅ #<x> 已合并  ✅ #<y> 已合并

阶段1  (无阻塞)
  Task #10 — 配置DB schema
  Task #11 — 定义API contracts

阶段2  (依赖阶段1)
  Task #12 — 结算逻辑       被#10, #11阻塞  ·  阻塞#13

阶段3  (依赖阶段2)
  Task #13 — 通知功能          被#12阻塞
─────────────────────────────────────────────
3个阶段 · 4个任务

如果执行Epic，还需显示跨Feature的阻塞关系：

Feature #5 — 支付结算   (无Feature级阻塞)
Feature #6 — 报表功能            被Feature #5阻塞

调用

AskUserQuestion

，参数如下：

```
question
```
: "这是基于依赖图生成的建议执行计划。是否符合预期？"
```
header
```
: "计划审核"

options

{label: "批准——启动循环", description: "按此顺序执行任务"}

{label: "移除任务", description: "从本次运行中移除一个或多个任务——我会指定具体任务"}

{label: "调整顺序", description: "覆盖建议的阶段排序——我会描述具体调整"}

{label: "拒绝——终止", description: "退出且不执行任何任务"}

**如果选择“移除任务”：**询问要移除的任务，将其从图中移除（并重新评估剩余任务是否失去所有阻塞，可以移至更早的阶段），然后重新呈现更新后的计划并再次询问。

**如果选择“调整顺序”：**询问用户期望的调整。应用调整后，检查新顺序是否违反

blocked_by

边（如果违反则发出警告但不阻止），重新呈现更新后的计划并再次询问。

**如果选择“拒绝——终止”：**立即退出。未执行任何实现工作。

只有在明确收到“批准”答复后，才能进入步骤4。

4. Execute each task

4. 执行每个任务

Parallelism within phases: Tasks within the same phase (from the plan in step 3) have no internal dependencies between them. For each phase, spawn one sub-agent per task in parallel using the Agent tool with

isolation: "worktree"

, passing the task number and full spec context to each sub-agent. Wait for all sub-agents in the phase to complete before starting the next phase.

For each Task (within its phase):

a. Dependency gate (lightweight re-check)

Before starting each task, do a quick re-check against its internal blockers from the graph built in step 1. The full dependency validation already ran in step 2d — this check only guards against the case where an earlier task in this run was skipped or its PR wasn't merged before the dependent task starts.

For each internal blocker of the current task:

bash

gh issue view <blocker_number> --json state,stateReason \
  --jq '"#\(.number) \(.state) (\(.stateReason))"'

If a blocker is not

CLOSED

COMPLETED

, pause:

```
question
```
: "Task #<blocker> (an internal blocker) hasn't been merged yet. How do you want to proceed?"
```
header
```
: "Blocked"

options

{label: "Wait — I'll merge it now", description: "Pause here. Re-run the loop from this task after merging."}

{label: "Skip this task", description: "Skip Task #<current_task> and continue with tasks that aren't blocked"}

If all internal blockers are resolved, continue silently.

b. Implement

Follow the

wtf:implement-task

process for the Task, passing the Task number in as context. The skill will:

Set up the correct feature branch (creating it if absent)
Run the TDD cycle
Mark
```
implemented
```

c. Verify

Follow the

wtf:verify-task

process (single-task mode), passing the Task number in as context.

Before verifying, classify each Gherkin scenario in the Task:

Test-suite covered — a test file exists that exercises this scenario (e.g. a
```
describe
```
/
```
it
```
block, a Cucumber step, a
```
test_*
```
function). Verification is the test run result. If the suite passes, the scenario is verified — continue automatically.
Not covered — no automated test maps to this scenario. Requires a human-in-the-loop check (manual steps, UI walkthrough, or explicit sign-off).

If all scenarios are test-suite covered and the suite passes → proceed to step 4d automatically.

If any scenario is not covered by the test suite → pause and present only those uncovered scenarios for human verification. Do not re-verify covered scenarios.

If a covered scenario's tests fail:

Call

AskUserQuestion

with:

```
question
```
: "Task #<n> — [n] test(s) failed. How do you want to proceed?"
```
header
```
: "Tests failed"

options

{label: "Fix and re-verify", description: "Pause the loop — fix the implementation, then re-run from this task"}

{label: "Skip and continue", description: "Skip this task for now and proceed to the next"}

{label: "Stop loop", description: "Exit the loop entirely"}

d. Open PR and wait for pipeline

Follow the

wtf:create-pr

process, passing the Task number and branch in as context. The PR targets the parent feature branch. Closing happens via

Closes #<task_number>

in the PR body — do not call

gh issue close

directly. Run non-interactively — no confirmation, title review, or body approval.

After the PR is opened, poll its pipeline until all status checks complete:

bash

gh pr checks <pr_number> --watch

This blocks until every check finishes. Once complete, inspect the result:

bash

gh pr checks <pr_number> --json name,state,conclusion \
  --jq '.[] | "\(.state) \(.conclusion) \(.name)"'

If all checks pass (

conclusion: SUCCESS

conclusion: SKIPPED

for every check) → merge automatically:

bash

gh pr merge <pr_number> --merge --delete-branch

Then continue to the next task.

If any check fails (

conclusion: FAILURE

conclusion: ACTION_REQUIRED

Call

AskUserQuestion

with:

```
question
```
: "Task #<n> PR pipeline failed — [list failing check names]. How do you want to proceed?"
```
header
```
: "Pipeline failed"

options

{label: "Fix and re-run", description: "Pause the loop — push a fix, then re-run the pipeline"}

{label: "Skip this task", description: "Leave the PR open and continue with remaining tasks"}

{label: "Stop loop", description: "Exit the loop entirely"}

If the pipeline times out or returns no checks (repo has no CI configured) → merge automatically, as there is nothing to wait on.

e. Progress update

After each Task's PR is merged, print:

✅ Task #<n> — <title> — merged: <url>
   [n remaining]

**阶段内并行执行：**步骤3计划中同一阶段的任务之间无内部依赖关系。针对每个阶段，使用Agent工具为每个任务并行生成一个子Agent，设置

isolation: "worktree"

，并将任务编号和完整规格上下文传递给每个子Agent。等待当前阶段的所有子Agent完成后，再开始下一阶段。

针对每个Task（在其所属阶段内）：

a. 依赖关卡（轻量重新检查）

开始每个任务前，快速重新检查步骤1构建的图中其内部阻塞项。完整的依赖验证已在步骤2d中完成——此检查仅用于防范本次运行中前序任务被跳过或其PR在依赖任务开始前未合并的情况。

针对当前任务的每个内部阻塞项：

bash

gh issue view <blocker_number> --json state,stateReason \
  --jq '"#\(.number) \(.state) (\(.stateReason))"'

如果阻塞项未处于

CLOSED

COMPLETED

状态，则暂停：

```
question
```
: "Task #<blocker>（内部阻塞项）尚未合并。你希望如何处理？"
```
header
```
: "被阻塞"

options

{label: "等待——我现在合并", description: "暂停在此处。合并后从该任务重新运行循环。"}

{label: "跳过此任务", description: "跳过Task #<current_task>，继续执行未被阻塞的任务"}

如果所有内部阻塞项已解决，则静默继续。

b. 实现

遵循

wtf:implement-task

流程执行Task，传递Task编号作为上下文。该Skill将：

设置正确的Feature分支（如果不存在则创建）
运行TDD循环
标记为
```
implemented
```

c. 验证

遵循

wtf:verify-task

流程（单任务模式），传递Task编号作为上下文。

验证前，对Task中的每个Gherkin场景进行分类：

测试套件覆盖 —— 存在测试文件覆盖此场景（例如
```
describe
```
/
```
it
```
块、Cucumber步骤、
```
test_*
```
函数）。验证结果即为测试运行结果。如果测试套件通过，则该场景验证通过——自动继续。
未覆盖 —— 无自动化测试对应此场景。需要人工介入检查（手动步骤、UI walkthrough或明确签字确认）。

如果所有场景均被测试套件覆盖且套件通过 → 自动进入步骤4d。

如果任何场景未被测试套件覆盖 → 暂停并仅呈现未覆盖的场景供人工验证。无需重新验证已覆盖的场景。

如果被覆盖的场景测试失败：

调用

AskUserQuestion

，参数如下：

```
question
```
: "Task #<n> — [n]个测试失败。你希望如何处理？"
```
header
```
: "测试失败"

options

{label: "修复并重新验证", description: "暂停循环——修复实现，然后从该任务重新运行"}

{label: "跳过并继续", description: "暂时跳过此任务，继续执行下一个任务"}

{label: "终止循环", description: "完全退出循环"}

d. 打开PR并等待流水线执行

遵循

wtf:create-pr

流程，传递Task编号和分支作为上下文。PR以父Feature分支为目标。通过PR正文中的

Closes #<task_number>

关闭议题——不得直接调用

gh issue close

。以非交互模式运行——无需确认、标题审核或正文批准。

PR打开后，轮询其流水线直到所有状态检查完成：

bash

gh pr checks <pr_number> --watch

此操作会阻塞直到所有检查完成。完成后，检查结果：

bash

gh pr checks <pr_number> --json name,state,conclusion \
  --jq '.[] | "\(.state) \(.conclusion) \(.name)"'

如果所有检查通过（每个检查的

conclusion: SUCCESS

或

conclusion: SKIPPED

）→ 自动合并：

bash

gh pr merge <pr_number> --merge --delete-branch

然后继续执行下一个任务。

如果任何检查失败（

conclusion: FAILURE

或

conclusion: ACTION_REQUIRED

）：

调用

AskUserQuestion

，参数如下：

```
question
```
: "Task #<n>的PR流水线失败——[列出失败的检查名称]。你希望如何处理？"
```
header
```
: "流水线失败"

options

{label: "修复并重新运行", description: "暂停循环——推送修复，然后重新运行流水线"}

{label: "跳过此任务", description: "保持PR打开，继续执行剩余任务"}

{label: "终止循环", description: "完全退出循环"}

如果流水线超时或未返回任何检查结果（仓库未配置CI）→ 自动合并，因为无需等待任何内容。

e. 进度更新

每个Task的PR合并后，打印：

✅ Task #<n> — <标题> — 已合并: <url>
   剩余任务数: [n]

5. Feature PR (after all tasks)

5. Feature PR（所有任务完成后）

Once all Tasks' PRs are merged into the feature branch, open a PR from the feature branch to

main

. Use both signals together — a task is complete only when its PR is merged AND the issue is closed:

bash

undefined

所有Task的PR合并到Feature分支后，打开从Feature分支到

main

的PR。需结合两个信号判断——只有当Task的PR已合并且议题已关闭时，才视为任务完成：

bash

undefined

Check for merged task PRs

检查已合并的Task PR

gh pr list --state merged --base feature/<feature-number>-<feature-slug>

Check for open sub-issues (primary signal — reliable even if feature branch was just created)

检查开放的子议题（主要信号——即使Feature分支刚创建也可靠）

gh sub-issue list <feature_number>

Should be empty (all task issues closed via merged PRs)

应为空（所有Task议题已通过合并PR关闭）


If both checks show all work is complete (no open sub-issues, all task PRs merged), open the feature PR automatically — no confirmation needed.

If either check shows pending work, list the outstanding tasks and call `AskUserQuestion` with:

- `question`: "Not all task PRs are merged yet. Open the feature PR anyway?"
- `header`: "Feature PR"
- `options`:
  - `{label: "Wait — I'll merge them first", description: "Pause here"}`
  - `{label: "Open it now", description: "Open feature → main PR with unmerged tasks noted in description"}`

Open the feature PR using `wtf:create-pr` targeting `main`, running non-interactively. The body must include `Closes #<feature_number>` and one `Closes #<task_number>` per task on separate lines.

After opening, poll and merge using the same pipeline pattern as step 4d — wait for all checks, auto-merge on green, gate on red.


如果两项检查均显示所有工作已完成（无开放子议题、所有Task PR已合并），则自动打开Feature PR——无需确认。

如果任何一项检查显示存在未完成工作，列出未完成的任务并调用`AskUserQuestion`，参数如下：

- `question`: "并非所有Task PR都已合并。是否仍要打开Feature PR？"
- `header`: "Feature PR"
- `options`:
  - `{label: "等待——我先合并", description: "暂停在此处"}`
  - `{label: "立即打开", description: "打开Feature → main的PR，并在描述中注明未合并的任务"}`

使用`wtf:create-pr`以非交互模式打开以`main`为目标的Feature PR。正文必须包含`Closes #<feature_number>`，并为每个Task单独添加一行`Closes #<task_number>`。

打开后，按照步骤4d的流水线模式轮询并合并——等待所有检查通过，绿灯时自动合并，红灯时触发关卡。

6. Summary

6. 总结

Print a final summary:

Loop complete — Feature #<n>: <title>
─────────────────────────────────────
Tasks completed:  [n]
Tasks skipped:    [n]
PRs merged:       [list of URLs]
Feature PR:       <url> (merged / open — pipeline pending)

If any Tasks were skipped, list them with reasons and suggest follow-up actions.

打印最终总结：

循环完成 —— Feature #<n>: <标题>
─────────────────────────────────────
已完成任务数:  [n]
已跳过任务数:    [n]
已合并PR:       [URL列表]
Feature PR:       <url> (已合并 / 打开中 —— 流水线待执行)

如果有任务被跳过，列出它们及原因，并建议后续操作。

Human-in-the-loop gate reference

人工介入关卡参考

The loop pauses and asks for human input only when:

Trigger	Why human input is needed
Spec contradiction (Task vs Feature)	Model cannot resolve intent ambiguity
Spec contradiction (Feature vs Epic)	Scope boundary unclear
Codebase mismatch (contract/module missing)	Implementation target may have changed
Missing Gherkin or Contracts	Cannot implement without a test target
Circular dependency (internal)	Hard stop — cannot resolve automatically
External blocker not yet merged/closed	Loop cannot start until upstream work is done
Internal blocker skipped or unmerged mid-run	Ordering constraint within the current run
Gherkin scenario not covered by test suite	No automated signal — human must verify manually
Covered test(s) fail	Implementation may need rework
PR pipeline check(s) fail	CI signal is authoritative — human must decide whether to fix or skip
Pending task PRs before feature PR	Some tasks not yet merged — human decides whether to wait or open early

循环仅在以下情况时暂停并请求人工输入：

触发条件	需要人工输入的原因
规格矛盾（Task与Feature）	模型无法解决意图歧义
规格矛盾（Feature与Epic）	范围边界不明确
代码库不匹配（contract/模块缺失）	实现目标可能已变更
缺失Gherkin或Contracts	无测试目标则无法实现
内部循环依赖	强制终止——无法自动解决
外部阻塞尚未合并/关闭	上游工作完成前循环无法开始
运行中内部阻塞被跳过或未合并	本次运行内的顺序约束被打破
Gherkin场景未被测试套件覆盖	无自动化信号——必须人工验证
被覆盖的测试失败	实现可能需要返工
PR流水线检查失败	CI信号具有权威性——人工必须决定修复或跳过
Feature PR前存在未合并的Task PR	部分任务未完成——人工决定等待或提前打开PR