project-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

项目规划（分析 + 计划一体化）

Project Planning (Analysis + Planning Integration)

本技能用于在开发前产出可执行的“分析计划文件”，既完成需求分析，也完成实施任务编排。

This skill is used to produce an executable "analysis plan document" before development, which completes both requirement analysis and implementation task orchestration.

何时使用

When to Use

你要规划一个新功能、模块改造或缺陷修复
你希望先澄清需求，再得到可落地的开发任务
你需要一份可追踪状态的计划文档，供后续
```
project-workflow
```
执行

不适用：仅需直接编码、不需要分析与计划沉淀的超小改动。

You need to plan a new feature, module refactoring, or bug fix
You want to clarify requirements first, then obtain actionable development tasks
You need a trackable plan document for subsequent execution of
```
project-workflow
```

Not applicable: Ultra-small changes that only require direct coding without analysis and plan documentation.

核心产出契约（必须遵守）

Core Output Contract (Must Comply)

输出文件：
```
docs/plans/001-feature-name.md
```
（3 位编号 + kebab-case 名称）。

模板来源：

./plan-templates/combined-plan-template.md

。

文档必须同时包含：
- 需求分析（目标、边界、风险、隐含需求、验收标准）
- 实施计划（任务拆解、依赖关系、TDD 执行步骤）
- 状态管理（整体进度、任务状态总览、执行记录）

每个任务必须可追踪：

任务ID

、

状态

、

负责人

、

开始时间

、

完成时间

、

阻塞原因

。

初始状态统一为：
```
待开始
```
。

Output file:
```
docs/plans/001-feature-name.md
```
(3-digit number + kebab-case name).

Template source:

./plan-templates/combined-plan-template.md

The document must include simultaneously:
- Requirement analysis (objectives, boundaries, risks, implicit requirements, acceptance criteria)
- Implementation plan (task breakdown, dependency relationships, TDD execution steps)
- Status management (overall progress, task status overview, execution records)

Each task must be trackable:

Task ID

Status

Assignee

Start Time

Completion Time

Blocking Reason

Initial status is unified as:
```
To Be Started
```
.

工作模式

Working Modes

模式 A：分析驱动（需求不清晰）

Mode A: Analysis-Driven (Unclear Requirements)

触发信号：需求边界模糊、方案分歧明显、验收标准不完整。

执行方式：

一次只问一个问题，优先多选题
每轮给出 2-3 个方案（含推荐与权衡）
分段确认后再进入任务拆解

Trigger signals: Vague requirement boundaries, obvious solution differences, incomplete acceptance criteria.

Execution method:

Ask only one question at a time, prioritize multiple-choice questions
Provide 2-3 options per round (including recommendations and trade-offs)
Proceed to task breakdown only after segmented confirmation

模式 B：直写计划（需求清晰）

Mode B: Direct Plan Writing (Clear Requirements)

触发信号：目标、范围、验收标准、技术约束都已明确。

执行方式：

快速复述需求并确认边界
直接输出分析结论与实施计划

Trigger signals: Objectives, scope, acceptance criteria, and technical constraints are all clear.

Execution method:

Quickly restate requirements and confirm boundaries
Directly output analysis conclusions and implementation plan

执行流程

Execution Process

Step 0：读取上下文

Step 0: Read Context

读取
```
docs/README.md
```
读取相关规范（如存在）：
```
docs/specs/PRD.md
```
、
```
docs/specs/SAD.md
```
读取相关模块文档（如存在）：
```
docs/modules/*.md
```
检查既有计划：
```
docs/plans/
```

Read
```
docs/README.md
```
Read relevant specifications (if existing):
```
docs/specs/PRD.md
```
,
```
docs/specs/SAD.md
```
Read relevant module documents (if existing):
```
docs/modules/*.md
```
Check existing plans:
```
docs/plans/
```

Step 1：需求澄清与边界确认

Step 1: Requirement Clarification and Boundary Confirmation

至少明确以下内容：

业务目标（为什么做）
范围内 / 范围外（做什么 / 不做什么）
成功标准（如何判定完成）
关键约束（技术、时间、依赖）

At least clarify the following:

Business objectives (why do it)
In-scope / Out-of-scope (what to do / what not to do)
Success criteria (how to determine completion)
Key constraints (technical, time, dependencies)

Step 2：产出需求分析

Step 2: Produce Requirement Analysis

