Back to Details

write-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Write Plan

编写计划

Overview

概述

Produce a complete, self-contained implementation plan that can be executed by 
execute-plan
with minimal ambiguity.
This skill is for planning only:
  • Do not implement code
  • Do not modify production files (except plan artifacts)
生成一份完整、独立的实施计划，可通过
execute-plan
执行，且歧义极小。
此技能仅用于规划：
  • 请勿实现代码
  • 请勿修改生产文件（计划制品除外）

Artifact Conventions

制品规范

Use one consistent artifact structure for every plan:
  • Plan directory: 
    docs/plans/YYMMDD-HHmm-<plan-slug>/
  • Main summary: 
    docs/plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md
  • Phase files: 
    docs/plans/YYMMDD-HHmm-<plan-slug>/phase-01-<name>.md
    , 
    phase-02-<name>.md
    , etc.
  • Optional research notes: 
    docs/plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md
Use 
scripts/get-time.sh
for:
  • Folder timestamp: 
    YYMMDD-HHmm
  • Human-readable timestamp: 
    YYYY-MM-DD HH:mm:ss
为每份计划使用统一的制品结构：
  • 计划目录：
    docs/plans/YYMMDD-HHmm-<plan-slug>/
  • 主摘要：
    docs/plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md
  • 阶段文件：
    docs/plans/YYMMDD-HHmm-<plan-slug>/phase-01-<name>.md
    , 
    phase-02-<name>.md
    等
  • 可选研究笔记：
    docs/plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md
使用
scripts/get-time.sh
获取：
  • 文件夹时间戳：
    YYMMDD-HHmm
  • 人类可读时间戳：
    YYYY-MM-DD HH:mm:ss

Workflow

工作流程

Step 1: Contextualize

步骤1：梳理上下文

Read project documentation first:
  • docs/project-pdr.md
  • docs/architecture.md
  • docs/codebase.md
  • docs/code-standard.md
Then inspect only the code areas relevant to the requested change.
Capture:
  • Existing patterns to follow
  • Constraints and dependencies
  • Risks, assumptions, and unknowns
首先阅读项目文档：
  • docs/project-pdr.md
  • docs/architecture.md
  • docs/codebase.md
  • docs/code-standard.md
然后仅检查与请求变更相关的代码区域。
记录：
  • 需遵循的现有模式
  • 约束条件与依赖关系
  • 风险、假设与未知项

Step 2: Initialize Plan Artifacts

步骤2：初始化计划制品

  1. Create: 
    docs/plans/YYMMDD-HHmm-<plan-slug>/
  2. Create: 
    • SUMMARY.md
    • one phase file per implementation phase
  3. Add 
    research/
    only if needed.
  1. 创建目录：
    docs/plans/YYMMDD-HHmm-<plan-slug>/
  2. 创建文件： 
    • SUMMARY.md
    • 每个实施阶段对应一个阶段文件
  3. 仅在需要时添加
    research/
    目录

Step 3: Define Strategy and Phases

步骤3：定义策略与阶段

Design a phased strategy that is safe and verifiable.
Each phase should have:
  • A clear objective
  • Ordered tasks
  • Verification commands
  • Exit criteria
Granularity rule:
  • Tasks should be small, concrete, and typically 2-10 minutes each.
设计安全且可验证的分阶段策略。
每个阶段应包含：
  • 明确的目标
  • 有序的任务
  • 验证命令
  • 退出标准
粒度规则：
  • 任务应小巧、具体，通常耗时2-10分钟。

Step 4: Research (Only if Needed)

步骤4：研究（仅在需要时进行）

Research is optional and should be proportional to uncertainty.
Preferred order:
  1. Existing project docs and code
  2. Existing skills and local references
  3. External references (only if available in the current environment)
If external research capability is unavailable, proceed with local evidence and explicitly list assumptions and open questions.
Document findings in:
  • docs/plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md
研究为可选操作，且应与不确定性程度相匹配。
优先顺序：
  1. 现有项目文档与代码
  2. 现有技能与本地参考资料
  3. 外部参考资料（仅当当前环境中可获取时）
若无法进行外部研究，基于本地证据推进，并明确列出假设与待解决问题。
将研究结果记录在：
  • docs/plans/YYMMDD-HHmm-<plan-slug>/research/<topic>.md

Step 5: Write Plan Content

步骤5：编写计划内容

SUMMARY.md
format

SUMMARY.md
格式

markdown
undefined
markdown
undefined

Implementation Plan: <Title>

实施计划：<标题>

