wtf.write-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Write Task

编写任务

Create a GitHub Task issue — the implementable unit of work. Core value: derives Gherkin scenarios directly from the parent Feature's Acceptance Criteria, so nothing gets lost in translation.

创建GitHub Task工单——即可实现的工作单元。核心价值：直接从父Feature的验收标准（ACs）生成Gherkin场景，确保信息在传递过程中无遗漏。

Process

流程

0. GitHub CLI setup

0. GitHub CLI 设置

Run the setup check from

../references/gh-setup.md

. Stop if

gh

is not installed or not authenticated. Note whether the extensions are available — this determines whether native sub-issue and dependency links are created in step 10.

Skip this step if invoked from

feature-to-tasks

write-feature

(the orchestrator already ran it), or on re-invocations within the same session (e.g. "Write next Task" loop in step 11).

运行

../references/gh-setup.md

中的设置检查。如果未安装或未认证

gh

，则停止操作。记录扩展是否可用——这将决定步骤10中是否创建原生子工单和依赖链接。

如果是从

feature-to-tasks

或

write-feature

调用（编排器已运行过此步骤），或在同一会话中重复调用（例如步骤11中的“编写下一个任务”循环），则跳过此步骤。

1. Identify the parent Feature

1. 确定父Feature

Search for recent open issues with label

feature

to populate options. Call

AskUserQuestion

with

question: "Which Feature does this Task belong to?"

header: "Feature"

, and

options

