Back to Details

executing-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Executing Plans

执行计划

Overview

概述

This skill orchestrates the execution of implementation plans generated by the 
decomposing-tasks
skill. It handles the complete lifecycle of plan execution including worktree verification, resume detection, phase-by-phase execution (sequential or parallel), quality verification, and final stack completion.
该Skill用于编排由
decomposing-tasks
Skill生成的实施计划的执行。它负责计划执行的完整生命周期，包括worktree验证、恢复检测、分阶段执行（串行或并行）、质量验证以及最终的栈完成操作。

When to Use

使用场景

Use this skill when:
  • Executing an implementation plan from 
    /spectacular:execute
  • Resuming interrupted plan execution
  • Orchestrating multi-phase feature implementation
Announce: "I'm using executing-plan to orchestrate implementation of the plan."
在以下场景中使用该Skill：
  • 执行来自
    /spectacular:execute
    的实施计划
  • 恢复中断的计划执行
  • 编排多阶段功能实现
声明： "我正在使用executing-plan Skill来编排计划的实施。"

Architecture

架构

The execute command uses an orchestrator-with-embedded-instructions architecture for cognitive load reduction:
Orchestrator Skills (
executing-sequential-phase
, 
executing-parallel-phase
)
  • Responsibilities: Setup, worktree management, dispatch coordination, code review orchestration
  • Size: ~464 lines (sequential), ~850 lines (parallel)
  • Dispatches: Task tool with embedded execution instructions (~150 lines per task)
  • Focus: Manages workflow lifecycle, embeds focused task instructions for subagents
Verification Skill (
phase-task-verification
)
  • Responsibilities: Shared git operations (add, branch create, HEAD verify, detach)
  • Size: ~92 lines
  • Used by: Task subagents via Skill tool (both sequential and parallel)
  • Focus: Eliminates duplication of branch creation/verification logic
Cognitive Load Reduction:
  • Original: 750-line monolithic skills (orchestration + task + verification mixed)
  • Current: Subagents receive ~150 lines of focused task execution instructions via Task tool
  • Benefit: 80% reduction in content subagents must parse (only see task instructions, not orchestration)
  • Verification: Shared 92-line skill eliminates duplication
Maintainability benefit: Orchestrator features (resume support, enhanced error recovery, verification improvements) can be added without affecting task execution instructions. Subagents receive focused, consistent instructions while orchestrators handle workflow complexity.
Testing framework: This plugin uses Test-Driven Development for workflow documentation. See 
tests/README.md
and 
CLAUDE.md
for the complete testing system. All changes to commands and skills must pass the test suite before committing.
execute命令采用"编排器嵌入指令"架构以降低认知负载：
编排器Skill (
executing-sequential-phase
, 
executing-parallel-phase
)
  • 职责：初始化、worktree管理、调度协调、代码审查编排
  • 代码量：约464行（串行），约850行（并行）
  • 调度：通过Task工具嵌入执行指令（每个任务约150行）
  • 核心：管理工作流生命周期，为子Agent嵌入聚焦的任务指令
验证Skill (
phase-task-verification
)
  • 职责：共享Git操作（add、分支创建、HEAD验证、分离HEAD）
  • 代码量：约92行
  • 使用方式：任务子Agent通过Skill工具调用（串行和并行场景均适用）
  • 核心：消除分支创建/验证逻辑的重复
认知负载降低：
  • 原架构：750行单体Skill（编排+任务+验证混合）
  • 当前架构：子Agent通过Task工具接收约150行聚焦的任务执行指令
  • 收益：子Agent需要解析的内容减少80%（仅需查看任务指令，无需关注编排逻辑）
  • 验证：共享的92行Skill消除了代码重复
可维护性收益： 可以在不影响任务执行指令的情况下添加编排器功能（恢复支持、增强的错误恢复、验证改进）。子Agent接收聚焦且一致的指令，而编排器处理工作流的复杂性。
测试框架： 该插件使用测试驱动开发（TDD）进行工作流文档编写。完整的测试系统请参见
tests/README.md
和
CLAUDE.md
。在提交前，所有对命令和Skill的修改必须通过测试套件。

Available Skills

可用Skill

Skills are referenced on-demand when you encounter the relevant step. Do not pre-read all skills upfront.
Phase Execution (read when you encounter the phase type):
  • executing-parallel-phase
    - Mandatory workflow for parallel phases (Step 2)
  • executing-sequential-phase
    - Mandatory workflow for sequential phases (Step 2)
Support Skills (read as needed when referenced):
  • understanding-cross-phase-stacking
    - Reference before starting any phase (explains base branch inheritance)
  • validating-setup-commands
    - Reference if CLAUDE.md setup validation needed (Step 1.5)
  • using-git-spice
    - Reference for git-spice command syntax (as needed)
  • requesting-code-review
    - Reference after each phase completes (Step 2)
  • verification-before-completion
    - Reference before claiming completion (Step 3)
  • finishing-a-development-branch
    - Reference after all phases complete (Step 4)
  • troubleshooting-execute
    - Reference if execution fails (error recovery)
  • using-git-worktrees
    - Reference if worktree issues occur (diagnostics)
仅在遇到相关步骤时按需参考Skill，无需预先阅读所有Skill。
阶段执行（遇到对应阶段类型时阅读）：
  • executing-parallel-phase
    - 并行阶段的强制工作流（步骤2）
  • executing-sequential-phase
    - 串行阶段的强制工作流（步骤2）
支持Skill（按需参考）：
  • understanding-cross-phase-stacking
    - 开始任何阶段前参考（解释基础分支继承机制）
  • validating-setup-commands
    - 若需要验证CLAUDE.md的初始化命令时参考（步骤1.5）
  • using-git-spice
    - 参考git-spice命令语法（按需使用）
  • requesting-code-review
    - 每个阶段完成后参考（步骤2）
  • verification-before-completion
    - 声明完成前参考（步骤3）
  • finishing-a-development-branch
    - 所有阶段完成后参考（步骤4）
  • troubleshooting-execute
    - 执行失败时参考（错误恢复）
  • using-git-worktrees
    - 遇到worktree问题时参考（诊断）