在计划文档中输出：

需求摘要
用户路径 / 核心交互
验收标准（AC）草案：改写为可测试条目
风险与假设
隐含需求清单（权限、空状态、错误状态、性能、兼容性、可观测性）

Output in the plan document:

Requirement summary
User path / core interaction
Draft acceptance criteria (AC): Rewrite into testable items
Risks and assumptions
Implicit requirements list (permissions, empty states, error states, performance, compatibility, observability)

Step 3：产出实施计划

Step 3: Produce Implementation Plan

任务拆解要求：

单任务粒度 2-5 分钟
明确依赖与执行顺序
每个任务包含 TDD 最小闭环：
- RED：先写失败测试并验证失败
- GREEN：最小实现并验证通过
- REFACTOR：重构并回归验证
每个任务写清：文件路径、命令、预期结果、完成证据

Task breakdown requirements:

Single task granularity: 2-5 minutes
Clear dependencies and execution order
Each task includes a minimum TDD closed loop:
- RED: First write a failing test and verify failure
- GREEN: Minimal implementation and verify pass
- REFACTOR: Refactor and verify regression
Each task must specify: file path, command, expected result, completion evidence

Step 4：初始化状态管理

Step 4: Initialize Status Management

计划落地时必须初始化：

整体进度（按阶段）
任务状态总览表（全部任务默认
```
待开始
```
）
执行记录（写入第一条记录）

When implementing the plan, you must initialize:

Overall progress (by phase)
Task status overview table (all tasks default to
```
To Be Started
```
)
Execution records (write the first record)

Step 5：质量校验（写入前自检）

Step 5: Quality Check (Self-Inspection Before Writing)

KISS：任务描述不绕弯、可直接执行
YAGNI：删除“可能以后要做”的内容
DRY：避免重复任务；相同模式合并
SOLID：任务职责单一、依赖方向清晰
可验证：每条 AC 都能映射到测试或验证动作

KISS: Task descriptions are straightforward and directly executable
YAGNI: Remove content that "might be needed later"
DRY: Avoid duplicate tasks; merge identical patterns
SOLID: Single responsibility for tasks, clear dependency direction
Verifiable: Each AC can be mapped to a test or verification action

Step 6：交付与下一步

Step 6: Delivery and Next Steps

完成后明确提示：

计划文件位置
推荐使用
```
project-workflow
```
执行
如有未决问题，列出“阻塞项 + 建议决策”

After completion, clearly indicate:

Plan file location
Recommended use of
```
project-workflow
```
for execution
If there are unresolved issues, list "blockers + recommended decisions"

对话与澄清规范

Dialogue and Clarification Specifications

每次只推进一个关键问题
优先多选题，减少沟通成本
回答后立即更新分析结论，避免信息漂移
当信息不足时，明确标注“假设”而不是臆测

Only advance one key question at a time
Prioritize multiple-choice questions to reduce communication costs
Update analysis conclusions immediately after receiving answers to avoid information drift
When information is insufficient, clearly mark "assumption" instead of speculating

任务编写规则（强约束）

Task Writing Rules (Strong Constraints)

每个任务必须有唯一
```
任务ID
```
（如
```
T01
```
、
```
T02
```
）。
每个任务必须标注
```
依赖任务
```
（无依赖写
```
无
```
）。
每个任务必须列出：
- 创建文件
- 修改文件
- 测试文件
每个任务必须具备可执行命令与预期输出。
未通过 RED/GREEN/REFACTOR 任一环节，不得标记为
```
已完成
```
。

Each task must have a unique
```
Task ID
```
(e.g.,
```
T01
```
,
```
T02
```
).
Each task must mark
```
Dependent Tasks
```
(write
```
None
```
if no dependencies).
Each task must list:
- Create file
- Modify file
- Test file
Each task must include executable commands and expected outputs.
Do not mark as
```
Completed
```
if any of the RED/GREEN/REFACTOR steps are not passed.

与其他技能关系

Relationship with Other Skills

```
project-docs-setup
```
：先补齐项目文档，再做计划。
```
project-workflow
```
：按本技能产出的计划执行开发。

建议链路：

project-docs-setup → project-planning → project-workflow

。

```
project-docs-setup
```
: Complete project documentation first, then make the plan.
```
project-workflow
```
: Execute development according to the plan produced by this skill.

Recommended workflow:

project-docs-setup → project-planning → project-workflow