wtf.implement-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement Task

实现任务

Pick up an existing Task as a developer. Core value: reads the full spec (Task + Feature + Epic), maps it to the actual codebase, proposes a concrete technical approach, then drives implementation test-first against each Gherkin scenario.

The expected Task issue body structure is defined in @.github/ISSUE_TEMPLATE/TASK.md.

以开发者身份接手现有Task。核心价值：读取完整规范（Task + Feature + Epic），将其映射到实际代码库，提出具体技术方案，然后针对每个Gherkin场景以测试优先的方式驱动实现。

预期的Task问题主体结构定义在@.github/ISSUE_TEMPLATE/TASK.md中。

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. Extensions are not required for this skill.

Skip this step if invoked from

verify-task

or another skill that already ran gh-setup this session.

执行

../references/gh-setup.md

中的步骤1–2（安装检查和身份验证检查）。如果

gh

未安装或未通过身份验证，则停止。此技能不需要扩展。

如果是从

verify-task

或本次会话中已运行gh-setup的其他技能调用，则跳过此步骤。

1. Identify the Task

1. 识别Task

Ask: "Which Task are you implementing? (issue number)"

Fetch the Task first, extract Feature and Epic numbers from its Context section, then fetch Feature and Epic in parallel:

bash

gh issue view <task_number>    # Gherkin, Contracts, Impacted Areas — also yields feature and epic numbers

询问："你要实现哪个Task？（问题编号）"

首先获取Task，从其上下文部分提取Feature和Epic编号，然后并行获取Feature和Epic：

bash

gh issue view <task_number>    # Gherkin、契约、受影响区域 — 同时获取feature和epic编号

Extract feature and epic numbers, then in parallel:

提取feature和epic编号，然后并行执行：

gh issue view <feature_number> # ACs, user stories gh issue view <epic_number> # Goal, context, constraints

undefined

gh issue view <feature_number> # 验收标准、用户故事 gh issue view <epic_number> # 目标、上下文、约束条件

undefined

2. Lifecycle check

2. 生命周期检查

Check whether the task has been designed:

bash

gh issue view <task_number> --json labels --jq '.labels[].name'

If the

designed

label is absent, warn the user that the task hasn't been designed yet and that the recommended flow is: write-task → design-task → implement-task → verify-task. Then call

AskUserQuestion

with:

```
question
```
: "This task doesn't have a
```
designed
```
label yet. How would you like to proceed?"
```
header
```
: "Design check"

options

