Back to Details

execute-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Execute Plan

执行计划

Overview

概述

Execute a pre-approved plan with strict adherence to scope, sequence, and verification.
The input is typically:
  • execute-plan docs/plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md
  • or shorthand: 
    execute-plan docs/plans/YYMMDD-HHmm-<plan-slug>
Do not redesign the plan during execution. If ambiguity or blockers appear, stop and ask.
严格按照范围、顺序和验证要求执行预先获批的计划。
输入格式通常为：
  • execute-plan docs/plans/YYMMDD-HHmm-<plan-slug>/SUMMARY.md
  • 或简写形式：
    execute-plan docs/plans/YYMMDD-HHmm-<plan-slug>
执行过程中不得重新设计计划。若出现歧义或障碍，立即停止并询问。

Workflow

工作流

Step 1: Initialize

步骤1：初始化

  1. Locate Plan
    • Confirm the plan path exists and is readable.
    • If a directory is provided, locate 
      SUMMARY.md
      inside it.
  2. Load Execution Context
    • Read: 
      • docs/project-pdr.md
      • docs/architecture.md
      • docs/codebase.md
      • docs/code-standard.md
    • Review the plan’s phase files and dependencies.
  3. Select Execution Mode (Explicit Rule)
    • Default mode: Batch
    • Use Interactive when any of the following is true:
      • High-risk changes (auth, payments, migrations, security-critical logic)
      • Irreversible operations (data migrations, destructive scripts)
      • Unclear acceptance criteria
      • User explicitly requests checkpoints
    • If mode is unclear, ask once and proceed with user choice.
  4. Find Next Pending Phase
    • First 
      [ ]
      phase
    • If none, first 
      [-]
      phase
    • If no pending/in-progress phases remain, go to final verification.
  5. Critical Plan Sanity Check
    • Ensure each phase has:
      • clear objective
      • file targets
      • verification commands
    • If essential details are missing or contradictory, stop and request clarification.
  1. 定位计划
    • 确认计划路径存在且可读取。
    • 若提供的是目录，则在其中找到
      SUMMARY.md
      文件。
  2. 加载执行上下文
    • 读取以下文件： 
      • docs/project-pdr.md
      • docs/architecture.md
      • docs/codebase.md
      • docs/code-standard.md
    • 审阅计划的阶段文件和依赖项。
  3. 选择执行模式（明确规则）
    • 默认模式：批量模式
    • 满足以下任一条件时使用交互式模式：
      • 高风险变更（认证、支付、数据迁移、安全关键逻辑）
      • 不可逆操作（数据迁移、破坏性脚本）
      • 验收标准不明确
      • 用户明确要求检查点
    • 若模式不明确，询问一次后按照用户选择执行。
  4. 查找下一个待处理阶段
    • 第一个标记为
      [ ]
      的阶段
    • 若无，则选择第一个标记为
      [-]
      的阶段
    • 若没有待处理/进行中的阶段，进入最终验证环节。
  5. 关键计划合理性检查
    • 确保每个阶段包含：
      • 清晰的目标
      • 文件目标
      • 验证命令
    • 若缺少必要细节或存在矛盾，停止执行并请求澄清。

Step 2: Execute Per-Phase Loop

步骤2：分阶段执行循环

For each phase in order:
  1. Skip Completed
    • If status is 
      [x]
      , continue to next phase.
  2. Mark In Progress
    • Update phase status to 
      [-]
      before making changes.
  3. Execute Exactly
    • Implement only the tasks defined in that phase.
    • Do not expand scope without approval.
  4. Verify Phase
    • Run the phase-specific verification commands from the plan.
    • At minimum, run relevant tests/checks tied to touched files.
  5. Handle Failures
    • If verification fails:
      • Attempt focused fixes within phase scope.
      • Re-run verification.
    • If still failing or root cause is outside scope, stop and report blocker.
  6. Mark Complete
    • Update phase status to 
      [x]
      only after verification passes.
  7. Progress Report
    • Interactive mode: report and wait for confirmation before next phase.
    • Batch mode: report briefly and continue immediately.
按顺序处理每个阶段：
  1. 跳过已完成阶段
    • 若状态为
      [x]
      ，继续处理下一个阶段。
  2. 标记为进行中
    • 在进行变更前，将阶段状态更新为
      [-]
      。
  3. 严格执行
    • 仅实施该阶段定义的任务。
    • 未经批准不得扩大范围。
  4. 阶段验证
    • 运行计划中指定的阶段专属验证命令。
    • 至少运行与修改文件相关的测试/检查。
  5. 处理失败情况
    • 若验证失败：
      • 在阶段范围内尝试针对性修复。
      • 重新运行验证。
    • 若仍失败或根本原因超出阶段范围，停止执行并报告障碍。
  6. 标记为完成
    • 仅在验证通过后，将阶段状态更新为
      [x]
      。
  7. 进度报告
    • 交互式模式： 报告进度并等待确认后再进入下一阶段。
    • 批量模式： 简要报告进度后立即继续执行。

Step 3: Final Verification

步骤3：最终验证

