do-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Do Task

Overview

概述

Implement a specific action item from

docs/ROADMAP.md

by its ID. Read the task's full context from the roadmap, research as needed, clarify ambiguities with the user, execute the implementation, and deliver a test plan.

根据ID执行

docs/ROADMAP.md

中的具体行动项。从路线图中读取任务的完整上下文，根据需要开展调研，与用户澄清歧义点，执行实现工作，并交付测试计划。

Workflow

工作流程

Step 1: Parse and Load Task

步骤1：解析并加载任务

Extract the task ID from the user's arguments (e.g.,

1.1

2.3

3.1

Read

docs/ROADMAP.md

from the current working directory. If the file does not exist, check for

ROADMAP.md

at the project root. If neither exists, inform the user and stop.

Locate the action item matching the given ID (the

### X.Y

heading). Extract:

Phase title — the
```
## Phase N: ...
```
heading the task belongs to
Task title — the
```
### X.Y ...
```
heading text
Description — the
```
**Description**:
```
content
Requirements — the
```
**Requirements**:
```
checklist items
Implementation Notes — the
```
**Implementation Notes**:
```
content

If the task ID is not found, list all available task IDs with their titles and ask the user to pick one.

If the task belongs to the Future phase (which uses Description/Features/Rationale instead of Description/Requirements/Implementation Notes), inform the user that Future-phase items are high-level directions, not scoped tasks. Offer to help break it down into concrete action items instead.

从用户参数中提取任务ID（例如

1.1

、

2.3

、

3.1

）。

读取当前工作目录下的

docs/ROADMAP.md

文件。如果该文件不存在，则检查项目根目录下的

ROADMAP.md

。若两者都不存在，则告知用户并终止操作。

找到与给定ID匹配的行动项（即

### X.Y

标题），提取以下内容：

阶段标题 —— 该任务所属的
```
## Phase N: ...
```
标题
任务标题 ——
```
### X.Y ...
```
标题文本
描述 ——
```
**Description**:
```
对应的内容
需求 ——
```
**Requirements**:
```
对应的清单项
实现说明 ——
```
**Implementation Notes**:
```
对应的内容

如果未找到任务ID，则列出所有可用的任务ID及其标题，并请用户选择其中一个。

如果该任务属于Future阶段（该阶段使用Description/Features/Rationale而非Description/Requirements/Implementation Notes），则告知用户未来阶段的条目是高层级方向，而非已明确范围的任务，同时可协助将其拆解为具体的行动项。

Step 2: Load Project Context

步骤2：加载项目上下文

Read the following files if they exist, to understand the full project context:

```
docs/SPEC.md
```
— architecture, tech stack, data models, key decisions
```
docs/STYLES.md
```
— design tokens, component styling (for frontend tasks)

Also review the existing codebase structure to understand what has already been built. Use

Glob

and

Read

to survey the project directory — check for existing files, components, utilities, and patterns that the task should build on or integrate with.

若以下文件存在，则读取这些文件以全面了解项目上下文：

```
docs/SPEC.md
```
—— 架构、技术栈、数据模型、关键决策
```
docs/STYLES.md
```
—— 设计标记、组件样式（针对前端任务）

同时查看现有代码库结构，了解已完成的开发内容。使用

Glob

和

Read

工具调研项目目录——检查现有文件、组件、工具类和模式，确保任务的实现能够基于或整合这些内容。

Step 3: Clarify Ambiguities

步骤3：澄清歧义点

Before writing any code, evaluate whether the task's requirements and implementation notes are clear enough to proceed confidently. Consider:

Are there technical implementation choices that could go multiple ways?
Are there UI/UX decisions not specified in the requirements or STYLES.md?
Are there concerns, trade-offs, or risks worth surfacing?
Do the requirements reference something that doesn't exist yet or is unclear?

If anything is unclear, use the

AskUserQuestion

tool to ask focused follow-up questions. Do not guess on ambiguous requirements — ask.

If everything is clear, proceed without asking unnecessary questions.

在编写任何代码之前，评估任务的需求和实现说明是否足够清晰，以便顺利推进。需考虑以下几点：

是否存在多种技术实现方案可选？
需求或STYLES.md中是否未明确UI/UX决策？
是否有需要提出的关注点、权衡因素或风险？
需求中是否引用了尚未存在或含义模糊的内容？

若存在任何模糊点，使用

AskUserQuestion

工具提出针对性的跟进问题。请勿对模糊的需求进行猜测——务必询问。

若所有内容都清晰明确，则无需额外提问，直接推进。

Step 4: Research (If Needed)

步骤4：调研（如需）

If the task involves unfamiliar APIs, libraries, patterns, or integrations mentioned in the implementation notes, conduct targeted research using

WebSearch

to understand:

API usage and current best practices
Library-specific patterns and gotchas
Integration approaches

Keep research focused on what is needed for this specific task.

如果任务涉及实现说明中提到的不熟悉的API、库、模式或集成，使用

WebSearch

开展针对性调研，以了解：

API使用方法和当前最佳实践
特定库的模式和注意事项
集成方法

调研需聚焦于完成当前任务所需的内容。

Step 5: Implement

步骤5：执行实现

Execute the task by working through each requirement in the checklist. Follow existing project patterns and conventions discovered in Step 2.

Implementation rules:

Address every
```
- [ ]
```
requirement item — do not skip any
Follow the guidance in Implementation Notes
Match existing code style, naming conventions, and patterns in the project
Apply styles from
```
docs/STYLES.md
```
when the task involves UI
Keep changes focused on this task — do not refactor unrelated code
Write clean, working code — not placeholder stubs

通过逐一处理清单中的每个需求来执行任务。遵循步骤2中发现的现有项目模式和规范。

实现规则：

处理每一个
```
- [ ]
```
需求项——请勿跳过任何一项
遵循实现说明中的指导
匹配项目中现有的代码风格、命名规范和模式
当任务涉及UI时，应用
```
docs/STYLES.md
```
中的样式
保持变更聚焦于当前任务——请勿重构无关代码
编写简洁、可运行的代码——不要使用占位符存根

Step 6: Test Plan

步骤6：测试计划

After completing the implementation, provide a concise, step-by-step test plan the user can follow to verify the task works end-to-end.

Format the test plan as:

undefined

完成实现后，提供一份简洁的分步测试计划，供用户验证任务是否端到端正常运行。

测试计划格式如下：

undefined

Test Plan for X.Y: <Task Title>

<Action to take> → Expected: <What the user should see or experience>
<Next action> → Expected: <Expected result>

...


Each step should be a concrete action (run a command, navigate to a URL, click something, check a value) with a one-liner describing the expected outcome.

The test plan should cover:
- Happy path verification of each requirement
- Edge cases mentioned in the requirements or implementation notes
- Any error states or fallbacks the task implements

<Action to take> → Expected: <What the user should see or experience>
<Next action> → Expected: <Expected result>

...


每个步骤应是具体的操作（运行命令、导航到URL、点击内容、检查值），并附带一行描述预期结果的说明。

测试计划应涵盖：
- 每个需求的正常路径验证
- 需求或实现说明中提到的边缘情况
- 任务实现的任何错误状态或降级处理