Created: YYYY-MM-DD HH:mm:ss Status: Draft
创建时间：YYYY-MM-DD HH:mm:ss 状态：草稿

Objective

目标

  • What is being built/changed and why.
  • 要构建/变更的内容及原因。

Scope

范围

  • In scope
  • Out of scope
  • 包含范围
  • 排除范围

Architecture & Approach

架构与方法

  • Design decisions and rationale.
  • Constraints and compatibility notes.
  • 设计决策及依据。
  • 约束条件与兼容性说明。

Phases

阶段

  • Phase 1: <name> — Goal: <goal>
  • Phase 2: <name> — Goal: <goal>
  • 阶段1：<名称> — 目标：<目标>
  • 阶段2：<名称> — 目标：<目标>

Key Changes

关键变更

  • Files/modules likely to change
  • Data/API/schema impacts
  • 可能变更的文件/模块
  • 对数据/API/schema的影响

Verification Strategy

验证策略

  • Lint/typecheck/tests/build commands
  • Manual checks if needed
  • 代码检查/类型校验/测试/构建命令
  • 必要时进行人工检查

Dependencies

依赖关系

  • New packages/tools (if any) with reason
  • 新的包/工具（如有）及原因

Risks & Mitigations

风险与缓解措施

  • Risk → mitigation
  • 风险 → 缓解方案

Open Questions

待解决问题

  • Items requiring user confirmation
undefined
  • 需要用户确认的事项
undefined

phase-XX-<name>.md
format

phase-XX-<name>.md
格式

markdown
undefined
markdown
undefined

Phase XX: <Name>

阶段XX：<名称>

Objective

目标

  • Specific result for this phase.
  • 本阶段的具体成果。

Preconditions

前置条件

  • What must already be true.
  • 必须已满足的条件。

Tasks

任务

  1. Context: files/components to inspect or modify
  2. Implement: exact change steps
  3. Verify: commands/checks to run
  4. Confirm: expected outcome
  1. 上下文：需检查或修改的文件/组件
  2. 实施：具体的变更步骤
  3. 验证：需运行的命令/检查项
  4. 确认：预期结果

Verification

验证

  • Commands:
    • <command 1>
    • <command 2>
  • Expected results:
    • <result>
  • 命令：
    • <命令1>
    • <命令2>
  • 预期结果：
    • <结果>

Exit Criteria

退出标准

  • Clear checklist that determines completion.
undefined
  • 用于判定完成状态的清晰检查清单。
undefined

Step 6: Review and Refine

步骤6：审核与优化

Before presenting the plan, verify:
  • Paths are exact and consistent
  • Phase order is logical
  • Tasks are actionable (no vague steps)
  • Verification is defined for each phase
  • Risks/assumptions are explicit
  • Plan is executable without hidden context
Then present for user review.
If multiple viable approaches exist, present options and ask for one of:
  • Validate: refine via additional clarifying questions
  • Confirm: approve current plan for execution
Iterate until confirmed.
在提交计划前，验证以下内容：
  • 路径准确且一致
  • 阶段顺序符合逻辑
  • 任务可执行（无模糊步骤）
  • 每个阶段都定义了验证方式
  • 风险/假设已明确说明
  • 计划可独立执行，无隐藏上下文
然后提交给用户审核。
若存在多种可行方案，列出选项并请用户选择以下操作之一：
  • 验证：通过额外澄清问题优化计划
  • 确认：批准当前计划用于执行
反复迭代直至获得确认。

Step 7: Handoff

步骤7：交接

When approved, end with:
Plan 
<relative_path_to_plan>/SUMMARY.md
is ready.
Use 
/clear
and then 
/execute-plan <relative_path_to_plan>/SUMMARY.md
to execute it.
获得批准后，结尾需包含：
计划
<relative_path_to_plan>/SUMMARY.md
已准备就绪。
请先执行
/clear
，再执行
/execute-plan <relative_path_to_plan>/SUMMARY.md
来运行计划。

Rules

规则

  • Never automatically implement or execute the code change in the same session, or ask user for execution right now, always finished when completed planning and ready for user review.
  • Prefer explicit file paths and concrete commands
  • Align with project standards and existing architecture
  • Ask clarifying questions when uncertainty affects execution safety
  • Keep plans self-contained and deterministic
  • 切勿在同一会话中自动实现或执行代码变更，也不要立即请求用户允许执行，完成规划并准备好提交用户审核后即结束当前操作。
  • 优先使用明确的文件路径与具体命令
  • 与项目标准及现有架构保持一致
  • 当不确定性影响执行安全性时，提出澄清问题
  • 确保计划独立且可预测