plan-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: /plan-task

Trigger

触发方式

/plan-task "task description"

Without a description, ask before continuing.

/plan-task "task description"

若未提供任务描述，需先询问用户再继续。

Response guidelines

响应准则

Be comprehensive but concise. Prefer tables and lists over paragraphs. Omit obvious explanations. No flowcharts.

内容需全面且简洁。优先使用表格和列表，而非段落。省略显而易见的说明。不使用流程图。

Reading project context

读取项目上下文

Read if they exist:

```
.claude/project.md
```
— stack, environments, modules
```
.claude/conventions.md
```
— team standards
```
.claude/architecture.md
```
— technical decisions
```
.claude/known-issues.md
```
— known pitfalls

If they don't exist, inform and continue with generic context.

若存在以下文件，请读取：

```
.claude/project.md
```
— 技术栈、环境、模块
```
.claude/conventions.md
```
— 团队标准
```
.claude/architecture.md
```
— 技术决策
```
.claude/known-issues.md
```
— 已知陷阱

若这些文件不存在，告知用户后基于通用上下文继续。

Stage 0: Clarification

阶段0：澄清

Before producing the plan, check if the description is sufficient.

Ask up to 3 targeted questions if any of the following are true:

The task type cannot be determined (feature / bug / refactor / infra)
The affected module or service is not identifiable from the description or
```
.claude/architecture.md
```
The scope boundary is ambiguous (e.g., "improve performance" with no target component named)

Do not ask about implementation preferences — only ask for facts needed to scope the plan correctly.

After asking, wait for the user's reply before proceeding to Stage 1. If the description is clear enough, skip Stage 0 silently and proceed.

在生成规划前，检查任务描述是否足够清晰。

若出现以下任一情况，最多提出3个针对性问题：

无法确定任务类型（功能开发 / Bug修复 / 代码重构 / 基础设施搭建）
无法从描述或
```
.claude/architecture.md
```
中识别受影响的模块或服务
范围边界模糊（例如：“提升性能”但未指定目标组件）

不要询问实现偏好，仅询问正确规划范围所需的事实信息。

提问后，等待用户回复再进入阶段1。若描述足够清晰，可直接跳过阶段0进入下一阶段。

Stage execution

阶段执行

By default, all stages run sequentially in one response.

The user can say "do only Stage 1", "stop after Stage 3", "skip to Stage 5". Respect this literally.

If a mid-stage ambiguity requires input, emit the completed portion of the current stage, then write:

Paused at Stage N. [Question]. Reply to continue.

默认情况下，所有阶段在一个响应中按顺序执行。

用户可指定“仅执行阶段1”、“完成阶段3后停止”、“跳至阶段5”，需严格遵循此类要求。

若执行中途出现模糊点需要用户输入，先输出当前阶段已完成的部分，然后写入：

暂停于阶段N。[问题]。请回复以继续。

Stage 1: Task understanding

阶段1：任务理解

Rephrase in 2–3 lines. List assumed premises as a table if there's ambiguity.

Premise	Assumed value
Task type	feature / bug / refactor / infra
Target module	identified name or "unknown"

If after rephrasing you identify a fundamental ambiguity that would make the remaining stages unreliable, pause here and ask the user to confirm before continuing.

用2-3句话重述任务。若存在歧义，将假设前提以表格形式列出。

前提	假设值
任务类型	功能开发 / Bug修复 / 代码重构 / 基础设施搭建
目标模块	已识别名称或“未知”

若重述后发现会导致后续阶段不可靠的根本性歧义，需在此处暂停，请求用户确认后再继续。

Stage 2: Files and modules involved

阶段2：涉及的文件和模块

File / Folder	Action	Reason
`path/to/file`	Create / Modify / Delete	Short reason

文件/文件夹	操作	原因
`path/to/file`	创建 / 修改 / 删除	简短原因

Stage 3: Dependencies and prerequisites

阶段3：依赖项与前置条件

Item	Type	Required before
Migration X	DB	Step 2
Service Y running	Infra	Step 1
Feature flag Z	Config	Step 3

If no dependencies exist, write: No external dependencies identified.

项	类型	需在完成前准备
迁移X	数据库	步骤2
服务Y运行中	基础设施	步骤1
功能标志Z	配置	步骤3

若不存在依赖项，写入：未识别到外部依赖项。

Stage 4: Implementation checklist

阶段4：实施检查清单

[ ] Step 1 — clear description
[ ] Step 2 — clear description
...

Each item should be small enough to be done and tested independently.

[ ] 步骤1 — 清晰描述
[ ] 步骤2 — 清晰描述
...

每个条目应足够小，可独立完成并测试。

Stage 5: Edge cases and risks

阶段5：边缘情况与风险

Scenario	Impact	Mitigation
Short description	High / Medium / Low	Short mitigation

场景	影响程度	缓解措施
简短描述	高 / 中 / 低	简短缓解措施

Stage 6: Acceptance criteria

阶段6：验收准则

Criterion	How to verify
Feature works end-to-end	Manual test or automated test description
No regressions	Existing test suite passes

准则	验证方式
功能端到端正常运行	手动测试或自动化测试描述
无回归问题	现有测试套件全部通过

Final output: Ready-to-use prompt

最终输出：可直接使用的提示语

After completing all stages, output one single copy block with everything the implementer needs. There must be exactly one