pre-filled with 1–2 likely open Feature issue references inferred from GitHub search (e.g. recent open issues labeled

feature

Fetch the Feature, then find its parent Epic via the sub-issue hierarchy:

bash

gh issue view <feature_number>                                         # ACs, edge cases, user stories
gh sub-issue list <feature_number> --relation parent                   # find parent Epic number
gh issue view <epic_number>                                            # Goal, Context

If the Epic number was passed in as context (e.g. from an orchestrator), skip the

gh sub-issue list

call and use it directly.

搜索最近带有

feature

标签的开放工单以填充选项。调用

AskUserQuestion

，参数为

question: "此任务属于哪个Feature？"

、

header: "Feature"

，并预先填充1-2个从GitHub搜索推断出的可能的开放Feature工单引用（例如最近带有

feature

标签的开放工单）。

获取Feature后，通过子工单层级找到其父Epic：

bash

gh issue view <feature_number>                                         # 验收标准、边缘情况、用户故事
gh sub-issue list <feature_number> --relation parent                   # 查找父Epic编号
gh issue view <epic_number>                                            # 目标、上下文

如果Epic编号已作为上下文传入（例如来自编排器），则跳过

gh sub-issue list

调用，直接使用该编号。

2. Name the task

2. 命名任务

If a task description was passed in from the orchestrator (e.g. from

feature-to-tasks

step 3 or

write-feature

step 11), present it directly as the proposal without offering source options:

"Here's the task I'll write: [task description]. Does this look right, or would you like to adjust it?"

If invoked from
write-feature
or
feature-to-tasks
context but no description was pre-filled, call

AskUserQuestion

with:

```
question
```
: "How would you like to define this task?"
```
header
```
: "Task source"

options

[{label: "Propose from ACs", description: "Let me propose a task based on the Feature ACs (default)"}, {label: "Describe myself", description: "I'll describe the task myself"}]

Propose from ACs → based on the Feature's Acceptance Criteria, existing tasks, and the Proposed Tasks checklist from the Feature body, propose the next concrete unimplemented task. State it clearly and ask: "Does this task look right, or would you like to adjust it?"
Describe myself → ask: "What is this task implementing?" (one sentence)

If invoked standalone (no Feature context), ask directly: "What is this task implementing?" (one sentence — e.g. "Add date range filter to search API")

如果任务描述已从编排器传入（例如来自

feature-to-tasks

步骤3或

write-feature

步骤11），直接将其作为提案展示，不提供来源选项：

"这是我要编写的任务：[任务描述]。这个看起来是否合适，还是您想要调整？"

如果是从
write-feature
或
feature-to-tasks
上下文调用但未预先填充描述，调用

AskUserQuestion

，参数为：

```
question
```
: "您希望如何定义此任务？"
```
header
```
: "任务来源"

options

[{label: "根据验收标准提案", description: "让我基于Feature的验收标准提案一个任务（默认选项）"}, {label: "自行描述", description: "我将自行描述任务"}]

根据验收标准提案 → 基于Feature的验收标准、现有任务以及Feature正文中的“提案任务”清单，提案下一个具体的未实现任务。清晰说明并询问：“这个任务看起来是否合适，还是您想要调整？”
自行描述 → 询问：“此任务要实现什么？”（一句话描述）

如果是独立调用（无Feature上下文），直接询问：“此任务要实现什么？”（一句话描述——例如“为搜索API添加日期范围筛选器”）

3. Clarify ambiguity before proceeding

3. 进行前澄清歧义

Critically assess whether you have enough information to define a single, focused, implementable task. Cross-check the user's input against the Feature's Acceptance Criteria, Edge Cases, and the Epic's Goal.

Topics that may require clarification (in priority order):

Exact scope, entry/exit points
Data contracts and error handling
User roles and permissions
Performance requirements
Which Aggregate(s) does this Task modify or query?
What invariants must hold after the change?
What domain Events does this Task emit?
If this Task touches an integration boundary, which Bounded Contexts are involved?

Questioning style:

Ask questions one at a time. Wait for the answer before asking the next.
Always use the
AskUserQuestion
tool for every question — including open-ended ones like "What are the entry/exit points?" or "What invariants must hold?". For each question, infer 1–2 likely answers from codebase research (e.g. Aggregate names found in the code, event names from existing domain events) and pass them as
```
options
```
. The UI automatically appends an "Other (type your answer)" escape hatch — do NOT add one manually.
Stop when you have enough to write a complete draft. Do not invent answers or assume away ambiguity.

严格评估是否拥有足够信息来定义一个单一、聚焦、可实现的任务。将用户输入与Feature的验收标准、边缘情况以及Epic的目标进行交叉核对。

可能需要澄清的主题（按优先级排序）：

精确范围、入口/出口点
数据契约和错误处理
用户角色和权限
性能要求
此任务将修改或查询哪些Aggregate？
变更后必须保持哪些不变量？
此任务将触发哪些领域事件（domain Events）？
如果此任务涉及集成边界，涉及哪些Bounded Context？

提问风格：

一次只问一个问题。等待回答后再问下一个。
所有问题都必须使用
AskUserQuestion
工具——包括开放式问题，如“入口/出口点是什么？”或“必须保持哪些不变量？”。对于每个问题，从代码库研究中推断1-2个可能的答案（例如在代码中找到的Aggregate名称、现有领域事件的事件名称）并将其作为
```
options
```
传入。UI会自动添加“其他（输入您的答案）”选项——请勿手动添加。
当拥有足够信息来编写完整草稿时停止。不要编造答案或消除歧义假设。

4. Explore the codebase and wiki

4. 探索代码库和Wiki

Use the Agent tool to search the codebase for:

Files and modules this task will touch (Impacted Areas)
Existing patterns that inform Technical Approach
Current interfaces at the integration point
Existing tests covering adjacent behavior
Dependencies (other tasks or systems that must exist first)
The Aggregate classes or modules relevant to this task — note their invariant-enforcement logic
Any existing domain Event definitions to reuse rather than invent

Also fetch any relevant wiki pages or in-repo glossary docs for this task's Bounded Context — check

docs/glossary.md

, GitHub wiki pages matching the context name, or any ADR files. Use these to verify Ubiquitous Language terms before writing Gherkin scenarios. If no wiki or glossary exists, proceed without comment.

Cross-feature dependency scan: Fetch the sibling Features from the Epic's Feature Breakdown checklist (already fetched above), then fetch the Proposed Tasks checklist from each sibling Feature's issue body:

bash

undefined

使用Agent工具搜索代码库以查找：

此任务将涉及的文件和模块（影响区域）
为技术方案提供参考的现有模式
集成点的当前接口
覆盖相邻行为的现有测试
依赖项（必须先存在的其他任务或系统）
与此任务相关的Aggregate类或模块——记录其不变量强制执行逻辑
任何可重用而非重新创建的现有领域事件定义

同时获取与此任务的Bounded Context相关的Wiki页面或仓库内术语表文档——检查

docs/glossary.md

、与上下文名称匹配的GitHub Wiki页面或任何ADR文件。在编写Gherkin场景之前，使用这些文档验证通用语言术语。如果没有Wiki或术语表，则直接继续。

跨功能依赖扫描： 从Epic的“Feature分解”清单中提取同级Feature（已在上面获取），然后从每个同级Feature的工单正文中提取“提案任务”清单：

bash

undefined

For each sibling Feature number extracted from the Epic's Feature Breakdown:

对于从Epic的Feature分解中提取的每个同级Feature编号：

gh issue view <sibling_feature_number> --json number,title,body


Extract the task names and issue numbers (where linked) from each Feature's Proposed Tasks section. Then fetch the full body of any already-created sibling tasks to understand their scope:

```bash
gh issue list --label task --state open --json number,title,body

Filter this list client-side to tasks whose body references a sibling Feature number. Note any whose scope overlaps with or must precede this task. Keep these candidate dependencies in mind for step 5.

gh issue view <sibling_feature_number> --json number,title,body


从每个Feature的“提案任务”部分提取任务名称和工单编号（如果已链接）。然后获取任何已创建的同级任务的完整正文以了解其范围：

```bash
gh issue list --label task --state open --json number,title,body

在客户端过滤此列表，保留正文引用同级Feature编号的任务。记录任何范围与此任务重叠或必须在此任务之前完成的任务。在步骤5中记住这些候选依赖项。

5. Vertical slice assessment

5. 垂直切片评估

A task must be a vertical slice: it touches all layers needed to deliver one observable, user-facing behavior end-to-end (e.g. DB schema → service logic → API → UI). It must be independently shippable without requiring another unmerged task to be complete first.

This assessment runs on the codebase findings from step 4 — before a draft is written. It catches structural problems early. A second, draft-level scope check runs at step 9 after the written artefact is complete.

Evaluate whether this task meets that bar:

Passes → proceed.
Too broad → propose splitting into smaller slices; present the breakdown and ask the user to confirm before continuing.
Has dependencies → identify them explicitly, including tasks from sibling Features in the same Epic (surfaced in step 4):
- Tasks this task depends on (must be merged first — check if the code path exists yet; these may belong to the same Feature or a different Feature in the Epic)
- Tasks that depend on this task (will be blocked until this merges)

For each cross-feature dependency found, state explicitly: "Task #X (in Feature #Y) must be completed first because [reason]." This makes the inter-feature ordering visible before committing to it.

Document all dependencies in the draft with GitHub issue references. For cross-feature deps, annotate the reason inline:

markdown

undefined

任务必须是一个垂直切片：它涵盖端到端交付一个可观察的用户面向行为所需的所有层（例如数据库架构→服务逻辑→API→UI）。它必须可独立交付，无需等待另一个未合并的任务完成。

此评估基于步骤4中的代码库发现——在编写草稿之前进行。它可以及早发现结构性问题。在步骤9中，编写完工件后将进行第二次草稿级范围检查。

评估此任务是否符合标准：

通过 → 继续。
范围过宽 → 建议拆分为更小的切片；展示分解方案并在继续前请求用户确认。
存在依赖项 → 明确识别它们，包括同一Epic中同级Feature的任务（步骤4中显示）：
- 此任务依赖的任务（必须先合并——检查代码路径是否已存在；这些任务可能属于同一Feature或Epic中的不同Feature）
- 依赖此任务的任务（将被阻塞直到此任务合并）

对于每个发现的跨功能依赖项，明确说明：“任务#X（在Feature#Y中）必须先完成，因为[原因]。”这使得在确定顺序之前可以看到跨功能的排序关系。

在草稿中使用GitHub工单引用记录所有依赖项。对于跨功能依赖项，在Inline中注释原因：

markdown

undefined

Dependencies

依赖项

Depends on #42 (Feature #12 — payment aggregate must exist before settlement status can be read)
Blocks #51 (Feature #15 — notification email requires this task's event to be emitted)

undefined

依赖#42（Feature#12——结算状态读取前必须存在支付聚合）
阻塞#51（Feature#15——通知邮件需要此任务触发的事件）

undefined

6. Ask about contracts

6. 询问契约相关信息

Call

AskUserQuestion

with

question: "Are there specific API contracts, events, or data schemas I should know about?"

header: "Contracts"

, and

options

pre-filled with 1–2 contract names or event names inferred from the codebase (e.g. existing API routes or domain events found in step 4). Include

{label: "None — proceed without", description: "Skip this section"}

as an option if nothing was found.

Use the answer to fill Contracts & Interfaces. Apply domain event naming rules from

../references/ddd-writing-rules.md

— past-tense domain names, named from the domain's perspective. If "none", stub events with the domain Event names derived in step 3 rather than leaving them blank.

调用

AskUserQuestion

，参数为

question: "是否有我需要了解的特定API契约、事件或数据模式？"

、

header: "契约"

，并预先填充1-2个从代码库推断出的契约名称或事件名称（例如步骤4中找到的现有API路由或领域事件）。如果未找到任何内容，添加

{label: "无——直接继续", description: "跳过此部分"}

作为选项。

使用答案填充“契约与接口”部分。应用

../references/ddd-writing-rules.md

中的领域事件命名规则——过去式领域名称，从领域角度命名。如果选择“无”，则使用步骤3中推导的领域事件名称来存根事件，而非留空。

7. Generate Gherkin from Feature ACs

7. 从Feature验收标准生成Gherkin

For each Acceptance Criterion in the parent Feature:

Write at least one Scenario (happy path)
Write a failure or edge case Scenario if the Feature listed one

Reference the contracts gathered in step 6 when writing scenarios — use the exact domain Event names, API operation names, and field names from those contracts in Given/When/Then steps so the scenarios align precisely with the implementation contracts.

Gherkin rules (vocabulary rules from

../references/ddd-writing-rules.md

Scenarios describe observable outcomes — not internal state
Given/When/Then must be concrete and specific, not abstract
Each scenario must survive internal refactors — it tests behavior, not implementation
Use only Ubiquitous Language in steps — never reference implementation details (no "database row", "REST call", "HTTP 200", "mock", "table", "JSON field")
Domain actors appear in Given steps ("Given a Fulfilment Manager has an open Purchase Order")
Domain Events appear in When steps where they trigger behavior ("When the
```
PaymentSettled
```
event is received")
Business outcomes appear in Then steps ("Then the Order is marked as Fulfilled") — not system states ("Then the orders table has status = 'fulfilled'")

对于父Feature中的每个验收标准：

编写至少一个场景（快乐路径）
如果Feature列出了边缘情况，则编写一个失败或边缘情况场景

编写场景时参考步骤6中收集的契约——在Given/When/Then步骤中使用契约中的确切领域事件名称、API操作名称和字段名称，使场景与实现契约精确对齐。

Gherkin规则（来自

../references/ddd-writing-rules.md

的词汇规则）：

场景描述可观察的结果——而非内部状态
Given/When/Then必须具体明确，而非抽象
每个场景必须在内部重构后仍然有效——它测试行为，而非实现
步骤中仅使用通用语言——永远不要引用实现细节（无“数据库行”“REST调用”“HTTP 200”“模拟”“表格”“JSON字段”）
领域参与者出现在Given步骤中（“Given一个履行经理有一个未完成的采购订单”）
领域事件出现在触发行为的When步骤中（“When接收到
```
PaymentSettled
```
事件”）
业务结果出现在Then步骤中（“Then订单被标记为已履行”）——而非系统状态（“Then订单表的状态='已履行'”）

8. Draft the Task

8. 起草任务

Use the issue body structure from @.github/ISSUE_TEMPLATE/TASK.md (ignore the YAML frontmatter — use only the markdown body below the second

---

delimiter). Fill in all sections with the gathered context. Replace the placeholder Gherkin scenarios with the ones generated in step 7.

Section-specific guidance:

Design Reference: Link the Figma frame if one exists; otherwise write "N/A — no design for this task."
Observability: Fill Logs, Metrics, and Alerts from the codebase patterns found in step 4. If the task has no production observability requirements, state "None required for this task" rather than leaving blank.
Rollout: Fill Feature flag, Backward compatibility, and Data migration only if applicable; otherwise write "N/A" for each.

使用 @.github/ISSUE_TEMPLATE/TASK.md 中的工单正文结构（忽略YAML前置内容——仅使用第二个

---

分隔符下方的markdown正文）。使用收集到的上下文填充所有部分。将占位符Gherkin场景替换为步骤7中生成的场景。

各部分指导：

设计参考：如果存在Figma框架，则链接；否则写入“N/A——此任务无设计。”
可观察性：从步骤4中找到的代码库模式填充日志、指标和警报。如果任务没有生产可观察性要求，则写入“此任务无需可观察性配置”而非留空。
发布：仅在适用时填充功能标志、向后兼容性和数据迁移；否则为每个部分写入“N/A”。

9. Scope gate

9. 范围检查

This is a final structural guardrail on the written draft — distinct from step 5's vertical-slice check on codebase findings. Both can fire independently: step 5 catches tasks that cannot ship alone; this step catches tasks that are simply too large. Frame this to the user as a structural check, not a challenge to their earlier answers.

Look for these Task-level split signals (heuristics — use judgement, not rigid thresholds):

There are more than 4 Gherkin scenarios covering distinct, independently shippable user journeys — not multiple failure modes for the same behavior (four ways a payment validation can fail is one behavior, not four tasks)
The Impacted Areas list spans more than 3–4 unrelated modules (e.g. API layer, database schema, frontend component, and a background job all bundled together)
The Technical Approach describes more than 5 distinct implementation steps that could each be merged separately without breaking anything
The task contains both a schema/data migration and user-facing behavior — migrations are typically safer as a separate prior task

Split strategy by signal:

Migration + behavior signal → always propose the migration as task A and the behavior as task B; task B depends on task A.
Broad modules signal → propose splits along deployment boundaries (e.g. backend task + frontend task, or data-layer task + service-layer task).
Too many Gherkin scenarios → split by user journey, keeping each task's scenarios tightly grouped around one observable outcome.

If no signals are present, proceed to the user review.

If one or more signals fire, present your case: state which signals you found, explain the risk (large tasks increase review friction, merge conflict surface, and rollback complexity), and propose a concrete split using the matching strategy above (two focused task descriptions in one sentence each). Then call

AskUserQuestion

with:

```
question
```
: "I think this Task may be too broad — see my reasoning above. How do you want to proceed?"
```
header
```
: "Scope check"

options

{label: "Keep the original draft", description: "Proceed with the current draft without splitting"}

{label: "Split it", description: "Start over with one of the proposed smaller Tasks"}

{label: "Stop here", description: "Exit without creating — I'll handle the split manually"}

Keep the original draft → proceed to the user review without further comment.
Split it → return to step 2 with the chosen focused task description as the seed, reusing the same parent Feature. Carry forward codebase findings from step 4.
Stop here → exit.

这是对书面草稿的最终结构防护——与步骤5中基于代码库发现的垂直切片检查不同。两者可独立触发：步骤5捕获无法单独交付的任务；此步骤捕获范围过大的任务。向用户说明这是结构检查，而非对其先前答案的质疑。

查找这些任务级拆分信号（启发式方法——使用判断，而非严格阈值）：

有超过4个Gherkin场景覆盖不同的、可独立交付的用户旅程——而非同一行为的多种失败模式（支付验证的四种失败方式是一种行为，而非四个任务）
影响区域列表涵盖超过3-4个不相关模块（例如API层、数据库架构、前端组件和后台作业捆绑在一起）
技术方案描述了超过5个可单独合并而不破坏任何内容的不同实现步骤
任务同时包含模式/数据迁移和用户面向行为——迁移通常作为单独的前置任务更安全

按信号拆分策略：

迁移+行为信号 → 始终建议将迁移作为任务A，行为作为任务B；任务B依赖任务A。
广泛模块信号 → 建议沿部署边界拆分（例如后端任务+前端任务，或数据层任务+服务层任务）。
Gherkin场景过多 → 按用户旅程拆分，使每个任务的场景紧密围绕一个可观察的结果。

如果无信号触发，继续进行用户审核。

如果一个或多个信号触发，说明理由：指出发现的信号，解释风险（大型任务会增加审核摩擦、合并冲突概率和回滚复杂度），并使用上述匹配策略提出具体的拆分方案（每个聚焦任务用一句话描述）。然后调用

AskUserQuestion

，参数为：

```
question
```
: "我认为此任务范围可能过宽——请参阅上述理由。您希望如何进行？"
```
header
```
: "范围检查"

options

{label: "保留原始草稿", description: "继续使用当前草稿，不拆分"}

{label: "拆分任务", description: "从其中一个提议的更小任务重新开始"}

{label: "在此停止", description: "退出，不创建任务——我将手动处理拆分"}

保留原始草稿 → 直接继续用户审核，无需进一步说明。
拆分任务 → 返回步骤2，使用选定的聚焦任务描述作为种子，重用同一Feature。沿用步骤4中的代码库发现结果。
在此停止 → 退出。

10. Review with user

10. 用户审核

Show the draft. Pay specific attention to Gherkin. Then call

AskUserQuestion

with

question: "Do the scenarios cover everything from the Feature ACs?"

header: "Review"

, and

options: [{label: "Yes — looks complete", description: "Proceed with issue creation"}, {label: "Missing edge cases", description: "I want to add more scenarios"}, {label: "Other changes", description: "I want to adjust something else"}]

Apply edits, then proceed.

展示草稿。特别关注Gherkin部分。然后调用

AskUserQuestion

，参数为

question: "场景是否覆盖了Feature验收标准的所有内容？"

、

header: "审核"

，以及

options: [{label: "是——看起来完整", description: "继续创建工单"}, {label: "缺少边缘情况", description: "我想添加更多场景"}, {label: "其他修改", description: "我想调整其他内容"}]

。

应用修改，然后继续。

11. Create the issue and link to Feature

11. 创建工单并关联到Feature

Note: Write each body to a temp file with the Write tool, then use
--body-file
to avoid shell quoting issues with multi-line content.

Title generation: Spawn a subagent using the

claude-haiku-4-5

model to generate a concise title from the task description. Pass in the task description and ask for a short title (no prefix emoji/label needed — that is added below). If the subagent returns nothing usable, derive the title directly from the one-sentence task description provided in step 2.

Create the Task issue:

bash

undefined

注意：使用Write工具将每个正文写入临时文件，然后使用
--body-file
避免多行内容的shell引用问题。

标题生成： 使用

claude-haiku-4-5

模型生成子代理，从任务描述生成简洁标题。传入任务描述并请求简短标题（无需前缀表情符号/标签——将在下方添加）。如果子代理未返回可用内容，则直接从步骤2中提供的一句话任务描述推导标题。

创建Task工单：

bash

undefined

Ensure the label exists before creating the issue

在创建工单前确保标签存在

gh label create task --color e4e669 --description "Implementable vertical slice of a Feature" 2>/dev/null || true

gh issue create --title "🛠 Task: <title>" --body-file /tmp/task-body.md --label "task"


Print the Task issue URL and number.

**Native relationships:** If `gh-sub-issue-available` (from step 0), link this Task as a child of its Feature:

```bash
gh sub-issue add <feature_number> <task_number>

gh-issue-dependency-available

, create a blocking link for each dependency identified in step 5:

bash

undefined

gh label create task --color e4e669 --description "Feature的可实现垂直切片" 2>/dev/null || true

gh issue create --title "🛠 Task: <title>" --body-file /tmp/task-body.md --label "task"


打印Task工单的URL和编号。

**原生关系：** 如果 `gh-sub-issue-available`（来自步骤0），将此Task链接为其Feature的子工单：

```bash
gh sub-issue add <feature_number> <task_number>

如果

gh-issue-dependency-available

，为步骤5中识别的每个依赖项创建阻塞链接：

bash

undefined

For each issue this Task depends on (same Feature or sibling Feature):

对于此Task依赖的每个工单（同一Feature或同级Feature）：

gh issue-dependency add <task_number> --blocked-by <blocker_number>


If either extension is unavailable, warn the user — do not write relationship references into the issue body.

gh issue-dependency add <task_number> --blocked-by <blocker_number>


如果任一扩展不可用，向用户发出警告——不要在工单正文中写入关系引用。

12. Offer to continue

12. 提供后续操作选项

Count remaining tasks by fetching the Feature's Proposed Tasks checklist (named items without issue numbers) and comparing against already-created child tasks via the sub-issue hierarchy:

bash

gh sub-issue list <feature_number>

Subtract created task count from total named items in the Proposed Tasks list to get remaining. Mention how many remain.

Call

AskUserQuestion

with:

```
question
```
: "What's next?"
```
header
```
: "Next step"

options

[{label: "Design this Task", description: "Add design coverage for this Task now (default)"}, {label: "Write next Task", description: "Write the next Task for this Feature (N remaining)"}, {label: "Write a Feature", description: "Write a new Feature for the same Epic"}, {label: "Stop here", description: "Exit — no further action"}]

(Replace N with actual count.)

Design this Task → follow the
```
design-task
```
process, opening with: "Continue with task #<task_number>".
Write next Task → restart from step 2, reusing the same Feature. If the Feature's Proposed Tasks list has named-but-uncreated items, propose the next one as the default.
Write a Feature → proceed with
```
write-feature
```
, passing the Epic number in as context.
Stop here → exit.

Suggest clearing context before continuing if the conversation has grown long.

通过获取Feature的“提案任务”清单（未关联工单编号的命名项）并与子工单层级中的已创建子任务进行比较，计算剩余任务数量：

bash

gh sub-issue list <feature_number>

从“提案任务”清单中的总命名项数减去已创建任务数，得到剩余数量。提及剩余数量。

调用

AskUserQuestion

，参数为：

```
question
```
: "下一步是什么？"
```
header
```
: "下一步"

options

[{label: "设计此任务", description: "立即为此任务添加设计覆盖（默认选项）"}, {label: "编写下一个任务", description: "为此Feature编写下一个任务（剩余N个）"}, {label: "编写Feature", description: "为同一Epic编写新Feature"}, {label: "在此停止", description: "退出——无进一步操作"}]

(将N替换为实际数量。)

设计此任务 → 遵循
```
design-task
```
流程，开头为：“继续处理任务#<task_number>”。
编写下一个任务 → 从步骤2重新开始，重用同一Feature。如果Feature的“提案任务”清单中有已命名但未创建的项，则将下一个项作为默认提案。
编写Feature → 继续
```
write-feature
```
，传入Epic编号作为上下文。
在此停止 → 退出。

如果对话已持续较长时间，建议在继续前清除上下文。