starting-a-design-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Starting a Design Plan

设计计划启动指南

Overview

概述

Orchestrate the complete design workflow from initial idea to implementation-ready documentation through six structured phases: context gathering, clarification, definition of done, brainstorming, design documentation, and planning handoff.

Core principle: Progressive information gathering -> clear understanding -> creative exploration -> validated design -> documented plan.

Announce at start: "I'm using the starting-a-design-plan skill to guide us through the design process."

通过六个结构化阶段统筹从初始想法到可落地文档的完整设计工作流：上下文收集、需求澄清、完成定义、头脑风暴、设计文档编写以及落地计划交接。

核心原则： 渐进式信息收集 → 清晰理解需求 → 创意方案探索 → 验证后设计 → 文档化计划。

启动时告知： "我将使用starting-a-design-plan技能引导我们完成设计流程。"

Quick Reference

快速参考

Phase	Key Activities	Output
1. Context Gathering	Ask for freeform description, constraints, goals, URLs, files	Initial context bundle
2. Clarification	Invoke asking-clarifying-questions skill	Disambiguated requirements
3. Definition of Done	Synthesize and confirm deliverables before brainstorming	Confirmed success criteria
4. Brainstorming	Invoke brainstorming skill	Validated design (in conversation)
5. Design Documentation	Invoke writing-design-plans skill	Committed design document
6. Planning Handoff	Offer to invoke writing-plans skill	Implementation plan (optional)

阶段	核心活动	产出物
1. 上下文收集	收集自由描述信息、约束条件、目标、URL、文件	初始上下文包
2. 需求澄清	调用asking-clarifying-questions技能	明确化的需求
3. 完成定义	头脑风暴前综合并确认交付物	已确认的成功标准
4. 头脑风暴	调用brainstorming技能	验证后的设计（对话形式）
5. 设计文档编写	调用writing-design-plans技能	已提交的设计文档
6. 落地计划交接	提供调用writing-plans技能的选项	落地计划（可选）

The Process

流程说明

REQUIRED: Create task tracker at start

Use TaskCreate to create todos for each phase (or TodoWrite in older Claude Code versions):

Phase 1: Context Gathering (initial information collected)
(conditional) Read project design guidance (if
```
.ed3d/design-plan-guidance.md
```
exists)
Phase 2: Clarification (requirements disambiguated)
Phase 3: Definition of Done (deliverables confirmed)
Phase 4: Brainstorming (design validated)
Phase 5: Design Documentation (design written to docs/design-plans/)
Phase 6: Planning Handoff (implementation plan offered/created)

Use TaskUpdate to mark each phase as in_progress when working on it, completed when finished (or TodoWrite in older versions).

必填：启动时创建任务追踪器

使用TaskCreate为每个阶段创建待办事项（旧版Claude Code使用TodoWrite）：

阶段1：上下文收集（完成初始信息收集）
（可选）阅读项目设计指南（若存在
```
.ed3d/design-plan-guidance.md
```
文件）
阶段2：需求澄清（完成需求明确化）
阶段3：完成定义（确认交付物）
阶段4：头脑风暴（完成设计验证）
阶段5：设计文档编写（将设计写入docs/design-plans/目录）
阶段6：落地计划交接（提供/创建落地计划）

使用TaskUpdate标记每个阶段的状态：进行中（in_progress）、已完成（completed）（旧版使用TodoWrite）。

Phase 1: Context Gathering

阶段1：上下文收集

Never skip this phase. Even if the user provides detailed information, ask for anything missing.

Use TaskUpdate to mark Phase 1 as in_progress.

Ask the user to provide (freeform, not AskUserQuestion):

"I need some information to start the design process. Please provide what you have:

What are you designing?

High-level description of what you want to build
Goals or success criteria
Any known constraints or requirements

Context materials (very helpful if available):

URLs to relevant documentation, APIs, or examples
File paths to existing code or specifications in this repository
Any research you've already done

Project state:

Are you starting fresh or extending existing functionality?
Are there existing patterns in the codebase I should follow?
Any architectural decisions already made?

Share whatever details you have. We'll clarify anything unclear in the next step."

Progressive prompting: If user already provided some of this information, acknowledge what you have and ask only for what's missing.

Example: "You mentioned OAuth2 integration. I have the high-level goal. To help design this effectively, I need:

Any constraints (regulatory, existing auth system, etc.)
URLs to the OAuth2 provider's documentation (if you have them)
Whether this is for human users, service accounts, or both"

Mark Phase 1 as completed when you have initial context.

绝对不可跳过此阶段。即便用户已提供详细信息，也要询问缺失的内容。

使用TaskUpdate标记阶段1为进行中。

请用户提供以下内容（自由形式，无需使用AskUserQuestion）：

"我需要一些信息来启动设计流程，请提供你已有的相关内容：

你要设计什么？

待构建内容的高层级描述
目标或成功标准
已知的约束条件或需求

上下文材料（如有则非常有帮助）：

相关文档、API或示例的URL
本仓库中现有代码或规范的文件路径
你已完成的相关调研

项目状态：

是从零开始还是扩展现有功能？
代码库中是否有需要遵循的现有模式？
是否已做出任何架构决策？

请分享你掌握的所有细节，我们将在下一步澄清不明确的内容。"

渐进式提示： 若用户已提供部分信息，先确认已获取的内容，仅询问缺失的部分。

示例： "你提到了OAuth2集成，我已了解高层级目标。为了更有效地设计，我还需要：

约束条件（合规要求、现有认证系统限制等）
OAuth2提供商的文档URL（若有）
此集成是面向人类用户、服务账户还是两者兼顾"

获取初始上下文后，标记阶段1为已完成。

Between Phase 1 and Phase 2: Check for Project Guidance

阶段1与阶段2之间：检查项目指南

Before clarification, check for project-specific design guidance.

Check if
.ed3d/design-plan-guidance.md
exists:

Use the Read tool to check if

.ed3d/design-plan-guidance.md

exists in the session's working directory.

If the file exists:

Use TaskCreate to add: "Read project design guidance from [absolute path to .ed3d/design-plan-guidance.md]"
- Set this task as blocked by Phase 1 (Context Gathering)
- Update Phase 2 (Clarification) to be blocked by this new task
Mark the task in_progress
Read the file and incorporate the guidance into your understanding
Mark the task completed
Proceed to Phase 2

If the file does not exist:

Proceed directly to Phase 2. Do not create a task or mention the missing file.

What project guidance provides:

Domain-specific terminology to use in clarification
Architectural constraints or preferences
Technologies that are required, preferred, or forbidden
Stakeholders and their priorities
Project conventions that designs must follow

The guidance informs what questions you ask during clarification.

在需求澄清前，检查是否存在项目特定的设计指南。

检查
.ed3d/design-plan-guidance.md
是否存在：

使用Read工具检查会话工作目录中是否存在

.ed3d/design-plan-guidance.md

文件。

若文件存在：

使用TaskCreate添加任务："读取项目设计指南，路径为[.ed3d/design-plan-guidance.md的绝对路径]"
- 设置此任务依赖于阶段1（上下文收集）完成
- 更新阶段2（需求澄清）的依赖为该新任务
标记该任务为进行中
读取文件并将指南内容融入你的理解
标记该任务为已完成
进入阶段2

若文件不存在：

直接进入阶段2，无需创建任务或提及文件缺失。

项目指南包含的内容：

需求澄清时需使用的领域特定术语
架构约束或偏好
必需、首选或禁用的技术
利益相关者及其优先级
设计必须遵循的项目规范

指南将指导你在需求澄清阶段提出的问题。

Phase 2: Clarification

阶段2：需求澄清

Use TaskUpdate to mark Phase 2 as in_progress.

REQUIRED SUB-SKILL: Use ed3d-plan-and-execute:asking-clarifying-questions

Announce: "I'm using the asking-clarifying-questions skill to make sure I understand your requirements correctly."

The clarification skill will:

Use subagents to try to disambiguate before raising questions to the user
Disambiguate technical terms ("OAuth2" -> which flow?)
Identify scope boundaries ("users" -> humans? services? both?)
Clarify assumptions ("integrate with X" -> which version?)
Understand constraints ("must use Y" -> why?)

Output: Clear understanding of what user means, ready to confirm Definition of Done.

Mark Phase 2 as completed when requirements are disambiguated.

使用TaskUpdate标记阶段2为进行中。

必填子技能： 使用ed3d-plan-and-execute:asking-clarifying-questions

告知用户："我将使用asking-clarifying-questions技能确保我正确理解你的需求。"

该澄清技能将：

