plan-feature

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feature Planning

特性规划

Create concrete, implementation-ready plans for features and complex changes.

DO NOT WRITE CODE during planning. Only explore, analyse, and document.

为功能特性和复杂变更创建具体的、可直接用于实施的计划。

规划阶段请勿编写代码，仅进行探索、分析和文档记录。

Planning threshold

规划阈值

Before deep planning, quickly confirm the scope:

Plan in detail when changes affect 3+ files or multiple systems
Plan in detail when requirements are unclear or architectural tradeoffs exist
Skip heavyweight planning for single-file changes with clear requirements
For small/obvious changes, give a short execution outline instead of a full spec

在深入规划前，先快速确认范围：

当变更影响3个及以上文件或多个系统时，需制定详细计划
当需求不明确或存在架构权衡时，需制定详细计划
对于需求明确的单文件变更，可跳过重量级规划
对于小型/明显的变更，只需给出简短的执行大纲，无需完整规范

Planning workflow

规划工作流

1. Discovery

1. 需求挖掘

Ask targeted questions to uncover intent. For each question:

Present 2-3 concrete options with tradeoffs
Give your recommended option with clear reasoning
One question at a time; wait for user response
Skip questions already answered by the user

Critical questions:

What problem are you solving? (user pain point, business goal)
What should happen? (expected behaviour, success criteria)
What should NOT happen? (constraints, edge cases to avoid)
Who is this for? (user type, environment, scale)
How will you verify it works? (testing approach, validation)

提出针对性问题以明确用户意图。每个问题需满足：

给出2-3个具体选项及各选项的权衡点
给出你的推荐选项及清晰的理由
一次只提一个问题，等待用户回复
跳过用户已回答过的问题

核心问题：

你要解决什么问题？（用户痛点、业务目标）
预期达成什么效果？（预期行为、成功标准）
需要避免什么情况？（约束条件、需规避的边缘场景）
这是为谁设计的？（用户类型、运行环境、规模）
你将如何验证功能正常？（测试方法、验证方式）

Speed-to-learning reference

快速学习参考

Use
```
ship-fast-loop.md
```
for a lightweight shipping loop and feedback cadence.

如需轻量级交付循环和反馈节奏，请参考
```
ship-fast-loop.md
```
。

2. Analysis

2. 分析阶段

Explore the codebase systematically:

Locate relevant files (document paths with line numbers)
Map existing patterns (architecture, naming, data flow)
Identify dependencies (what will be affected by changes)
Find similar implementations (to maintain consistency)
Note relevant standards (from
```
implement-frontend
```
,
```
define-architecture
```
, etc)

Document findings:

File:
```
path/to/file.ts:123
```
- what it does, how it's relevant
Pattern: existing approach for similar features
Constraint: technical limitation or requirement

系统地探索代码库：

定位相关文件（记录文件路径及行号）
梳理现有模式（架构、命名规范、数据流）
识别依赖关系（变更会影响哪些部分）
查找类似实现（以保持一致性）
记录相关标准（来自
```
implement-frontend
```
、
```
define-architecture
```
等）

记录分析结果：

文件：
```
path/to/file.ts:123
```
- 功能说明及相关性
模式：类似功能的现有实现方式
约束：技术限制或要求

3. Planning

3. 规划阶段

Create a concrete, ordered plan with:

For each change, specify:

File path and approximate line number
Exact function/component/class to modify
What to add/remove/change (be specific)
Why this change (how it fits the goal)
Dependencies (what must happen first)

Plan structure:

undefined

创建具体的、有序的计划，包含以下内容：

每项变更需明确：

文件路径及大致行号
需修改的具体函数/组件/类
新增/删除/修改的具体内容
变更原因（如何契合目标）
依赖关系（哪些步骤需先完成）

计划结构：

undefined

Goal

目标

[One sentence: what we're building and why]

[一句话说明：要构建的内容及目的]

Changes

变更内容

1. [Description]

1. [变更描述]

File:
```
path/to/file.ts:45
```
Action: Add
```
functionName()
```
that does X
Reasoning: Needed because Y
Dependencies: None

文件：
```
path/to/file.ts:45
```
操作：新增
```
functionName()
```
实现X功能
原因：因Y需求需要
依赖：无

2. [Description]

2. [变更描述]

File:
```
path/to/other.ts:89
```
Action: Modify
```
existingFunction()
```
to handle Z
Reasoning: Integrates with change #1
Dependencies: #1 must complete first

文件：
```
path/to/other.ts:89
```
操作：修改
```
existingFunction()
```
以支持Z场景
原因：与变更#1集成
依赖：需先完成#1

Validation

验证标准

测试用例全部通过
功能在场景A下正常工作
已处理边缘场景B
符合
```
implement-frontend
```
规范（若为前端变更）
无控制台日志或调试代码

undefined

4. Standards reference

4. 标准参考

Explicitly note which standards apply:

Frontend changes: reference
```
implement-frontend
```
,
```
audit-ui
```
UI changes: reference
```
design-ui
```
Motion: reference
```
ui-animation
```
Backend: reference
```
define-architecture
```
Typography: reference
```
audit-ui
```

Format: "This plan must follow

implement-frontend

for forms and type safety."

明确标注需遵循的相关标准：

前端变更：参考
```
implement-frontend
```
、
```
audit-ui
```
UI变更：参考
```
design-ui
```
动效：参考
```
ui-animation
```
后端变更：参考
```
define-architecture
```
排版：参考
```
audit-ui
```

格式示例："本计划需遵循

implement-frontend

中关于表单和类型安全的规范。"

Anti-patterns

反模式

Avoid vague plans:

Bad: "Update the authentication system"
Good: "Modify
```
auth/middleware.ts:34
```
to add
```
validateSession()
```
that checks token expiry"

Avoid missing context:

Bad: "Add error handling"
Good: "Wrap API call in
```
auth/api.ts:67
```
with try/catch, show toast on error per
```
audit-ui
```
"

Avoid assuming knowledge:

Bad: "Use the standard pattern"
Good: "Follow the existing DAO pattern from
```
user/dao.ts:12
```
(class-based with explicit types)"

Avoid incomplete acceptance criteria:

Bad: "Make sure it works"
Good: "Verify: (1) form submits on Enter, (2) shows inline errors, (3) disables submit during request"

Avoid ignoring standards:

Bad: Plan uses
```
any
```
types and manual form state
Good: Plan enforces
```
implement-frontend
```
: no
```
any
```
, uses React Hook Form

避免模糊的计划：

错误示例："更新认证系统"
正确示例："修改
```
auth/middleware.ts:34
```
，新增
```
validateSession()
```
函数检查令牌过期时间"

避免缺失上下文：

错误示例："添加错误处理"
正确示例："在
```
auth/api.ts:67
```
处为API调用添加try/catch包裹，按照
```
audit-ui
```
规范在错误时显示提示弹窗"

避免假设对方已知信息：

错误示例："使用标准模式"
正确示例："遵循
```
user/dao.ts:12
```
中的现有DAO模式（基于类的实现，包含明确类型定义）"

避免不完整的验收标准：

错误示例："确保功能正常"
正确示例："验证：(1) 按Enter键可提交表单，(2) 显示内联错误提示，(3) 请求过程中禁用提交按钮"

避免忽略标准：

错误示例：计划使用
```
any
```
类型和手动维护表单状态
正确示例：计划遵循
```
implement-frontend
```
规范：不使用
```
any
```
类型，采用React Hook Form