Multi-Repo Support

多仓库支持

Detecting Multi-Repo Mode

检测多仓库模式

At the start of execution, detect workspace mode:
bash
undefined
执行开始时，检测工作区模式：
bash
undefined

Detect workspace mode

Detect workspace mode

REPO_COUNT=$(find . -maxdepth 2 -name ".git" -type d 2>/dev/null | wc -l | tr -d ' ') if [ "$REPO_COUNT" -gt 1 ]; then echo "Multi-repo workspace detected ($REPO_COUNT repos)" WORKSPACE_MODE="multi-repo" REPOS=$(find . -maxdepth 2 -name ".git" -type d | xargs -I{} dirname {} | sed 's|^./||' | tr '\n' ' ') echo "Available repos: $REPOS" else echo "Single-repo mode" WORKSPACE_MODE="single-repo" fi
undefined
REPO_COUNT=$(find . -maxdepth 2 -name ".git" -type d 2>/dev/null | wc -l | tr -d ' ') if [ "$REPO_COUNT" -gt 1 ]; then echo "Multi-repo workspace detected ($REPO_COUNT repos)" WORKSPACE_MODE="multi-repo" REPOS=$(find . -maxdepth 2 -name ".git" -type d | xargs -I{} dirname {} | sed 's|^./||' | tr '\n' ' ') echo "Available repos: $REPOS" else echo "Single-repo mode" WORKSPACE_MODE="single-repo" fi
undefined

Multi-Repo Execution Differences

多仓库执行差异

AspectSingle-RepoMulti-Repo
Worktree
.worktrees/{runId}-main/
Per-task: 
{repo}/.worktrees/{runId}-task-X-Y/
Spec location
specs/{runId}-{feature}/
./specs/{runId}-{feature}/
(workspace root)
Setup commandsOne CLAUDE.mdPer-repo CLAUDE.md
Constitution
@docs/constitutions/current/
@{repo}/docs/constitutions/current/
Git-spice stackSingle stackPer-repo stacks
维度单仓库多仓库
Worktree
.worktrees/{runId}-main/
每个任务对应：
{repo}/.worktrees/{runId}-task-X-Y/
规格文件位置
specs/{runId}-{feature}/
./specs/{runId}-{feature}/
（工作区根目录）
初始化命令单个CLAUDE.md每个仓库对应一个CLAUDE.md
章程
@docs/constitutions/current/
@{repo}/docs/constitutions/current/
Git-spice栈单个栈每个仓库对应独立栈

Passing Repo Context to Phase Skills

向阶段Skill传递仓库上下文

When dispatching phase execution, include repo context:
markdown
**Multi-repo context for phase:**
- WORKSPACE_MODE: multi-repo
- WORKSPACE_ROOT: {absolute path}
- Task repos: {list of repos with tasks in this phase}
- Per-task repo: extracted from plan's `**Repo**: {repo}` field
调度阶段执行时，需包含仓库上下文：
markdown
**阶段的多仓库上下文：**
- WORKSPACE_MODE: multi-repo
- WORKSPACE_ROOT: {绝对路径}
- 任务仓库：{此阶段包含任务的仓库列表}
- 每个任务的仓库：从计划的`**Repo**: {repo}`字段提取
阶段Skill使用这些信息：
  • 在正确的仓库中创建worktree
  • 读取对应仓库的CLAUDE.md
  • 读取对应仓库的章程

The Process

执行流程

Input

输入

User will provide: 
/spectacular:execute {plan-path}
Example: 
/spectacular:execute @specs/a1b2c3-magic-link-auth/plan.md
Where 
a1b2c3
is the runId and 
magic-link-auth
is the feature slug.
用户将提供：
/spectacular:execute {plan-path}
示例：
/spectacular:execute @specs/a1b2c3-magic-link-auth/plan.md
其中
a1b2c3
是runId，
magic-link-auth
是功能标识（feature slug）。

Step 0a: Extract Run ID from Plan

步骤0a：从计划中提取RUN_ID

User provided plan path: The user gave you a plan path like 
.worktrees/3a00a7-main/specs/3a00a7-agent-standardization-refactor/plan.md
Extract RUN_ID from the path:
The RUN_ID is the first segment of the spec directory name (before the first dash).
For example:
  • Path: 
    .worktrees/3a00a7-main/specs/3a00a7-agent-standardization-refactor/plan.md
  • Directory: 
    3a00a7-agent-standardization-refactor
  • RUN_ID: 
    3a00a7
bash
undefined
用户提供的计划路径：用户会提供类似
.worktrees/3a00a7-main/specs/3a00a7-agent-standardization-refactor/plan.md
的路径
从路径中提取RUN_ID：
RUN_ID是规格目录名称的第一个段（第一个短横线之前的部分）。
例如：
  • 路径：
    .worktrees/3a00a7-main/specs/3a00a7-agent-standardization-refactor/plan.md
  • 目录：
    3a00a7-agent-standardization-refactor
  • RUN_ID：
    3a00a7
bash
undefined

Extract RUN_ID and FEATURE_SLUG from plan path (replace {the-plan-path-user-provided} with actual path)

Extract RUN_ID and FEATURE_SLUG from plan path (replace {the-plan-path-user-provided} with actual path)

