Back to Details

plan-implementation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Plan Implementation

实施规划

Methodology for decomposing work into implementation units and planning each one. Use this skill standalone or as a reference from other planning skills.
将工作分解为实施单元并对每个单元进行规划的方法论。可独立使用本技能，也可作为其他规划技能的参考。

Decomposition

分解

Sizing

规模划分

  • One unit = one logical unit of work (a feature, a subsystem, a layer)
  • Never split tightly-coupled pieces across units (if UI + API + tests are inseparable, keep them together)
  • Split independent subsystems into separate units
  • If a unit would touch more than ~15-20 files or span 3+ unrelated subsystems, split further
  • If the entire scope fits one session, produce a single unit — do not over-decompose
  • Each unit must leave the codebase fully integrated — never leave components unreachable from the project's entry points
  • 一个单元 = 一个逻辑工作单元（功能、子系统、层级）
  • 切勿将紧密耦合的部分拆分到不同单元中（若UI + API + 测试不可分割，则将它们放在一起）
  • 将独立子系统拆分为单独单元
  • 若一个单元涉及超过约15-20个文件，或跨越3个及以上不相关子系统，则进一步拆分
  • 若整个范围可在一个会话内完成，则生成单个单元——避免过度分解
  • 每个单元必须确保代码库完全集成——切勿留下无法从项目入口点访问的组件

Ordering

排序

Order by dependency — foundational work before dependent work:
  1. Setup and scaffolding (project init, config, CI)
  2. Data and domain layer (models, schemas, types)
  3. Core business logic
  4. API and service layer
  5. UI and frontend
  6. Integration and end-to-end concerns
  7. Finalization (QA, commit, PR — always last)
按依赖关系排序——基础工作先于依赖工作：
  1. 搭建与脚手架（项目初始化、配置、CI）
  2. 数据与领域层（模型、模式、类型）
  3. 核心业务逻辑
  4. API与服务层
  5. UI与前端
  6. 集成与端到端相关工作
  7. 最终收尾（QA、提交、PR——始终放在最后）

Adaptation

适配

When a plan meets reality, adjust for divergence before executing:
  • File paths changed — update references to match actual structure
  • Architecture evolved — adjust the plan to work with what was actually built
  • Scope shifted — add or remove items based on what prior work produced
  • New information — incorporate discoveries from previous sessions
Keep adaptations minimal — adjust only what diverged, do not rewrite plans unnecessarily.
当规划与实际情况不符时，在执行前进行调整：
  • 文件路径变更——更新引用以匹配实际结构
  • 架构演进——调整规划以适配实际构建的架构
  • 范围变更——根据前期工作成果添加或删除内容
  • 新信息——纳入之前会话中的新发现
尽量减少调整——仅对出现偏差的部分进行调整，无需不必要地重写规划。

Planning Each Unit

规划每个单元

For each unit of work, plan the implementation thoroughly:
  1. Explore the codebase — read files relevant to the unit's scope, understand existing patterns, find code to build on
  2. Design the implementation — determine what files to create or modify, what approach to take, what tests to write
  3. Write a detailed plan — specific enough to execute: exact file paths, function signatures, data flow, test cases
  4. Include a task list — one task per step in the plan
  5. Include relevant skills — identify which skills apply and instruct: "After plan approval and before making edits, run 
    /skill-a
    , 
    /skill-b
    ."
针对每个工作单元，详尽规划实施内容：
  1. 探索代码库——阅读与该单元范围相关的文件，理解现有模式，寻找可复用的代码
  2. 设计实施方案——确定要创建或修改的文件、采用的方法、要编写的测试
  3. 编写详细规划——具体到可直接执行：精确的文件路径、函数签名、数据流、测试用例
  4. 包含任务列表——规划中的每个步骤对应一项任务
  5. 关联相关技能——识别适用的技能并说明：“在规划获批且开始编辑前，运行
    /skill-a
    、
    /skill-b
    。”

Rules

规则

  • Split conservatively when scope is ambiguous (smaller units are safer than oversized ones)
  • Each unit must be self-contained with enough context to understand the work without reading the full plan
  • Never merge setup and finalization into the same unit
  • 当范围不明确时，保守拆分（较小的单元比过大的单元更安全）
  • 每个单元必须具备自包含性，无需阅读完整规划即可理解工作内容
  • 切勿将搭建与收尾工作合并到同一单元中