project-planning

Original：🇨🇳 Chinese

Translated

Use when you need to move a feature from a vague concept to an executable development plan, and complete requirement analysis, task breakdown, and status tracking within the same plan document.

2installs

Sourcezhucl1006/skills

Added on2026-02-26

NPX Install

npx skill4agent add zhucl1006/skills project-planning

SKILL.md Content (Chinese)

View Translation Comparison →

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

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)

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

Mode A: Analysis-Driven (Unclear Requirements)

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

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: Read Context

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: 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: Produce Requirement Analysis

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: Produce Implementation Plan

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: 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: Quality Check (Self-Inspection Before Writing)

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: Delivery and Next Steps

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)

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
```
: 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

.