PLAN_PATH="{the-plan-path-user-provided}" DIR_NAME=$(echo "$PLAN_PATH" | sed 's|^.*specs/||; s|/plan.md$||') RUN_ID=$(echo "$DIR_NAME" | cut -d'-' -f1) FEATURE_SLUG=$(echo "$DIR_NAME" | cut -d'-' -f2-)
echo "Extracted RUN_ID: $RUN_ID" echo "Extracted FEATURE_SLUG: $FEATURE_SLUG"
PLAN_PATH="{the-plan-path-user-provided}" DIR_NAME=$(echo "$PLAN_PATH" | sed 's|^.*specs/||; s|/plan.md$||') RUN_ID=$(echo "$DIR_NAME" | cut -d'-' -f1) FEATURE_SLUG=$(echo "$DIR_NAME" | cut -d'-' -f2-)
echo "Extracted RUN_ID: $RUN_ID" echo "Extracted FEATURE_SLUG: $FEATURE_SLUG"

Verify RUN_ID and FEATURE_SLUG are not empty

Verify RUN_ID and FEATURE_SLUG are not empty

if [ -z "$RUN_ID" ]; then echo "Error: Could not extract RUN_ID from plan path: $PLAN_PATH" exit 1 fi
if [ -z "$FEATURE_SLUG" ]; then echo "Error: Could not extract FEATURE_SLUG from plan path: $PLAN_PATH" exit 1 fi

**CRITICAL**: Execute this entire block as a single multi-line Bash tool call. The comment on the first line is REQUIRED - without it, command substitution `$(...)` causes parse errors.

**Store RUN_ID and FEATURE_SLUG for use in:**

- Branch naming: `{run-id}-task-X-Y-name`
- Filtering: `git branch | grep "^  {run-id}-"`
- Spec path: `specs/{run-id}-{feature-slug}/spec.md`
- Cleanup: Identify which branches/specs belong to this run

**Announce:** "Executing with RUN_ID: {run-id}, FEATURE_SLUG: {feature-slug}"
if [ -z "$RUN_ID" ]; then echo "Error: Could not extract RUN_ID from plan path: $PLAN_PATH" exit 1 fi
if [ -z "$FEATURE_SLUG" ]; then echo "Error: Could not extract FEATURE_SLUG from plan path: $PLAN_PATH" exit 1 fi

**关键注意事项**：将整个代码块作为单个多行Bash工具调用执行。第一行的注释是必需的——没有它，命令替换`$(...)`会导致解析错误。

**存储RUN_ID和FEATURE_SLUG用于：**

- 分支命名：`{run-id}-task-X-Y-name`
- 过滤：`git branch | grep "^  {run-id}-"`
- 规格文件路径：`specs/{run-id}-{feature-slug}/spec.md`
- 清理：识别属于本次运行的分支/规格文件

**声明：** "Executing with RUN_ID: {run-id}, FEATURE_SLUG: {feature-slug}"

Step 0b: Verify Worktree Exists

步骤0b：验证Worktree存在

Multi-repo mode: Skip worktree verification at orchestrator level. Each task will create its own worktree in its repo during phase execution.
bash
if [ "$WORKSPACE_MODE" = "multi-repo" ]; then
  echo "Multi-repo mode: Worktrees created per-task during execution"
  # Verify spec exists at workspace root
  if [ ! -f "specs/${RUN_ID}-${FEATURE_SLUG}/plan.md" ]; then
    echo "Error: Plan not found at specs/${RUN_ID}-${FEATURE_SLUG}/plan.md"
    exit 1
  fi
  echo "Plan verified: specs/${RUN_ID}-${FEATURE_SLUG}/plan.md"
fi
Single-repo mode: Continue with existing worktree verification.
After extracting RUN_ID, verify the worktree exists:
bash
undefined
多仓库模式：在编排器层面跳过worktree验证。每个任务会在阶段执行期间在其对应仓库中创建自己的worktree。
bash
if [ "$WORKSPACE_MODE" = "multi-repo" ]; then
  echo "Multi-repo mode: Worktrees created per-task during execution"
  # Verify spec exists at workspace root
  if [ ! -f "specs/${RUN_ID}-${FEATURE_SLUG}/plan.md" ]; then
    echo "Error: Plan not found at specs/${RUN_ID}-${FEATURE_SLUG}/plan.md"
    exit 1
  fi
  echo "Plan verified: specs/${RUN_ID}-${FEATURE_SLUG}/plan.md"
fi
单仓库模式：继续执行现有的worktree验证。
提取RUN_ID后，验证worktree是否存在：
bash
undefined