[{label: "Design it first", description: "Go back and run

design-task

 (default)"}, {label: "Skip design", description: "Proceed to implementation anyway"}]

Design it first → follow the
```
design-task
```
process, passing the Task number in as context.
Skip design → proceed.

If the

designed

label is present, continue silently.

检查任务是否已完成设计：

bash

gh issue view <task_number> --json labels --jq '.labels[].name'

如果

designed

标签不存在，则警告用户该任务尚未完成设计，推荐流程为：write-task → design-task → implement-task → verify-task。然后调用

AskUserQuestion

，参数如下：

```
question
```
: "此任务尚未添加
```
designed
```
标签。你希望如何继续？"
```
header
```
: "设计检查"

options

[{label: "先完成设计", description: "返回并执行

design-task

（默认选项）"}, {label: "跳过设计", description: "直接继续实现"}]

先完成设计 → 遵循
```
design-task
```
流程，将Task编号作为上下文传入。
跳过设计 → 继续执行。

如果

designed

标签存在，则静默继续。

3. Load the technical steering document

3. 加载技术指导文档

Use the Read tool to attempt reading

docs/steering/TECH.md

If the file exists: keep its content in context. Use its stack, architecture patterns, key constraints, commands, and ADRs to inform the technical approach and implementation in this session. Do not surface it to the user — just apply it silently.

If the file does not exist, call

AskUserQuestion

with:

```
question
```
: "docs/steering/TECH.md doesn't exist yet. This document captures your stack, architecture patterns, and technical constraints. Would you like to create it now?"
```
header
```
: "Tech steering doc missing"

options

[{label: "Create it now", description: "Run

steer-tech

 before continuing (recommended)"}, {label: "Skip for this session", description: "Continue without it — technical decisions won't reference project standards"}]

Create it now → follow the
```
steer-tech
```
process, then return to this skill and continue from step 4.
Skip for this session → continue without it.

使用Read工具尝试读取

docs/steering/TECH.md

。

如果文件存在：将其内容保留在上下文中。使用其中的技术栈、架构模式、关键约束、命令和ADRs来指导本次会话中的技术方案和实现。不要向用户展示内容，仅在后台应用。

如果文件不存在，则调用

AskUserQuestion

，参数如下：

```
question
```
: "docs/steering/TECH.md 不存在。此文档记录了你的技术栈、架构模式和技术约束。你现在是否要创建它？"
```
header
```
: "缺少技术指导文档"

options

[{label: "现在创建", description: "先执行

steer-tech

再继续（推荐）"}, {label: "本次会话跳过", description: "继续执行 — 技术决策不会参考项目标准"}]

现在创建 → 遵循
```
steer-tech
```
流程，然后返回此技能并从步骤4继续。
本次会话跳过 → 继续执行。

4. Set up the branch

4. 设置分支

Before writing any code, set up branches following the trunk-based feature branching strategy:

main
└── feature/<feature-number>-<feature-slug>   (merges → main)
    └── task/<task-number>-<task-slug>         (merges → feature branch)

Slug generation: For both the feature slug and task slug, spawn a subagent using the

claude-haiku-4-5

model. Pass in the title and ask for a 2–4 word kebab-case summary restricted to

[a-z0-9-]

characters (e.g.

date-range-filter

Feature branch — create if missing:

bash

git fetch origin
git checkout feature/<feature-number>-<feature-slug> 2>/dev/null || {
  git checkout main
  git pull --rebase origin main
  git checkout -b feature/<feature-number>-<feature-slug>
  git push -u origin feature/<feature-number>-<feature-slug>
}
git pull --rebase origin feature/<feature-number>-<feature-slug>

Task branch — create or resume:

bash

undefined

在编写任何代码之前，遵循基于主干的特性分支策略设置分支：

main
└── feature/<feature-number>-<feature-slug>   (合并至 → main)
    └── task/<task-number>-<task-slug>         (合并至 → feature分支)

Slug生成： 对于feature slug和task slug，使用

claude-haiku-4-5

模型生成子代理。传入标题，要求生成2–4个单词的kebab-case格式摘要，仅允许

[a-z0-9-]

字符（例如

date-range-filter

）。

Feature分支 — 不存在则创建：

bash

git fetch origin
git checkout feature/<feature-number>-<feature-slug> 2>/dev/null || {
  git checkout main
  git pull --rebase origin main
  git checkout -b feature/<feature-number>-<feature-slug>
  git push -u origin feature/<feature-number>-<feature-slug>
}
git pull --rebase origin feature/<feature-number>-<feature-slug>

Task分支 — 创建或恢复：

bash

undefined

Fresh work:

全新工作:

git checkout -b task/<task-number>-<task-slug>

Resumed work (branch already exists):

恢复已有工作（分支已存在）:

git checkout task/<task-number>-<task-slug> git rebase origin/feature/<feature-number>-<feature-slug>


Resolve any conflicts before proceeding. Print the branch name.

git checkout task/<task-number>-<task-slug> git rebase origin/feature/<feature-number>-<feature-slug>


继续之前解决所有冲突。打印分支名称。

5. Explore the codebase

5. 探索代码库

Before exploring, identify the test framework setup by reading a sample of existing test files. Record the following in a working scratchpad before proceeding — these govern every test written in step 8:

Field	Value
Test framework	(e.g. Jest, Vitest, pytest, RSpec)
Test file pattern	(e.g. `*/.test.ts` , `tests/test_*.py` )
Import convention	(e.g. `import { describe, it } from 'vitest'` )
Run command	(e.g. `npm test` , `pytest` )
Coverage command	(e.g. `npm run coverage` , `pytest --cov` )

Use the Agent tool with these concrete searches (run in parallel):

```
Grep
```
for the domain nouns and verbs from the Task's Functional Description across
```
*.{ts,tsx,js,jsx,py,go,rb}
```
files — finds files and modules this task will touch
```
Glob
```
matching the file patterns for each Impacted Area listed in the Task (e.g.
```
src/api/**/*
```
,
```
src/features/<feature-slug>/**/*
```
) — surfaces integration points and existing patterns
```
Grep
```
for interface or type names from the Task's Contracts section — finds current interface definitions to implement against
```
Glob
```
matching the test file pattern from the scratchpad (e.g.
```
**/*.test.ts
```
) near the integration points found above — surfaces existing tests covering adjacent behavior
```
Grep
```
for any import of the domain objects or services this task depends on — identifies dependencies that must exist first

Also fetch any relevant wiki pages or in-repo glossary docs for this task's Bounded Context. Use these to ensure the implementation and test naming aligns with the team's Ubiquitous Language.

探索之前，通过读取现有测试文件样本确定测试框架设置。继续之前在临时工作区记录以下内容 — 这些将指导步骤8中编写的所有测试：

字段	值
测试框架	(例如 Jest、Vitest、pytest、RSpec)
测试文件模式	(例如 `*/.test.ts` 、 `tests/test_*.py` )
导入约定	(例如 `import { describe, it } from 'vitest'` )
运行命令	(例如 `npm test` 、 `pytest` )
覆盖率命令	(例如 `npm run coverage` 、 `pytest --cov` )

使用Agent工具执行以下具体搜索（并行运行）：

在
```
*.{ts,tsx,js,jsx,py,go,rb}
```
文件中
```
Grep
```
任务功能描述中的领域名词和动词 — 找到此任务将涉及的文件和模块
对任务中列出的每个受影响区域执行
```
Glob
```
匹配文件模式（例如
```
src/api/**/*
```
、
```
src/features/<feature-slug>/**/*
```
） — 呈现集成点和现有模式
在任务的契约部分中
```
Grep
```
接口或类型名称 — 找到要实现的当前接口定义
对临时工作区中的测试文件模式执行
```
Glob
```
匹配（例如
```
**/*.test.ts
```
），范围为上述找到的集成点附近 — 呈现覆盖相邻行为的现有测试
```
Grep
```
此任务依赖的领域对象或服务的任何导入 — 识别必须先存在的依赖项

同时获取此任务的有界上下文（Bounded Context）的任何相关wiki页面或仓库内术语表文档。使用这些确保实现和测试命名符合团队的通用语言（Ubiquitous Language）。

6. Draft the Technical Approach

6. 起草技术方案

Produce a concrete Technical Approach with actual file paths (not generic layer names):

Architecture decisions: which layer owns what, which patterns to follow
Data flow: how data moves from input to output
Trade-offs: what alternatives were considered and why this approach was chosen
Impacted Areas: concrete file paths for Backend, Frontend, Database, APIs

生成包含真实文件路径（而非通用层名称）的具体技术方案：

架构决策：各层职责、遵循的模式
数据流：数据如何从输入传递到输出
权衡：考虑过哪些替代方案，以及选择此方案的原因
受影响区域：后端、前端、数据库、API的具体文件路径

7. Review approach with user

7. 与用户审核方案

Show the Technical Approach. Then call

AskUserQuestion

with

question: "Does this align with how you'd approach it?"

header: "Approach review"

, and

options: [{label: "Yes — looks good, proceed", description: "Continue with implementation"}, {label: "I have constraints to share", description: "I want to adjust the approach first"}, {label: "Suggest an alternative", description: "Let me describe a different approach"}]

Apply changes. Then update the Task issue with the Technical Approach and Impacted Areas.

See
references/issue-body-update-pattern.md
for the read-merge-write pattern. Use
/tmp/wtf-implement-task-approach.md
as the temp file.

bash

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-approach.md

展示技术方案。然后调用

AskUserQuestion

，参数为

question: "此方案是否符合你的预期实现方式？"

，

header: "方案审核"

，选项：

[{label: "是 — 没问题，继续", description: "继续实现"}, {label: "我有约束条件要说明", description: "我想先调整方案"}, {label: "建议替代方案", description: "让我描述一种不同的方案"}]

。

应用修改。然后更新Task问题，添加技术方案和受影响区域。

有关读取-合并-写入模式，请参阅
references/issue-body-update-pattern.md
。使用
/tmp/wtf-implement-task-approach.md
作为临时文件。

bash

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-approach.md

8. Drive the TDD cycle

8. 驱动TDD循环

For each Gherkin scenario in the Task, work through them in order. Match the project's established test patterns discovered in step 5. Reference the Contracts & Interfaces section for exact request/response shapes.

Write the failing test for the scenario.
Implement the minimum code to make it pass.
Refactor if needed — keep functions under 40 lines, no deep nesting.

Commit — create an atomic semantic commit:

bash

git add <changed files>
git commit -m "<type>(<scope>): <short description>

Scenario: <scenario name>
Task: #<task_number>"

Commit type:

feat

for new behavior,

fix

for bug fixes,

test

for test-only changes,

refactor

for refactors,

chore

for config/build changes.

Do not skip ahead — each scenario is a checkpoint.

Once all scenarios are green, run the full lint and type-check gate once across all changes. Check

package.json

for

lint

typecheck

type-check

, or

check

script keys and run whichever exist:

bash

undefined

针对Task中的每个Gherkin场景，按顺序处理。匹配步骤5中发现的项目既定测试模式。参考契约与接口部分获取精确的请求/响应格式。

为场景编写失败的测试。
实现最小化代码使测试通过。
如有需要进行重构 — 保持函数不超过40行，避免深层嵌套。
提交 — 创建原子化的语义化提交：
bash
```
git add <changed files>
git commit -m "<type>(<scope>): <简短描述>

Scenario: <场景名称>
Task: #<task_number>"
```
提交类型：
```
feat
```
表示新功能，
```
fix
```
表示修复bug，
```
test
```
表示仅测试变更，
```
refactor
```
表示重构，
```
chore
```
表示配置/构建变更。
不要提前跳过 — 每个场景都是一个检查点。

所有场景测试通过后，对所有变更运行完整的代码检查和类型检查。查看

package.json

中的

lint

、

typecheck

、

type-check

或

check

脚本键，并运行所有存在的脚本：

bash

undefined

e.g. npm run lint && npm run typecheck

例如 npm run lint && npm run typecheck


Fix any issues before proceeding to coverage.


继续执行覆盖率检查之前修复所有问题。

9. Verify coverage

9. 验证覆盖率

Once all scenarios pass, confirm unit test coverage meets the minimum threshold for all new and modified code. Use the threshold specified in

docs/steering/QA.md

if it exists; default to 80% if the document is absent or does not define a threshold:

bash

undefined

所有场景测试通过后，确认所有新增和修改代码的单元测试覆盖率达到最低阈值。如果

docs/steering/QA.md

存在，则使用其中指定的阈值；如果文档不存在或未定义阈值，则默认使用80%：

bash

undefined

Run the project's coverage command (check package.json scripts)

运行项目的覆盖率命令（查看package.json脚本）


If coverage is below 80% on any new or modified file, add targeted tests before proceeding. Every public function must have at least one happy-path and one error-path test.


如果任何新增或修改文件的覆盖率低于80%，则添加针对性测试后再继续。每个公共函数必须至少有一个正常路径测试和一个错误路径测试。

10. Update Test Mapping

10. 更新测试映射表

Fill the Test Mapping table in the Task issue with concrete file paths:

Gherkin Scenario	Test file	Status
`<scenario name>`	`<test file path:line>`	passing

See
references/issue-body-update-pattern.md
for the read-merge-write pattern. Re-fetch the body (do not reuse the temp file from step 6). Use
/tmp/wtf-implement-task-test-mapping.md
as the temp file.

bash

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-test-mapping.md

Print the updated Task issue URL.

填写Task问题中的测试映射表，包含具体文件路径：

Gherkin场景	测试文件路径	状态
`<场景名称>`	`<测试文件路径:行号>`	通过

有关读取-合并-写入模式，请参阅
references/issue-body-update-pattern.md
。重新获取问题主体（不要重用步骤6中的临时文件）。使用
/tmp/wtf-implement-task-test-mapping.md
作为临时文件。

bash

gh issue edit <task_number> --body-file /tmp/wtf-implement-task-test-mapping.md

打印更新后的Task问题URL。

11. Mark implemented and offer to continue

11. 标记为已实现并提供后续选项

Add the

implemented

lifecycle label:

bash

gh issue edit <task_number> --add-label "implemented"

Call

AskUserQuestion

with:

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

options

[{label: "Verify this Task", description: "Run QA against the Gherkin scenarios (recommended next step, default)"}, {label: "Open a pull request", description: "Create a PR for this branch"}, {label: "Implement another Task", description: "Implement another Task for the same Feature"}]

Verify this Task → follow the
```
verify-task
```
process, passing the Task number in as context so the user is not asked for it again.
Open a pull request → follow the
```
create-pr
```
process, passing the Task number and branch in as context.
Implement another Task → restart this skill from step 1.

添加

implemented

生命周期标签：

bash

gh issue edit <task_number> --add-label "implemented"

调用

AskUserQuestion

，参数如下：

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

options

[{label: "验证此Task", description: "针对Gherkin场景运行QA（推荐下一步，默认选项）"}, {label: "打开拉取请求", description: "为此分支创建PR"}, {label: "实现另一个Task", description: "为同一Feature实现另一个Task"}]

验证此Task → 遵循
```
verify-task
```
流程，将Task编号作为上下文传入，避免再次询问用户。
打开拉取请求 → 遵循
```
create-pr
```
流程，将Task编号和分支作为上下文传入。
实现另一个Task → 从步骤1重新启动此技能。",