在向用户提出问题前，使用子代理尝试消除歧义
明确技术术语（如"OAuth2" → 具体哪种流程？）
界定范围边界（如"用户" → 人类？服务？还是两者？）
澄清假设（如"与X集成" → 哪个版本？）
理解约束条件（如"必须使用Y" → 原因是什么？）

产出物： 对用户需求的清晰理解，可进入完成定义确认环节。

需求明确化后，标记阶段2为已完成。

Phase 3: Definition of Done

阶段3：完成定义

Before brainstorming the how, lock in the what. Brainstorming explores texture and approach — it assumes the goal is already clear.

Use TaskUpdate to mark Phase 3 as in_progress.

Synthesize the Definition of Done from context gathered so far:

From Phases 1-2 (Context Gathering and Clarification), you should be able to infer or extract:

What the deliverables are (what gets built/changed)
What success looks like (how we know it's done)
What's explicitly out of scope

If the Definition of Done is clear:

State it back to the user and confirm using AskUserQuestion:

Question: "Before we explore approaches, let me confirm what success looks like:"
Options:
  - "Yes, that's right" (Definition of Done is accurate)
  - "Needs adjustment" (User will clarify what's missing or wrong)

Present the Definition of Done as a brief statement (2-4 sentences) covering:

Primary deliverable(s)
Success criteria
Key exclusions (if any were discussed)

If the Definition of Done is unclear:

Ask targeted questions to nail it down. Use AskUserQuestion when there are discrete options, or open-ended questions when you need the user to describe their vision.

Examples of clarifying questions:

"What's the primary deliverable here — is it [X] or [Y]?"
"How will you know this is done? What would you test or demonstrate?"
"You mentioned [feature]. Is that in scope for this design, or a future addition?"

Do not proceed to brainstorming until Definition of Done is confirmed.

在探讨如何实现前，先锁定要实现什么。头脑风暴是探索实现细节和方法——前提是目标已明确。

使用TaskUpdate标记阶段3为进行中。

综合目前收集到的上下文，生成完成定义：

从阶段1-2（上下文收集和需求澄清）中，你应能推断或提取：

交付物是什么（要构建/修改的内容）
成功的标准是什么（如何判断已完成）
明确排除在范围外的内容

若完成定义清晰：

向用户复述并使用AskUserQuestion确认：

问题："在我们探讨实现方法前，让我确认一下成功的标准："
选项：
  - "是的，没错"（完成定义准确）
  - "需要调整"（用户将澄清缺失或错误的内容）

将完成定义以简短陈述（2-4句话）呈现，涵盖：

主要交付物
成功标准
关键排除项（如有讨论）

若完成定义不清晰：

提出针对性问题以明确。当有明确选项时使用AskUserQuestion，若需要用户描述愿景则使用开放式问题。

澄清问题示例：

"主要交付物是什么——是[X]还是[Y]？"
"你如何判断已完成？会测试或演示什么内容？"
"你提到了[功能]，这属于本次设计的范围还是后续新增功能？"

在完成定义得到确认前，不得进入头脑风暴阶段。

Create Design Document Immediately After Confirmation

确认后立即创建设计文档

REQUIRED: Once the user confirms the Definition of Done, create the design document file immediately. This captures the DoD at full fidelity before brainstorming begins.

必填： 用户确认完成定义后，立即创建设计文档文件。这能在头脑风暴开始前完整记录完成定义的内容。

Step 1: Get Design Plan Name

步骤1：获取设计计划名称

The slug becomes part of all acceptance criteria identifiers (e.g.,

my-feature.AC1.1

) and appears in test names. Ask the user to choose it explicitly.

Generate 2-3 suggested slugs based on the conversation context. Good slugs are:

Lowercase with hyphens (no spaces, underscores, or special characters)
Terse but unambiguous — prefer short forms that don't create confusion (e.g.,
```
authn
```
not
```
authentication
```
, but not
```
auth
```
since that's ambiguous with
```
authz
```
)
Recognizable months later

Use AskUserQuestion:

Question: "What should we call this design plan? The name becomes the prefix for all acceptance criteria (e.g., `{slug}.AC1.1`) and appears in test names.

If you have a ticketing system, you can use the ticket name (e.g., PROJ-1234)."

Options:
  - "[auto-generated-slug-1]" (e.g., "oauth2-svc-authn")
  - "[auto-generated-slug-2]" (e.g., "svc-authn")
  - "[auto-generated-slug-3]" (if meaningfully different)

If user selects "Other": They can provide any name. Normalize it:

Ticket names (pattern:
```
UPPERCASE-DIGITS
```
, e.g.,
```
PROJ-1234
```
): keep as-is
Descriptive names: lowercase, hyphens for spaces, strip invalid characters (e.g., "My Cool Feature" →
```
my-cool-feature
```
)

该短名称（slug）将作为所有验收标准标识符的前缀（如

my-feature.AC1.1

）并出现在测试名称中。请用户明确选择。

根据对话上下文生成2-3个建议的短名称。优质的短名称需满足：

小写字母，用连字符分隔（无空格、下划线或特殊字符）
简洁但无歧义 —— 优先选择不会产生混淆的缩写（如
```
authn
```
而非
```
authentication
```
，但不要用
```
auth
```
，因为它与
```
authz
```
易混淆）
数月后仍能清晰识别

使用AskUserQuestion：

问题："我们该如何命名这个设计计划？该名称将作为所有验收标准的前缀（如`{slug}.AC1.1`）并出现在测试名称中。

若你使用工单系统，可直接用工单名称（如PROJ-1234）。"

选项：
  - "[自动生成的短名称1]"（如"oauth2-svc-authn"）
  - "[自动生成的短名称2]"（如"svc-authn"）
  - "[自动生成的短名称3]"（若有明显差异）

若用户选择"其他"： 用户可提供任意名称，需进行标准化处理：

工单名称（格式：
```
大写字母-数字
```
，如
```
PROJ-1234
```
）：保持原样
描述性名称：转为小写，用连字符替换空格，去除无效字符（如"My Cool Feature" →
```
my-cool-feature
```
）

Step 2: Create File

步骤2：创建文件

File location:

docs/design-plans/YYYY-MM-DD-{slug}.md

Use today's date and the user-chosen slug.

Initial file contents:

markdown

undefined

文件路径：

docs/design-plans/YYYY-MM-DD-{slug}.md

使用当前日期和用户选择的短名称。

初始文件内容：

markdown

undefined

[Feature Name] Design

[功能名称] 设计方案

Summary

摘要

Definition of Done

完成定义

[The confirmed Definition of Done - copy exactly as confirmed with user]

[与用户确认的完成定义——完全按照确认内容复制]

Acceptance Criteria

验收标准

Glossary

术语表


**Why write immediately:**
- Captures Definition of Done at peak resolution (right after user confirmation)
- Prevents fidelity loss during brainstorming conversation
- Creates working document that grows incrementally
- Acceptance Criteria, Summary, and Glossary filled in later by writing-design-plans skill

Mark Phase 3 as completed when user confirms the Definition of Done AND the file is created.


**立即创建的原因：**
- 在用户刚确认完成定义时，以最高保真度记录内容
- 避免头脑风暴对话过程中信息丢失
- 创建可逐步完善的工作文档
- 验收标准、摘要和术语表将后续由writing-design-plans技能填充

用户确认完成定义且文件创建后，标记阶段3为已完成。

Phase 4: Brainstorming

阶段4：头脑风暴

With clear understanding from Phases 1-3, explore design alternatives and validate the approach.

Use TaskUpdate to mark Phase 4 as in_progress.

REQUIRED SUB-SKILL: Use ed3d-plan-and-execute:brainstorming

Announce: "I'm using the brainstorming skill to explore design alternatives and validate the approach."

Pass context to brainstorming:

Information gathered in Phase 1
Clarifications from Phase 2
Confirmed Definition of Done from Phase 3
This reduces Phase 1 of brainstorming (Understanding) since much is already known

The brainstorming skill will:

Complete any remaining understanding gaps (Phase 1)
Propose 2-3 architectural approaches (Phase 2)
Present design incrementally for validation (Phase 3)
Use research agents for codebase patterns and external knowledge

Output: Validated design held in conversation context.

Mark Phase 4 as completed when design is validated.

基于阶段1-3的清晰理解，探索设计方案并验证方法。

使用TaskUpdate标记阶段4为进行中。

必填子技能： 使用ed3d-plan-and-execute:brainstorming

告知用户："我将使用brainstorming技能探索设计方案并验证实现方法。"

向头脑风暴技能传递上下文：

阶段1收集的信息
阶段2的澄清内容
阶段3确认的完成定义
这将缩短头脑风暴的阶段1（理解环节），因为大部分信息已明确

头脑风暴技能将：

填补剩余的理解空白（阶段1）
提出2-3种架构方案（阶段2）
逐步呈现设计方案以获取验证（阶段3）
使用研究代理获取代码库模式和外部知识

产出物： 对话上下文中已验证的设计方案。

设计验证完成后，标记阶段4为已完成。

Phase 5: Design Documentation

阶段5：设计文档编写

Append the validated design to the document created in Phase 3.

Use TaskUpdate to mark Phase 5 as in_progress.

REQUIRED SUB-SKILL: Use ed3d-plan-and-execute:writing-design-plans

Announce: "I'm using the writing-design-plans skill to complete the design document."

Important: The design document already exists from Phase 3 with:

Title
Summary placeholder
Confirmed Definition of Done
Acceptance Criteria placeholder
Glossary placeholder

The writing-design-plans skill will:

Append body sections (Architecture, Existing Patterns, Implementation Phases, Additional Considerations) to the existing file
Structure with implementation phases (<=8 recommended)
- DO NOT pad out phases in order to reach the number of 8. 8 is the maximum, not the target.
Document existing patterns followed
Generate Acceptance Criteria (success + failure cases for each DoD item), get human validation
Generate Summary and Glossary to replace placeholders
Commit to git

Output: Committed design document ready for implementation planning.

Mark Phase 5 as completed when design document is committed.

将已验证的设计方案追加到阶段3创建的文档中。

使用TaskUpdate标记阶段5为进行中。

必填子技能： 使用ed3d-plan-and-execute:writing-design-plans

告知用户："我将使用writing-design-plans技能完成设计文档。"

注意： 设计文档已在阶段3创建，包含：

标题
摘要占位符
已确认的完成定义
验收标准占位符
术语表占位符

writing-design-plans技能将：

向现有文件追加主体部分（架构、现有模式、实现阶段、其他考虑因素）
划分实现阶段（建议不超过8个）
- 不要为了凑够8个阶段而强行拆分，8是最大值而非目标值
记录遵循的现有模式
生成验收标准（每个完成定义项的成功和失败场景），并获取人工验证
生成摘要和术语表以替换占位符
提交到git

产出物： 已提交的设计文档，可进入落地计划环节。

设计文档提交后，标记阶段5为已完成。

Phase 6: Planning Handoff

阶段6：落地计划交接

After design is documented, guide user to create implementation plan in fresh context.

Use TaskUpdate to mark Phase 6 as in_progress.

Do NOT create implementation plan directly. The user needs to /clear context first.

Announce design completion and provide next steps:

Design complete! Design document committed to `docs/design-plans/[filename]`.

Ready to create the implementation plan? This requires fresh context to work effectively.

**IMPORTANT: Copy the command below BEFORE running /clear (it will erase this conversation).**

(1) Copy this command now:

/ed3d-ed3d-plan-and-execute:start-implementation-plan @docs/design-plans/[full-filename].md .

(the `.` at the end is necessary or else Claude Code will eat the command and do the wrong thing.)

(2) Clear your context:

/clear


(3) Paste and run the copied command.

The start-implementation-plan command will create detailed tasks, set up a branch, and prepare for execution.

Why /clear instead of continuing:

Implementation planning needs fresh context for codebase investigation
Long conversations accumulate context that degrades quality
/clear gives the next phase a clean slate

Mark Phase 6 as completed after providing instructions.

设计文档完成后，引导用户在新会话上下文中创建落地计划。

使用TaskUpdate标记阶段6为进行中。

请勿直接创建落地计划，用户需要先执行/clear清除上下文。

告知用户设计完成并提供后续步骤：

设计已完成！设计文档已提交到`docs/design-plans/[文件名]`。

准备创建落地计划了吗？这需要在新的会话上下文中进行才能保证效果。

**重要：运行/clear前请先复制以下命令（该命令会清除当前对话）。**

(1) 立即复制此命令：

/ed3d-ed3d-plan-and-execute:start-implementation-plan @docs/design-plans/[完整文件名].md .

（末尾的`.`是必需的，否则Claude Code会解析错误。）

(2) 清除上下文：

/clear


(3) 粘贴并运行复制的命令。

start-implementation-plan命令将创建详细任务、设置分支并为执行环节做准备。

为什么要/clear而非继续当前会话：

落地计划需要新的上下文来调研代码库
长对话会积累冗余上下文，降低输出质量
/clear为下一阶段提供干净的环境

提供指导后，标记阶段6为已完成。

When to Revisit Earlier Phases

何时回溯到之前的阶段

You can and should go backward when:

Phase 2 reveals fundamental gaps -> Return to Phase 1
Phase 3 reveals unclear deliverables -> Return to Phase 2 for more clarification
Phase 4 uncovers new constraints -> Return to Phase 1, 2, or 3
User questions approach during Phase 4 -> Return to Phase 2
Phase 4 changes the Definition of Done -> Return to Phase 3 to reconfirm
Design documentation reveals missing details -> Return to Phase 4

Don't force forward linearly when going backward gives better results.

在以下情况下可以且应该回溯：

阶段2发现根本性信息空白 → 回到阶段1
阶段3发现交付物不明确 → 回到阶段2进一步澄清
阶段4发现新的约束条件 → 回到阶段1、2或3
用户在阶段4对实现方法提出疑问 → 回到阶段2
阶段4改变了完成定义 → 回到阶段3重新确认
设计文档编写时发现缺失细节 → 回到阶段4

当回溯能得到更好结果时，不要强行线性推进。

Common Rationalizations - STOP

常见错误借口——停止此类行为

Excuse	Reality
"User provided details, can skip context gathering"	Always run Phase 1. Ask for what's missing.
"Requirements are clear, skip clarification"	Clarification prevents misunderstandings. Always run Phase 2.
"I know what done looks like, skip confirmation"	Confirm Definition of Done explicitly. Always run Phase 3.
"Simple idea, skip brainstorming"	Brainstorming explores alternatives. Always run Phase 4.
"Design is in conversation, don't need documentation"	Documentation is contract with writing-implementation-plans. Always run Phase 5.
"Can invoke implementation planning directly"	Must /clear first. Provide copy-then-clear workflow.
"I can combine phases for efficiency"	Each phase has distinct purpose. Run all six.
"User knows what they want, less structure needed"	Structure ensures nothing is missed. Follow all phases.

All of these mean: STOP. Run all six phases in order.

借口	实际情况
"用户已提供详细信息，可以跳过上下文收集"	始终执行阶段1，询问缺失的内容
"需求很清晰，可以跳过澄清环节"	澄清可避免误解，始终执行阶段2
"我知道完成标准是什么，可以跳过确认"	必须明确确认完成定义，始终执行阶段3
"想法很简单，可以跳过头脑风暴"	头脑风暴可探索替代方案，始终执行阶段4
"设计已在对话中明确，无需文档化"	文档是与writing-implementation-plans技能的契约，始终执行阶段5
"可以直接调用落地计划功能"	必须先执行/clear，提供复制-清除的工作流
"我可以合并阶段以提高效率"	每个阶段都有明确的目标，需完整执行所有六个阶段
"用户知道自己想要什么，不需要那么多流程"	流程可确保无遗漏，需遵循所有阶段

以上所有借口都意味着：停止错误做法，按顺序执行所有六个阶段。

Key Principles

核心原则

Principle	Application
Never skip brainstorming	Even with detailed specs, always run Phase 4 (may be shorter)
Progressive prompting	Ask for less if user already provided some context
Clarify before ideating	Phase 2 prevents building the wrong thing
Lock in the goal before exploring	Phase 3 confirms what "done" means before brainstorming the how
All brains in skills	This skill orchestrates; sub-skills contain domain expertise
Task tracking	YOU MUST create todos with TaskCreate and update with TaskUpdate for all phases (or TodoWrite in older versions)
Flexible progression	Go backward when needed to fill gaps

原则	应用方式
绝不跳过头脑风暴	即便有详细规格，也要执行阶段4（可缩短时长）
渐进式提示	若用户已提供部分上下文，减少询问的内容
先澄清再构思	阶段2可避免构建错误的产品
先锁定目标再探索方法	阶段3在头脑风暴前确认"完成"的定义
技能封装专业能力	本技能负责统筹，子技能包含领域专业知识
任务追踪	必须使用TaskCreate创建所有阶段的待办事项，并使用TaskUpdate更新状态（旧版使用TodoWrite）
灵活推进	必要时回溯以填补信息空白