Get absolute repo root (stay in main repo, don't cd into worktree)

Get absolute repo root (stay in main repo, don't cd into worktree)

REPO_ROOT=$(git rev-parse --show-toplevel)
REPO_ROOT=$(git rev-parse --show-toplevel)

Verify worktree exists

Verify worktree exists

if [ ! -d "$REPO_ROOT/.worktrees/${RUN_ID}-main" ]; then echo "Error: Worktree not found at .worktrees/${RUN_ID}-main" echo "Run /spectacular:spec first to create the workspace." exit 1 fi
if [ ! -d "$REPO_ROOT/.worktrees/${RUN_ID}-main" ]; then echo "Error: Worktree not found at .worktrees/${RUN_ID}-main" echo "Run /spectacular:spec first to create the workspace." exit 1 fi

Verify it's a valid worktree

Verify it's a valid worktree

git worktree list | grep "${RUN_ID}-main"

**IMPORTANT: Orchestrator stays in main repo. All worktree operations use `git -C .worktrees/{run-id}-main` or absolute paths.**

**This ensures task worktrees are created at the same level as {run-id}-main, not nested inside it.**

**Announce:** "Verified worktree exists: .worktrees/{run-id}-main/"
git worktree list | grep "${RUN_ID}-main"

**重要提示：** 编排器始终停留在主仓库中。所有worktree操作使用`git -C .worktrees/{run-id}-main`或绝对路径。

**这确保任务worktree创建在{run-id}-main的同一层级，而非嵌套在其中。**

**声明：** "Verified worktree exists: .worktrees/{run-id}-main/"

Step 0c: Check for Existing Work

步骤0c：检查现有工作

Check if implementation work already exists:
bash
undefined
检查是否已存在实施工作：
bash
undefined

Get repo root

Get repo root

REPO_ROOT=$(git rev-parse --show-toplevel)
REPO_ROOT=$(git rev-parse --show-toplevel)

Check current branch in main worktree

Check current branch in main worktree

CURRENT_BRANCH=$(git -C "$REPO_ROOT/.worktrees/${RUN_ID}-main" branch --show-current 2>/dev/null || echo "")
CURRENT_BRANCH=$(git -C "$REPO_ROOT/.worktrees/${RUN_ID}-main" branch --show-current 2>/dev/null || echo "")

Count existing task branches for this RUN_ID

Count existing task branches for this RUN_ID

EXISTING_TASKS=$(git branch 2>/dev/null | grep -c "^ ${RUN_ID}-task-" || echo "0")
EXISTING_TASKS=$(git branch 2>/dev/null | grep -c "^ ${RUN_ID}-task-" || echo "0")

Report status

Report status

if [ "$EXISTING_TASKS" -gt 0 ]; then echo "Found $EXISTING_TASKS existing task branch(es) for RUN_ID: $RUN_ID" echo " Current branch: $CURRENT_BRANCH" echo "" echo "Resuming from current state. The execution will:" echo "- Sequential phases: Continue from current branch" echo "- Parallel phases: Skip completed tasks, run remaining" echo "" else echo "No existing work found - starting fresh execution" echo "" fi

**CRITICAL**: Execute this entire block as a single multi-line Bash tool call. The comment on the first line is REQUIRED - without it, command substitution `$(...)` causes parse errors.

**Resume behavior:**
- If `EXISTING_TASKS > 0`: Execution continues from current state in main worktree
- If `EXISTING_TASKS = 0`: Execution starts from Phase 1, Task 1
- Main worktree current branch indicates progress (latest completed work)

**Note:** Orchestrator proceeds immediately to Step 1. Phase execution logic in Step 2 handles resume by checking current branch and existing task branches.
if [ "$EXISTING_TASKS" -gt 0 ]; then echo "Found $EXISTING_TASKS existing task branch(es) for RUN_ID: $RUN_ID" echo " Current branch: $CURRENT_BRANCH" echo "" echo "Resuming from current state. The execution will:" echo "- Sequential phases: Continue from current branch" echo "- Parallel phases: Skip completed tasks, run remaining" echo "" else echo "No existing work found - starting fresh execution" echo "" fi

**关键注意事项**：将整个代码块作为单个多行Bash工具调用执行。第一行的注释是必需的——没有它，命令替换`$(...)`会导致解析错误。

**恢复行为：**
- 如果`EXISTING_TASKS > 0`：从主worktree的当前状态继续执行
- 如果`EXISTING_TASKS = 0`：从阶段1、任务1开始执行
- 主worktree的当前分支表示执行进度（最新完成的工作）

**注意：** 编排器直接进入步骤1。步骤2中的阶段执行逻辑通过检查当前分支和现有任务分支来处理恢复操作。

Step 1: Read and Parse Plan

步骤1：读取并解析计划

Read the plan file and extract:
  • Feature name
  • All phases (with strategy: sequential or parallel)
  • All tasks within each phase
For each task, extract and format:
  • Task ID and name
  • Files to modify (explicit paths)
  • Acceptance criteria (bullet points)
  • Dependencies (which tasks must complete first)
Store extracted task info for subagent prompts (saves ~1000 tokens per subagent):
Task 4.2:
Name: Integrate prompts module into generator
Files: - src/generator.ts - src/types.ts
Acceptance Criteria: - Import PromptService from prompts module - Replace manual prompt construction with PromptService.getCommitPrompt() - Update tests to mock PromptService - All tests pass
Dependencies: Task 4.1 (fallback logic removed)
Multi-repo plan parsing:
For multi-repo plans, also extract the 
repo
field from each task:
Task 4.2:
Name: Integrate prompts module into generator
Repo: backend  # NEW - required in multi-repo mode
Files: - src/generator.ts - src/types.ts
Acceptance Criteria: - Import PromptService from prompts module - Replace manual prompt construction with PromptService.getCommitPrompt() - Update tests to mock PromptService - All tests pass
Dependencies: Task 4.1 (fallback logic removed)
Pass repo information to phase execution skills.
Verify plan structure:
  • Has phases with clear strategies
  • All tasks have files specified
  • All tasks have acceptance criteria
  • Dependencies make sense
读取计划文件并提取：
  • 功能名称
  • 所有阶段（包含策略：串行或并行）
  • 每个阶段内的所有任务
针对每个任务，提取并格式化：
  • 任务ID和名称
  • 要修改的文件（明确路径）
  • 验收标准（项目符号）
  • 依赖项（必须先完成的任务）
存储提取的任务信息用于子Agent提示（每个子Agent节省约1000个token）：
Task 4.2:
Name: Integrate prompts module into generator
Files: - src/generator.ts - src/types.ts
Acceptance Criteria: - Import PromptService from prompts module - Replace manual prompt construction with PromptService.getCommitPrompt() - Update tests to mock PromptService - All tests pass
Dependencies: Task 4.1 (fallback logic removed)
多仓库计划解析：
对于多仓库计划，还需从每个任务中提取
repo
字段：
Task 4.2:
Name: Integrate prompts module into generator
Repo: backend  # NEW - required in multi-repo mode
Files: - src/generator.ts - src/types.ts
Acceptance Criteria: - Import PromptService from prompts module - Replace manual prompt construction with PromptService.getCommitPrompt() - Update tests to mock PromptService - All tests pass
Dependencies: Task 4.1 (fallback logic removed)
将仓库信息传递给阶段执行Skill。
验证计划结构：
  • 包含具备明确策略的阶段
  • 所有任务都指定了文件
  • 所有任务都有验收标准
  • 依赖关系合理

Step 1.5: Validate Setup Commands (REQUIRED)

步骤1.5：验证初始化命令（必需）

Use the 
validating-setup-commands
skill:
This skill validates that CLAUDE.md defines required setup commands BEFORE creating worktrees. It provides clear error messages with examples if missing.
The skill will extract and return:
  • INSTALL_CMD
    - Required dependency installation command
  • POSTINSTALL_CMD
    - Optional post-install command (codegen, etc.)
Store these commands for use in dependency installation steps throughout execution.
使用
validating-setup-commands
Skill：
该Skill用于在创建worktree之前验证CLAUDE.md是否定义了必需的初始化命令。如果缺少命令，它会提供带有示例的清晰错误消息。
该Skill会提取并返回：
  • INSTALL_CMD
    - 必需的依赖安装命令
  • POSTINSTALL_CMD
    - 可选的安装后命令（如代码生成等）
存储这些命令以便在整个执行过程中的依赖安装步骤中使用。

Step 1.6: Detect Project Commands (Optional)

步骤1.6：检测项目命令（可选）

Optionally detect project-specific quality check commands for subagents to use.
This is optional - most projects define commands in CLAUDE.md that subagents can discover.
If you want to provide hints, check for common patterns:
  • TypeScript/JavaScript: 
    package.json
    scripts
  • Python: 
    pytest
    , 
    ruff
    , 
    black
  • Go: 
    go test
    , 
    golangci-lint
  • Rust: 
    cargo test
    , 
    cargo clippy
If detected, mention in subagent prompts:
  • TEST_CMD
    - Command to run tests
  • LINT_CMD
    - Command to run linting
  • FORMAT_CMD
    - Command to format code
  • BUILD_CMD
    - Command to build project
If not detected, subagents will check CLAUDE.md or skip quality checks with warning.
IMPORTANT: Do NOT read constitution files here. Let subagents read them as needed to reduce orchestrator token usage.
可选：检测项目特定的质量检查命令，供子Agent使用。
此步骤为可选——大多数项目会在CLAUDE.md中定义命令，子Agent可以自行发现。
如果要提供提示，请检查常见模式：
  • TypeScript/JavaScript：
    package.json
    脚本
  • Python：
    pytest
    , 
    ruff
    , 
    black
  • Go：
    go test
    , 
    golangci-lint
  • Rust：
    cargo test
    , 
    cargo clippy
如果检测到，在子Agent提示中提及：
  • TEST_CMD
    - 运行测试的命令
  • LINT_CMD
    - 运行代码检查的命令
  • FORMAT_CMD
    - 格式化代码的命令
  • BUILD_CMD
    - 构建项目的命令
如果未检测到，子Agent会检查CLAUDE.md或跳过质量检查并发出警告。
重要提示： 请勿在此处读取章程文件。让子Agent按需读取以减少编排器的token使用量。

Step 1.7: Configure Code Review Frequency

步骤1.7：配置代码审查频率

Determine when to run code reviews:
bash
undefined
确定何时运行代码审查：
bash
undefined

Check if REVIEW_FREQUENCY env var is set

Check if REVIEW_FREQUENCY env var is set

REVIEW_FREQUENCY=${REVIEW_FREQUENCY:-}

**If not set, prompt user for preference:**

If `REVIEW_FREQUENCY` is empty, use AskUserQuestion tool to prompt:
Question: "How frequently should code reviews run during execution?" Header: "Review Frequency" Options:
  1. "After each phase" Description: "Run code review after every phase completes (safest - catches errors early, prevents compounding issues)"
  2. "Optimize automatically" Description: "Let Claude decide when to review based on phase risk/complexity (RECOMMENDED - balances speed and quality)"
  3. "Only at end" Description: "Skip per-phase reviews, run one review after all phases complete (faster, but errors may compound)"
  4. "Skip reviews" Description: "No automated code reviews (fastest, but requires manual review before merging)"

**Store user choice:**
- Option 1 -> `REVIEW_FREQUENCY="per-phase"`
- Option 2 -> `REVIEW_FREQUENCY="optimize"`
- Option 3 -> `REVIEW_FREQUENCY="end-only"`
- Option 4 -> `REVIEW_FREQUENCY="skip"`

**Announce decision:**
Code review frequency: {REVIEW_FREQUENCY}

**Note:** This setting applies to all phases in this execution. Phase skills check `REVIEW_FREQUENCY` to determine whether to run code review step.
REVIEW_FREQUENCY=${REVIEW_FREQUENCY:-}

**如果未设置，提示用户选择偏好：**

如果`REVIEW_FREQUENCY`为空，使用AskUserQuestion工具提示：
Question: "How frequently should code reviews run during execution?" Header: "Review Frequency" Options:
  1. "After each phase" Description: "Run code review after every phase completes (safest - catches errors early, prevents compounding issues)"
  2. "Optimize automatically" Description: "Let Claude decide when to review based on phase risk/complexity (RECOMMENDED - balances speed and quality)"
  3. "Only at end" Description: "Skip per-phase reviews, run one review after all phases complete (faster, but errors may compound)"
  4. "Skip reviews" Description: "No automated code reviews (fastest, but requires manual review before merging)"

**存储用户选择：**
- 选项1 -> `REVIEW_FREQUENCY="per-phase"`
- 选项2 -> `REVIEW_FREQUENCY="optimize"`
- 选项3 -> `REVIEW_FREQUENCY="end-only"`
- 选项4 -> `REVIEW_FREQUENCY="skip"`

**声明决策：**
Code review frequency: {REVIEW_FREQUENCY}

**注意：** 此设置适用于本次执行的所有阶段。阶段Skill会检查`REVIEW_FREQUENCY`以确定是否运行代码审查步骤。

Step 2: Execute Phases

步骤2：执行阶段

If resuming: Start from the incomplete phase/task identified in Step 0.
For each phase in the plan, execute based on strategy:
Multi-repo phase execution:
When dispatching phase skills, include:
  • WORKSPACE_MODE
    : "multi-repo" or "single-repo"
  • WORKSPACE_ROOT
    : Absolute path to workspace
  • For each task: 
    TASK_REPO
    field from plan
Example dispatch context:
WORKSPACE_MODE: multi-repo
WORKSPACE_ROOT: /home/user/workspace
Phase 2 tasks:
- Task 2.1: repo=backend
- Task 2.2: repo=frontend
- Task 2.3: repo=frontend
Phase skills use this to:
  • Create worktrees in the correct repo
  • Read CLAUDE.md from the task's repo
  • Read constitution from the task's repo
Code Review Gates: Phase execution skills check 
REVIEW_FREQUENCY
(set in Step 1.7) to determine when to run code reviews:
  • per-phase
    : Review after each phase before proceeding
  • optimize
    : LLM decides whether to review based on phase risk/complexity
  • end-only
    : Skip per-phase reviews, review once after all phases
  • skip
    : No automated reviews (manual review required)
如果是恢复执行： 从步骤0中识别出的未完成阶段/任务开始。
对于计划中的每个阶段，根据策略执行：
多仓库阶段执行：
调度阶段Skill时，需包含：
  • WORKSPACE_MODE
    : "multi-repo"或"single-repo"
  • WORKSPACE_ROOT
    : 工作区的绝对路径
  • 每个任务的
    TASK_REPO
    字段（来自计划）
示例调度上下文：
WORKSPACE_MODE: multi-repo
WORKSPACE_ROOT: /home/user/workspace
Phase 2 tasks:
- Task 2.1: repo=backend
- Task 2.2: repo=frontend
- Task 2.3: repo=frontend
阶段Skill使用这些信息：
  • 在正确的仓库中创建worktree
  • 读取任务对应仓库的CLAUDE.md
  • 读取任务对应仓库的章程
代码审查关卡： 阶段执行Skill会检查步骤1.7中设置的
REVIEW_FREQUENCY
以确定何时运行代码审查：
  • per-phase
    : 每个阶段完成后、进入下一阶段前运行审查
  • optimize
    : 由LLM根据阶段风险/复杂性决定是否运行审查
  • end-only
    : 跳过每个阶段的审查，所有阶段完成后运行一次审查
  • skip
    : 不进行自动审查（需要手动审查）

Cross-Phase Stacking

跨阶段堆叠

Use the 
understanding-cross-phase-stacking
skill:
This skill explains how sequential and parallel phases automatically chain together through base branch inheritance. Key concepts:
  • Main worktree tracks progress (current branch = latest completed work)
  • Parallel phases inherit from current branch (not original base)
  • Natural chaining creates linear stack across all phases
Read this skill before starting any new phase to understand how phases build on each other.
使用
understanding-cross-phase-stacking
Skill：
该Skill解释了串行和并行阶段如何通过基础分支继承自动链接。核心概念：
  • 主worktree跟踪执行进度（当前分支=最新完成的工作）
  • 并行阶段从当前分支继承（而非原始基础分支）
  • 自然链接在所有阶段之间创建线性栈
在开始任何新阶段前，请阅读该Skill以了解阶段之间的构建关系。

Sequential Phase Strategy

串行阶段策略

Use the 
executing-sequential-phase
skill:
This skill provides the complete workflow for executing sequential phases. Key concepts:
  • Execute tasks one-by-one in existing 
    {runid}-main
    worktree
  • Trust natural git-spice stacking (no manual 
    gs upstack onto
    )
  • Tasks build on each other cumulatively
  • Stay on task branches for automatic stacking
The skill includes detailed subagent prompts, quality check sequences, and code review integration.
CRITICAL: When dispatching subagents, substitute 
{run-id}
and 
{feature-slug}
with the values extracted in Step 0a. Subagents need these to read the spec at 
specs/{run-id}-{feature-slug}/spec.md
.
使用
executing-sequential-phase
Skill：
该Skill提供了执行串行阶段的完整工作流。核心概念：
  • 在现有的
    {runid}-main
    worktree中逐个执行任务
  • 依赖git-spice的自然堆叠功能（无需手动执行
    gs upstack onto
    ）
  • 任务之间逐步累积构建
  • 停留在任务分支上以实现自动堆叠
该Skill包含详细的子Agent提示、质量检查序列和代码审查集成。
关键注意事项： 调度子Agent时，将步骤0a中提取的
{run-id}
和
{feature-slug}
替换为实际值。子Agent需要这些值来读取
specs/{run-id}-{feature-slug}/spec.md
路径下的规格文件。

Parallel Phase Strategy

并行阶段策略

Use the 
executing-parallel-phase
skill:
This skill provides the complete mandatory workflow for executing parallel phases. Key requirements:
  • Create isolated worktrees for EACH task (even N=1)
  • Install dependencies per worktree
  • Spawn parallel subagents in single message
  • Verify completion before stacking
  • Stack branches linearly, then cleanup worktrees
  • Code review after stacking
The skill includes the 8-step mandatory sequence, verification checks, N=1 edge case handling, and stacking algorithm.
CRITICAL: When dispatching subagents, substitute 
{run-id}
and 
{feature-slug}
with the values extracted in Step 0a. Subagents need these to read the spec at 
specs/{run-id}-{feature-slug}/spec.md
.
使用
executing-parallel-phase
Skill：
该Skill提供了执行并行阶段的完整强制工作流。核心要求：
  • 为每个任务创建独立的worktree（即使只有1个任务）
  • 为每个worktree安装依赖
  • 在单个消息中生成并行子Agent
  • 堆叠前验证完成状态
  • 线性堆叠分支，然后清理worktree
  • 堆叠后进行代码审查
该Skill包含8步强制序列、验证检查、N=1边缘情况处理和堆叠算法。
关键注意事项： 调度子Agent时，将步骤0a中提取的
{run-id}
和
{feature-slug}
替换为实际值。子Agent需要这些值来读取
specs/{run-id}-{feature-slug}/spec.md
路径下的规格文件。

Step 3: Verify Completion

步骤3：验证完成

After all phases execute successfully:
Use the 
verification-before-completion
skill:
This skill enforces verification BEFORE claiming work is done.
Required verifications (if commands detected):
bash
undefined
所有阶段成功执行后：
使用
verification-before-completion
Skill：
该Skill在声明工作完成前强制执行验证。
必需的验证（如果检测到命令）：
bash
undefined

Run full test suite

Run full test suite

if [ -n "$TEST_CMD" ]; then $TEST_CMD || { echo "Tests failed"; exit 1; } fi
if [ -n "$TEST_CMD" ]; then $TEST_CMD || { echo "Tests failed"; exit 1; } fi

Run linting

Run linting

if [ -n "$LINT_CMD" ]; then $LINT_CMD || { echo "Linting failed"; exit 1; } fi
if [ -n "$LINT_CMD" ]; then $LINT_CMD || { echo "Linting failed"; exit 1; } fi

Run production build

Run production build

if [ -n "$BUILD_CMD" ]; then $BUILD_CMD || { echo "Build failed"; exit 1; } fi
if [ -n "$BUILD_CMD" ]; then $BUILD_CMD || { echo "Build failed"; exit 1; } fi

Verify all detected checks passed

Verify all detected checks passed

echo "All quality checks passed - ready to complete"

**If no commands detected:**
Warning: No test/lint/build commands found in project. Add to CLAUDE.md or constitution/testing.md for automated quality gates. Proceeding without verification - manual review recommended.

**Critical:** Evidence before assertions. Never claim "tests pass" without running them.
echo "All quality checks passed - ready to complete"

**如果未检测到命令：**
Warning: No test/lint/build commands found in project. Add to CLAUDE.md or constitution/testing.md for automated quality gates. Proceeding without verification - manual review recommended.

**关键提示：** 先有证据再做断言。未运行测试前，绝不能声称"测试通过"。

Step 4: Finish Stack

步骤4：完成栈操作

After verification passes:
Use the 
finishing-a-development-branch
skill to:
  1. Review all changes
  2. Choose next action:
    • Submit stack as PRs: 
      gs stack submit
      (per using-git-spice skill)
    • Continue with dependent feature: 
      gs branch create
    • Mark complete and sync: 
      gs repo sync
验证通过后：
使用
finishing-a-development-branch
Skill来：
  1. 审查所有变更
  2. 选择下一步操作：
    • 提交栈作为PR：
      gs stack submit
      （参考using-git-spice Skill）
    • 继续开发依赖功能：
      gs branch create
    • 标记完成并同步：
      gs repo sync

Step 5: Final Report

步骤5：最终报告

Multi-repo final report:
markdown
Feature Implementation Complete

**RUN_ID**: {run-id}
**Feature**: {feature-name}
**Workspace Mode**: multi-repo
**Workspace Root**: {path}
多仓库最终报告：
markdown
Feature Implementation Complete

**RUN_ID**: {run-id}
**Feature**: {feature-name}
**Workspace Mode**: multi-repo
**Workspace Root**: {path}

Per-Repo Summary

Per-Repo Summary

RepoTasksBranchesStatus
backend44Complete
frontend33Complete
shared-lib11Complete
RepoTasksBranchesStatus
backend44Complete
frontend33Complete
shared-lib11Complete

Branch Stacks (per-repo)

Branch Stacks (per-repo)

backend:
  • {runId}-task-1-1-database
  • {runId}-task-2-1-api
frontend:
  • {runId}-task-2-2-hook
  • {runId}-task-2-3-ui
backend:
  • {runId}-task-1-1-database
  • {runId}-task-2-1-api
frontend:
  • {runId}-task-2-2-hook
  • {runId}-task-2-3-ui

Next Steps

Next Steps

Submit PRs (per-repo)

Submit PRs (per-repo)

bash
cd backend && gs stack submit
cd ../frontend && gs stack submit

**Single-repo final report:**

```markdown
Feature Implementation Complete

**RUN_ID**: {run-id}
**Feature**: {feature-name}
**Worktree**: .worktrees/{run-id}-main/
**Stack**: {count} task branches (all stacked on {run-id}-main)
bash
cd backend && gs stack submit
cd ../frontend && gs stack submit

**单仓库最终报告：**

```markdown
Feature Implementation Complete

**RUN_ID**: {run-id}
**Feature**: {feature-name}
**Worktree**: .worktrees/{run-id}-main/
**Stack**: {count} task branches (all stacked on {run-id}-main)

Execution Summary

Execution Summary

Phases Completed: {count}
  • Sequential: {count} phases
  • Parallel: {count} phases
Tasks Completed: {count} Commits: {count}
Isolation: All work completed in worktree. Main repo unchanged.
Phases Completed: {count}
  • Sequential: {count} phases
  • Parallel: {count} phases
Tasks Completed: {count} Commits: {count}
Isolation: All work completed in worktree. Main repo unchanged.

Parallelization Results

Parallelization Results

{For each parallel phase:} Phase {id}: {task-count} tasks in parallel
  • Estimated sequential time: {hours}h
  • Actual parallel time: {hours}h
  • Time saved: {hours}h
Total Time Saved: {hours}h ({percent}%)
{For each parallel phase:} Phase {id}: {task-count} tasks in parallel
  • Estimated sequential time: {hours}h
  • Actual parallel time: {hours}h
  • Time saved: {hours}h
Total Time Saved: {hours}h ({percent}%)

Quality Checks

Quality Checks

Quality checks are project-specific (detected from CLAUDE.md, constitution, or common patterns):
  • Tests passing (if 
    TEST_CMD
    detected)
  • Linting clean (if 
    LINT_CMD
    detected)
  • Formatting applied (if 
    FORMAT_CMD
    detected)
  • Build successful (if 
    BUILD_CMD
    detected)
If no commands detected, quality gates are skipped with warning to user.
  • {total-commits} commits across {branch-count} task branches
Quality checks are project-specific (detected from CLAUDE.md, constitution, or common patterns):
  • Tests passing (if 
    TEST_CMD
    detected)
  • Linting clean (if 
    LINT_CMD
    detected)
  • Formatting applied (if 
    FORMAT_CMD
    detected)
  • Build successful (if 
    BUILD_CMD
    detected)
If no commands detected, quality gates are skipped with warning to user.
  • {total-commits} commits across {branch-count} task branches

Next Steps

Next Steps

Review Changes (from main repo)

Review Changes (from main repo)

bash
undefined
bash
undefined

All these commands work from main repo root

All these commands work from main repo root

gs log short # View all branches and commits in stack gs log long # Detailed view with commit messages git branch | grep "^ {run-id}-" # List all branches for this run
gs log short # View all branches and commits in stack gs log long # Detailed view with commit messages git branch | grep "^ {run-id}-" # List all branches for this run

To see changes in worktree:

To see changes in worktree:

cd .worktrees/{run-id}-main git diff main..HEAD # See all changes in current stack cd ../.. # Return to main repo
undefined
cd .worktrees/{run-id}-main git diff main..HEAD # See all changes in current stack cd ../.. # Return to main repo
undefined

Submit for Review (from main repo)

Submit for Review (from main repo)

bash
undefined
bash
undefined

git-spice commands work from main repo

git-spice commands work from main repo

gs stack submit # Submits entire stack as PRs (per using-git-spice skill)
undefined
gs stack submit # Submits entire stack as PRs (per using-git-spice skill)
undefined

Or Continue with Dependent Feature (from worktree)

Or Continue with Dependent Feature (from worktree)

bash
cd .worktrees/{run-id}-main       # Navigate to worktree
gs branch create  # Creates new branch stacked on current
cd ../..                          # Return to main repo when done
bash
cd .worktrees/{run-id}-main       # Navigate to worktree
gs branch create  # Creates new branch stacked on current
cd ../..                          # Return to main repo when done

Cleanup Worktree (after PRs merged)

Cleanup Worktree (after PRs merged)

bash
undefined
bash
undefined

From main repo root:

From main repo root:

git worktree remove .worktrees/{run-id}-main
git worktree remove .worktrees/{run-id}-main

Optional: Delete the {run-id}-main branch

Optional: Delete the {run-id}-main branch

git branch -d {run-id}-main

**Important**: Main repo remains unchanged. All work is in the worktree and task branches.
git branch -d {run-id}-main

**Important**: Main repo remains unchanged. All work is in the worktree and task branches.

Error Handling

错误处理

Use the 
troubleshooting-execute
skill:
This skill provides comprehensive diagnostic and recovery strategies for execute command failures:
  • Phase execution failures (sequential and parallel)
  • Parallel agent failures with 4 recovery options
  • Merge conflicts during stacking
  • Worktree not found errors
  • Parallel task worktree creation failures
The skill includes diagnostic commands, recovery strategies, and prevention guidelines.
Consult this skill when execution fails or produces unexpected results.
使用
troubleshooting-execute
Skill：
该Skill为execute命令失败提供全面的诊断和恢复策略：
  • 阶段执行失败（串行和并行）
  • 并行Agent失败的4种恢复选项
  • 堆叠期间的合并冲突
  • Worktree未找到错误
  • 并行任务worktree创建失败
该Skill包含诊断命令、恢复策略和预防指南。
当执行失败或产生意外结果时，请参考该Skill。

Important Notes

重要注意事项

  • Orchestrator delegates, never executes - The orchestrator NEVER runs git commands directly. All git operations are delegated to subagents (setup, implementation, cleanup)
  • Subagents own their git operations - Implementation subagents create branches and commit their own work using 
    gs branch create -m
  • Skill-driven execution - Uses using-git-spice, using-git-worktrees, and other superpowers skills
  • Automatic orchestration - Reads plan strategies, executes accordingly
  • Git-spice stacking - Sequential tasks stack linearly; parallel tasks branch from same base (per using-git-spice skill)
  • No feature branch - The stack of task branches IS the feature; never create empty branch upfront
  • Worktree isolation - Parallel tasks run in separate worktrees (per using-git-worktrees skill)
  • Critical: HEAD detachment - Parallel task subagents MUST detach HEAD after creating branches to make them accessible in parent repo
  • Context management - Each task runs in isolated subagent to avoid token bloat
  • Constitution adherence - All agents follow project constitution (@docs/constitutions/current/)
  • Quality gates - Tests and linting after every task, code review after every phase
  • Continuous commits - Small, focused commits with [Task X.Y] markers throughout
Now execute the plan from: {plan-path}
  • 编排器仅调度，不执行 - 编排器从不直接运行Git命令。所有Git操作都委托给子Agent（初始化、实施、清理）
  • 子Agent负责自身Git操作 - 实施子Agent使用
    gs branch create -m
    创建分支并提交自己的工作
  • Skill驱动的执行 - 使用using-git-spice、using-git-worktrees和其他超级能力Skill
  • 自动编排 - 读取计划策略，相应执行
  • Git-spice堆叠 - 串行任务线性堆叠；并行任务从同一基础分支分叉（参考using-git-spice Skill）
  • 无功能分支 - 任务分支的栈就是功能本身；绝不要提前创建空分支
  • Worktree隔离 - 并行任务在独立的worktree中运行（参考using-git-worktrees Skill）
  • 关键提示：HEAD分离 - 并行任务子Agent必须在创建分支后分离HEAD，以便在父仓库中访问这些分支
  • 上下文管理 - 每个任务在独立的子Agent中运行以避免token膨胀
  • 遵守章程 - 所有Agent遵循项目章程（@docs/constitutions/current/）
  • 质量关卡 - 每个任务完成后运行测试和代码检查，每个阶段完成后进行代码审查
  • 持续提交 - 整个过程中进行小型、聚焦的提交，并标记[Task X.Y]
现在从以下路径执行计划：{plan-path}