---

name: plan description: Planning workflow for breaking down tasks into actionable steps. Defines the standard plan structure (milestones/tasks/dependencies/risks) and execution tracking via manage_todo_list.

Skill: PLAN (Execution Planning Protocol)

Purpose

Break down a goal into a structured, executable plan before writing/changing code.

All plans follow the same structure regardless of complexity.

Use manage_todo_list tool to track plan execution.

Workflow

1. Create plan following the Output Format below
2. Present plan to user for approval
3. After approval: convert plan structure to manage_todo_list for execution tracking
4. Execute tasks according to todo list
5. Update plan: Mark completed tasks with [x] checkbox

Task Status Tracking

Use markdown checkboxes to track task progress in PLAN.md:

• [ ] - Not started
• [x] - Completed
• [~] - In progress (optional, can also use manage_todo_list status)

Output format (use exactly this structure but in Chinese in practice)

PLAN.md file structure:

Copy# PLAN: <task title>

## Task Background
- Goal: <main objective description>
- Context: <why this task is needed, current problems>
- Challenges: <expected technical difficulties>
- References: <related code/docs/project links>

---

### PLAN (two-level tree)

Then follow the two-level task structure below:

PLAN (two-level tree)

• Milestone A:
  • A1
    • Purpose:
    • Steps: <2–6 concrete actions>
    • Touchpoints: <files/modules/symbols; use TBD if unknown>
    • Acceptance: <verifiable checks/tests>
  • A2 ...
• Milestone B: ...
  • B1 ... (Keep total milestones <= 5, tasks <= ~12)

DEPENDENCIES

• Blocking: — confirm by
• Non-blocking: — confirm by

RISKS (max 3)

• — impact:<low|med|high>, likelihood:<low|med|high>
  • Mitigation:
  • Detection: <what signal indicates it's happening>

DIAGRAM (optional)

If dependencies/flow matter, include a compact Mermaid diagram focusing on milestone/task dependencies only.

Rules

• Don't claim repo-specific facts without evidence (path/symbol/snippet). If unknown, mark as TBD and add a "Grounding" task.
• Don't start coding until the user confirms the plan or explicitly asks to proceed.
• Keep Mermaid concise; details belong in the task bullets, not node text.
• Use manage_todo_list tool to convert plan into trackable todo items after user approval.

Definition of done for the plan

• Every task has Touchpoints and Acceptance.
• Unknowns are captured as TBD + a Grounding step.
• Risks are explicit and actionable.
• Todo list created via manage_todo_list for execution tracking.