START COPY

marker and one

END COPY

marker in the entire response — never inside the context, never duplicated.

Rules for building the prompt:

One block only — everything goes between the two markers. Do not split into multiple copy blocks.
Fill
<context>
with ALL stages — include task summary (Stage 1), file list (Stage 2), dependencies (Stage 3), full checklist (Stage 4), risks (Stage 5), acceptance criteria (Stage 6). Condense; remove headers like "Stage N:" — just the data.
Omit sections with no data — if Stage 3 has no dependencies, omit that section from
```
<context>
```
. Same for Stage 5 with no risks.
Keep the Rules section — always include it, customized with conventions from
```
.claude/conventions.md
```
if it exists.
No placeholder text — never write "Paste here" or "[...]". Every field must contain real data from the plan.
No flowcharts, no
<history>
, no
<request>
, no
<example>
blocks — remove all of these.

Output format — emit this exactly once at the end:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ START COPY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

You are [senior dev role inferred from the stack]. Your job is to implement the task described below.

Use this tone: precise, direct, no filler.

<context>
TASK SUMMARY:
[2–3 line summary from Stage 1]

CURRENT STATE (verified by code inspection):
[Key facts about the existing code that the implementer must know — nullable constraints, missing models, current type values, etc.]

FILES TO CREATE/MODIFY:
[Each file on its own line: path (Action) — reason]

DEPENDENCIES:
[Each dependency: item — type — must be done before X]
[Omit entire section if none]

IMPLEMENTATION CHECKLIST:
[Full checklist from Stage 4, grouped by area (BACKEND / FRONTEND / etc.)]

RISKS:
[Each risk: scenario — impact — mitigation]
[Omit entire section if none]

ACCEPTANCE CRITERIA:
[Each criterion: what — how to verify]
</context>

Rules:
- Touch only the files listed above unless a deviation is explicitly justified in a comment
- Each implementation step must be independently testable before moving to the next
- If unsure about scope, ask before implementing — do not assume
[- Additional rules from .claude/conventions.md if it exists]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END COPY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

After the

END COPY

marker, output these two lines and nothing else:

Suggested order: [one sentence — e.g. "B-1 → B-9 first (run migrations + tests after each), then F-1 → F-10"] Recommended: start a new chat and paste the block above as the first message — keeps implementation context clean and avoids token overhead from this planning session.

完成所有阶段后，输出一个单独的复制块，包含实现人员所需的全部内容。整个响应中必须恰好包含一个

START COPY

标记和一个

END COPY

标记——绝不能出现在上下文内部，也不能重复。

构建提示语的规则：

仅一个块 — 所有内容放在两个标记之间。不要拆分为多个复制块。
用所有阶段填充
<context>
— 包含任务摘要（阶段1）、文件列表（阶段2）、依赖项（阶段3）、完整检查清单（阶段4）、风险（阶段5）、验收准则（阶段6）。精简内容；移除“阶段N:”这类标题——仅保留数据。
省略无数据的章节 — 若阶段3无依赖项，从
```
<context>
```
中省略该章节。阶段5无风险时同理。
保留规则部分 — 始终包含此部分，若
```
.claude/conventions.md
```
存在，需结合其中的约定进行定制。
无占位文本 — 绝不要写“粘贴此处”或“[...]”。每个字段必须包含来自规划的真实数据。
无流程图、无
<history>
、无
<request>
、无
<example>
块 — 移除所有此类内容。

输出格式——需严格按此格式输出一次：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ START COPY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

You are [senior dev role inferred from the stack]. Your job is to implement the task described below.

Use this tone: precise, direct, no filler.

<context>
TASK SUMMARY:
[2–3 line summary from Stage 1]

CURRENT STATE (verified by code inspection):
[Key facts about the existing code that the implementer must know — nullable constraints, missing models, current type values, etc.]

FILES TO CREATE/MODIFY:
[Each file on its own line: path (Action) — reason]

DEPENDENCIES:
[Each dependency: item — type — must be done before X]
[Omit entire section if none]

IMPLEMENTATION CHECKLIST:
[Full checklist from Stage 4, grouped by area (BACKEND / FRONTEND / etc.)]

RISKS:
[Each risk: scenario — impact — mitigation]
[Omit entire section if none]

ACCEPTANCE CRITERIA:
[Each criterion: what — how to verify]
</context>

Rules:
- Touch only the files listed above unless a deviation is explicitly justified in a comment
- Each implementation step must be independently testable before moving to the next
- If unsure about scope, ask before implementing — do not assume
[- Additional rules from .claude/conventions.md if it exists]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ END COPY ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在

END COPY

标记之后，输出以下两行内容，且仅输出这两行：

Suggested order: [one sentence — e.g. "B-1 → B-9 first (run migrations + tests after each), then F-1 → F-10"] Recommended: start a new chat and paste the block above as the first message — keeps implementation context clean and avoids token overhead from this planning session.

Behavior with description

基于描述的行为

Use the description to:

Identify type (feature / bug / refactor / infra)
Adjust level of detail
Detect modules by name and cross-reference with
```
.claude/architecture.md
```

使用任务描述来：

识别任务类型（功能开发 / Bug修复 / 代码重构 / 基础设施搭建）
调整详细程度
通过名称识别模块，并与
```
.claude/architecture.md
```
交叉引用