After all phases are complete:
  1. Project-Wide Validation
    • Run full lint/type-check suite
    • Run all relevant tests (or full test suite if required by the plan)
    • Run build verification if applicable
  2. Stabilize
    • Fix regressions introduced during execution.
    • Re-run failed checks until green or blocked.
  3. Manual Validation Checkpoint
    • If user/manual QA is required, ask explicitly and pause: 
      • Verified
        to accept
      • or provide feedback for follow-up iteration
所有阶段完成后：
  1. 全项目验证
    • 运行完整的代码检查/类型检查套件
    • 运行所有相关测试（或按计划要求运行完整测试套件）
    • 若适用，运行构建验证
  2. 问题修复
    • 修复执行过程中引入的回归问题。
    • 重新运行失败的检查，直至通过或遇到障碍。
  3. 手动验证检查点
    • 若需要用户/手动QA，明确询问并暂停：
      • 回复
        Verified
        表示接受
      • 或提供反馈以便后续迭代

Step 4: Completion Artifacts

步骤4：完成交付物

  1. Documentation Sync
    • If behavior/architecture/codebase expectations changed, update: 
      • docs/project-pdr.md
      • docs/codebase.md
      • docs/architecture.md
  2. Create Execution Report
    • File: 
      docs/plans/YYMMDD-HHmm-<plan-slug>/EXECUTION-REPORT.md
    • Include all required sections below.
  3. Announce Completion
    • Output: 
      Execution complete. Report created at <path>.
  1. 文档同步
    • 若行为/架构/代码库预期发生变更，更新以下文件： 
      • docs/project-pdr.md
      • docs/codebase.md
      • docs/architecture.md
  2. 生成执行报告
    • 文件路径：
      docs/plans/YYMMDD-HHmm-<plan-slug>/EXECUTION-REPORT.md
    • 必须包含以下所有必填章节。
  3. 宣布完成
    • 输出内容：
      Execution complete. Report created at <path>.

Execution Report Standard

执行报告标准

EXECUTION-REPORT.md
must use this structure:
EXECUTION-REPORT.md
必须使用以下结构：

Execution Report: <Plan Title>

执行报告：<计划标题>

Date: YYYY-MM-DD HH:mm:ss
Mode: Batch | Interactive
Plan Path: <relative-path>
日期：YYYY-MM-DD HH:mm:ss
模式：批量 | 交互式
计划路径：<相对路径>

Summary

摘要

  • Overall result (Completed | Completed with follow-ups | Blocked)
  • High-level outcome in 2-4 bullets
  • 整体结果（已完成 | 已完成但需跟进 | 已阻塞）
  • 2-4条要点式的高层级成果

Phase Results

阶段结果

  • Phase 1: <name> — ✅/⚠️
    • Implemented:
    • Verification:
    • Notes:
  • Phase 2: ...
  • 阶段1：<名称> — ✅/⚠️
    • 已实施内容：
    • 验证情况：
    • 备注：
  • 阶段2：...

Verification Matrix

验证矩阵

  • Lint: pass/fail (command)
  • Type-check: pass/fail (command)
  • Tests: pass/fail (command)
  • Build: pass/fail (command)
  • Manual QA: pass/fail/pending
  • 代码检查：通过/失败（命令）
  • 类型检查：通过/失败（命令）
  • 测试：通过/失败（命令）
  • 构建：通过/失败（命令）
  • 手动QA：通过/失败/待处理

Deviations

偏差记录

  • List any approved deviations from the original plan.
  • If none: 
    None.
  • 列出所有已获批的与原计划的偏差。
  • 若无偏差：
    无。

Blockers and Resolutions

障碍与解决情况

  • Blocker:
  • Impact:
  • Resolution:
  • Status:
  • 障碍：
  • 影响：
  • 解决方案：
  • 状态：

Follow-ups

后续工作

  • Remaining tasks, if any
  • Recommended owner/next action
  • 剩余任务（若有）
  • 建议负责人/下一步行动

Changed Files

修改的文件

  • Relative path list (grouped by area if large)
  • 相对路径列表（若数量较多则按领域分组）

Rules

规则

  • Follow the plan strictly: no silent scope changes.
  • Stop on blocker: missing dependency, contradictory instructions, or unexplained failures.
  • No guessing: ask for clarification when uncertain.
  • Verify before complete: never mark phase done without passing checks.
  • Idempotency: prefer safe/re-runnable operations.
  • Respect project standards: follow 
    docs/code-standard.md
    and related project docs.
  • Do not skip workflow steps: initialization, per-phase verification, final verification, and reporting are all mandatory.
  • 严格遵循计划：不得擅自变更范围。
  • 遇障碍即停止：缺少依赖项、指令矛盾或无法解释的失败。
  • 不得猜测：不确定时请求澄清。
  • 验证通过再完成：未通过检查不得标记阶段完成。
  • 幂等性：优先选择安全/可重复运行的操作。
  • 遵守项目标准：遵循
    docs/code-standard.md
    及相关项目文档。
  • 不得跳过工作流步骤：初始化、分阶段验证、最终验证和报告均为必填步骤。

Integration

集成

  • Use 
    scripts/get-time.sh
    for: 
    • YYMMDD-HHmm
      folder naming
    • YYYY-MM-DD HH:mm:ss
      report timestamps
  • 使用
    scripts/get-time.sh
    用于： 
    • YYMMDD-HHmm
      文件夹命名
    • YYYY-MM-DD HH:mm:ss
      报告时间戳