kata-execute-phase

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<objective> Execute all plans in a phase using wave-based parallel execution.
Orchestrator stays lean: discover plans, analyze dependencies, group into waves, spawn subagents, collect results. Each subagent loads the full execute-plan context and handles its own plan.
Context budget: ~15% orchestrator, 100% fresh per subagent. </objective>
<execution_context> @./references/ui-brand.md @./references/planning-config.md @./references/phase-execute.md </execution_context>
<context> Phase: $ARGUMENTS
Flags:
  • --gaps-only
    — Execute only gap closure plans (plans with
    gap_closure: true
    in frontmatter). Use after phase-verify creates fix plans.
@.planning/ROADMAP.md @.planning/STATE.md </context>
<process> 0. **Resolve Model Profile**
Read model profile for agent spawning:
bash
MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
Default to "balanced" if not set.
Model lookup table:
Agentqualitybalancedbudget
general-purpose (executor)opussonnetsonnet
kata-verifiersonnetsonnethaiku
kata-code-revieweropussonnetsonnet
kata-*-analyzersonnetsonnethaiku
Note: Review agents (kata-code-reviewer, kata--analyzer) are spawned by the kata-review-pull-requests skill, which handles its own model selection based on the agents' frontmatter. The table above documents expected model usage for cost planning.*
Store resolved models for use in Task calls below.
  1. Validate phase exists Find phase directory using the discovery script:
    bash
    bash "${SKILL_BASE_DIR}/scripts/find-phase.sh" "$PHASE_ARG"
    Outputs
    PHASE_DIR
    ,
    PLAN_COUNT
    , and
    PHASE_STATE
    as key=value pairs. Exit code 1 = not found, 2 = no plans. Parse the output to set these variables for subsequent steps.
1.25. Move phase to active (state transition)
bash
# Move from pending to active when execution begins
# PHASE_STATE is from find-phase.sh output (step 1)
if [ "$PHASE_STATE" = "pending" ]; then
  DIR_NAME=$(basename "$PHASE_DIR")
  mkdir -p ".planning/phases/active"
  mv "$PHASE_DIR" ".planning/phases/active/${DIR_NAME}"
  PHASE_DIR=".planning/phases/active/${DIR_NAME}"
  echo "Phase moved to active/"
fi
1.5. Create Phase Branch (pr_workflow only)
Read pr_workflow config:
bash
PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
If PR_WORKFLOW=false: Skip to step 2.
If PR_WORKFLOW=true:
  1. Get milestone version from ROADMAP.md:
    bash
    MILESTONE=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
  2. Get phase number and slug from PHASE_DIR:
    bash
    PHASE_NUM=$(basename "$PHASE_DIR" | sed -E 's/^([0-9]+)-.*/\1/')
    SLUG=$(basename "$PHASE_DIR" | sed -E 's/^[0-9]+-//')
  3. Infer branch type from phase goal (feat/fix/docs/refactor/chore, default feat):
    bash
    PHASE_GOAL=$(grep -A 5 "Phase ${PHASE_NUM}:" .planning/ROADMAP.md | grep "Goal:" | head -1 || echo "")
    if echo "$PHASE_GOAL" | grep -qi "fix\|bug\|patch"; then
      BRANCH_TYPE="fix"
    elif echo "$PHASE_GOAL" | grep -qi "doc\|readme\|comment"; then
      BRANCH_TYPE="docs"
    elif echo "$PHASE_GOAL" | grep -qi "refactor\|restructure\|reorganize"; then
      BRANCH_TYPE="refactor"
    elif echo "$PHASE_GOAL" | grep -qi "chore\|config\|setup"; then
      BRANCH_TYPE="chore"
    else
      BRANCH_TYPE="feat"
    fi
  4. Create branch with re-run protection:
    bash
    BRANCH="${BRANCH_TYPE}/v${MILESTONE}-${PHASE_NUM}-${SLUG}"
    if git show-ref --verify --quiet refs/heads/"$BRANCH"; then
      git checkout "$BRANCH"
      echo "Branch $BRANCH exists, resuming on it"
    else
      git checkout -b "$BRANCH"
      echo "Created branch $BRANCH"
    fi
Store BRANCH variable for use in step 4.5 and step 10.5.
  1. Discover plans
    • List all *-PLAN.md files in phase directory
    • Check which have *-SUMMARY.md (already complete)
    • If
      --gaps-only
      : filter to only plans with
      gap_closure: true
    • Build list of incomplete plans
  2. Group by wave
    • Read
      wave
      from each plan's frontmatter
    • Group plans by wave number
3.5. Display execution banner
Display stage banner and wave structure:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► EXECUTING PHASE {X}: {Phase Name} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
{N} plans, {M} waves:
WavePlansDescription
101, 02{plan names from frontmatter}
203{plan name}
Model profile: {profile} (executor → {model})
  1. Execute waves For each wave in order:
    • Spawn
      general-purpose
      executor for each plan in wave (parallel Task calls)
    • Wait for completion (Task blocks)
    • Verify SUMMARYs created
    • Update GitHub issue checkboxes (if enabled):
      Build COMPLETED_PLANS_IN_WAVE from SUMMARY.md files created this wave:
      bash
      # Get plan numbers from SUMMARYs that exist after this wave
      COMPLETED_PLANS_IN_WAVE=""
      for summary in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-SUMMARY.md" 2>/dev/null); do
        # Extract plan number from filename (e.g., 04-01-SUMMARY.md -> 01)
        plan_num=$(basename "$summary" | sed -E 's/^[0-9]+-([0-9]+)-SUMMARY\.md$/\1/')
        # Check if this plan was in the current wave (from frontmatter we read earlier)
        if echo "${WAVE_PLANS}" | grep -q "plan-${plan_num}"; then
          COMPLETED_PLANS_IN_WAVE="${COMPLETED_PLANS_IN_WAVE} ${plan_num}"
        fi
      done
      Check github.enabled and issueMode:
      bash
      GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
      ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
      If
      GITHUB_ENABLED != true
      OR
      ISSUE_MODE = never
      :
      Skip GitHub update.
      Otherwise:
      1. Find phase issue number:
      bash
      VERSION=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
      ISSUE_NUMBER=$(gh issue list \
        --label "phase" \
        --milestone "v${VERSION}" \
        --json number,title \
        --jq ".[] | select(.title | startswith(\"Phase ${PHASE}:\")) | .number" \
        2>/dev/null)
      If issue not found: Warn and skip (non-blocking).
      1. Read current issue body:
      bash
      ISSUE_BODY=$(gh issue view "$ISSUE_NUMBER" --json body --jq '.body' 2>/dev/null)
      1. For each completed plan in this wave, update checkbox:
      bash
      for plan_num in ${COMPLETED_PLANS_IN_WAVE}; do
        # Format: Plan 01, Plan 02, etc.
        PLAN_ID="Plan $(printf "%02d" $plan_num):"
        # Update checkbox: - [ ] -> - [x]
        ISSUE_BODY=$(echo "$ISSUE_BODY" | sed "s/^- \[ \] ${PLAN_ID}/- [x] ${PLAN_ID}/")
      done
      1. Write and update:
      bash
      printf '%s\n' "$ISSUE_BODY" > /tmp/phase-issue-body.md
      gh issue edit "$ISSUE_NUMBER" --body-file /tmp/phase-issue-body.md 2>/dev/null \
        && echo "Updated issue #${ISSUE_NUMBER}: checked off Wave ${WAVE_NUM} plans" \
        || echo "Warning: Failed to update issue #${ISSUE_NUMBER}"
      This update happens ONCE per wave (after all plans in wave complete), not per-plan, avoiding race conditions.
    • Open Draft PR (first wave only, pr_workflow only):
      After first wave completion (orchestrator provides PHASE_ARG):
      bash
      # Re-read config (bash blocks don't share state)
      PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
      GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | head -1 | grep -o 'true\|false' || echo "false")
      ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
      MILESTONE=$(grep -E "^\- \[.\] \*\*Phase|^### v" .planning/ROADMAP.md | grep -E "In Progress" | grep -oE "v[0-9]+\.[0-9]+(\.[0-9]+)?" | head -1 | tr -d 'v')
      [ -z "$MILESTONE" ] && MILESTONE=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
      # PHASE_DIR already set by universal discovery in step 1
      PHASE_NUM=$(basename "$PHASE_DIR" | sed -E 's/^([0-9]+)-.*/\1/')
      BRANCH=$(git branch --show-current)
      
      if [ "$PR_WORKFLOW" = "true" ]; then
        # Check if PR already exists (re-run protection - also handles wave > 1)
        EXISTING_PR=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number' 2>/dev/null)
        if [ -n "$EXISTING_PR" ]; then
          echo "PR #${EXISTING_PR} already exists, skipping creation"
          PR_NUMBER="$EXISTING_PR"
        else
          # Push branch and create draft PR
          git push -u origin "$BRANCH"
      
          # Get phase name from ROADMAP.md (format: #### Phase N: Name)
          PHASE_NAME=$(grep -E "^#### Phase ${PHASE_NUM}:" .planning/ROADMAP.md | sed -E 's/^#### Phase [0-9]+: //' | xargs)
      
          # Build PR body (Goal is on next line after phase header)
          PHASE_GOAL=$(grep -A 3 "^#### Phase ${PHASE_NUM}:" .planning/ROADMAP.md | grep "Goal:" | sed 's/.*Goal:[[:space:]]*//')
      
          # Get phase issue number for linking (if github.enabled)
          CLOSES_LINE=""
          if [ "$GITHUB_ENABLED" = "true" ] && [ "$ISSUE_MODE" != "never" ]; then
            PHASE_ISSUE=$(gh issue list --label phase --milestone "v${MILESTONE}" \
              --json number,title --jq ".[] | select(.title | startswith(\"Phase ${PHASE_NUM}:\")) | .number" 2>/dev/null)
            [ -n "$PHASE_ISSUE" ] && CLOSES_LINE="Closes #${PHASE_ISSUE}"
            # Store PHASE_ISSUE for use in step 10.6 merge path
          fi
      
          # Build plans checklist (all unchecked initially)
          PLANS_CHECKLIST=""
          for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
            plan_name=$(grep -m1 "<name>" "$plan" | sed 's/.*<name>//;s/<\/name>.*//' || basename "$plan" | sed 's/-PLAN.md//')
            plan_num=$(basename "$plan" | sed -E 's/^[0-9]+-([0-9]+)-PLAN\.md$/\1/')
            PLANS_CHECKLIST="${PLANS_CHECKLIST}- [ ] Plan ${plan_num}: ${plan_name}\n"
          done
      
          # Collect source_issue references from all plans
          SOURCE_ISSUES=""
          for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
            source_issue=$(grep -m1 "^source_issue:" "$plan" | cut -d':' -f2- | xargs)
            if echo "$source_issue" | grep -q "^github:#"; then
              issue_num=$(echo "$source_issue" | grep -oE '#[0-9]+')
              [ -n "$issue_num" ] && SOURCE_ISSUES="${SOURCE_ISSUES}Closes ${issue_num}\n"
            fi
          done
          SOURCE_ISSUES=$(echo "$SOURCE_ISSUES" | sed '/^$/d')  # Remove empty lines
      
          cat > /tmp/pr-body.md << PR_EOF
<objective> 采用波浪式并行执行方式执行一个阶段中的所有计划。
编排器(Orchestrator)保持轻量化:发现计划、分析依赖关系、按波浪分组、生成子代理(subagents)、收集结果。每个子代理加载完整的执行计划上下文并处理自己的计划。
上下文预算:编排器占用约15%,每个子代理使用全新的100%上下文。 </objective>
<execution_context> @./references/ui-brand.md @./references/planning-config.md @./references/phase-execute.md </execution_context>
<context> 阶段:$ARGUMENTS
参数:
  • --gaps-only
    — 仅执行缺口修复计划(即前置元数据中包含
    gap_closure: true
    的计划)。在phase-verify生成修复计划后使用。
@.planning/ROADMAP.md @.planning/STATE.md </context>
<process> 0. **解析模型配置文件**
读取用于生成代理的模型配置文件:
bash
MODEL_PROFILE=$(cat .planning/config.json 2>/dev/null | grep -o '"model_profile"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "balanced")
如果未设置,默认使用“balanced”。
模型查找表:
代理类型qualitybalancedbudget
general-purpose (executor)opussonnetsonnet
kata-verifiersonnetsonnethaiku
kata-code-revieweropussonnetsonnet
kata-*-analyzersonnetsonnethaiku
注意:审核类代理(kata-code-reviewer、kata--analyzer)由kata-review-pull-requests技能生成,该技能会根据代理的前置元数据自行选择模型。以上表格记录了成本规划中预期的模型使用情况。*
存储解析后的模型,供后续Task调用使用。
  1. 验证阶段是否存在 使用发现脚本查找阶段目录:
    bash
    bash "${SKILL_BASE_DIR}/scripts/find-phase.sh" "$PHASE_ARG"
    输出
    PHASE_DIR
    PLAN_COUNT
    PHASE_STATE
    的键值对。退出码1表示未找到,2表示无计划。解析输出结果,为后续步骤设置这些变量。
1.25. 将阶段移至活跃状态(状态转换)
bash
# 执行开始时,从未处理状态移至活跃状态
# PHASE_STATE来自步骤1中find-phase.sh的输出
if [ "$PHASE_STATE" = "pending" ]; then
  DIR_NAME=$(basename "$PHASE_DIR")
  mkdir -p ".planning/phases/active"
  mv "$PHASE_DIR" ".planning/phases/active/${DIR_NAME}"
  PHASE_DIR=".planning/phases/active/${DIR_NAME}"
  echo "阶段已移至active/目录"
fi
1.5. 创建阶段分支(仅pr_workflow模式)
读取pr_workflow配置:
bash
PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
如果PR_WORKFLOW=false: 跳至步骤2。
如果PR_WORKFLOW=true:
  1. 从ROADMAP.md获取里程碑版本:
    bash
    MILESTONE=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
  2. 从PHASE_DIR获取阶段编号和别名:
    bash
    PHASE_NUM=$(basename "$PHASE_DIR" | sed -E 's/^([0-9]+)-.*/\1/')
    SLUG=$(basename "$PHASE_DIR" | sed -E 's/^[0-9]+-//')
  3. 根据阶段目标推断分支类型(feat/fix/docs/refactor/chore,默认feat):
    bash
    PHASE_GOAL=$(grep -A 5 "Phase ${PHASE_NUM}:" .planning/ROADMAP.md | grep "Goal:" | head -1 || echo "")
    if echo "$PHASE_GOAL" | grep -qi "fix\|bug\|patch"; then
      BRANCH_TYPE="fix"
    elif echo "$PHASE_GOAL" | grep -qi "doc\|readme\|comment"; then
      BRANCH_TYPE="docs"
    elif echo "$PHASE_GOAL" | grep -qi "refactor\|restructure\|reorganize"; then
      BRANCH_TYPE="refactor"
    elif echo "$PHASE_GOAL" | grep -qi "chore\|config\|setup"; then
      BRANCH_TYPE="chore"
    else
      BRANCH_TYPE="feat"
    fi
  4. 创建分支并支持重运行保护:
    bash
    BRANCH="${BRANCH_TYPE}/v${MILESTONE}-${PHASE_NUM}-${SLUG}"
    if git show-ref --verify --quiet refs/heads/"$BRANCH"; then
      git checkout "$BRANCH"
      echo "分支$BRANCH已存在,将在该分支上继续执行"
    else
      git checkout -b "$BRANCH"
      echo "已创建分支$BRANCH"
    fi
存储BRANCH变量,供步骤4.5和10.5使用。
  1. 发现计划
    • 列出阶段目录下所有*-PLAN.md文件
    • 检查哪些文件已有对应的*-SUMMARY.md(表示已完成)
    • 如果使用
      --gaps-only
      :仅筛选出
      gap_closure: true
      的计划
    • 构建未完成计划列表
  2. 按波浪分组
    • 读取每个计划前置元数据中的
      wave
      字段
    • 按波浪编号对计划进行分组
3.5. 显示执行横幅
显示阶段横幅和波浪结构:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 正在执行阶段 {X}: {阶段名称} ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
{N} 个计划,{M} 个波浪:
波浪编号计划描述
101, 02{来自前置元数据的计划名称}
203{计划名称}
模型配置: {profile}(执行器 → {model})
  1. 执行波浪计划 按顺序处理每个波浪:
    • 为波浪中的每个计划生成
      general-purpose
      执行器(并行Task调用)
    • 等待所有任务完成(Task会阻塞直到完成)
    • 验证是否已生成SUMMARY文件
    • 更新GitHub议题复选框(如果已启用):
      从本波浪生成的SUMMARY.md文件中构建COMPLETED_PLANS_IN_WAVE:
      bash
      # 获取本波浪完成后已存在的SUMMARY文件对应的计划编号
      COMPLETED_PLANS_IN_WAVE=""
      for summary in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-SUMMARY.md" 2>/dev/null); do
        # 从文件名中提取计划编号(例如:04-01-SUMMARY.md → 01)
        plan_num=$(basename "$summary" | sed -E 's/^[0-9]+-([0-9]+)-SUMMARY\.md$/\1/')
        # 检查该计划是否属于当前波浪(基于之前读取的前置元数据)
        if echo "${WAVE_PLANS}" | grep -q "plan-${plan_num}"; then
          COMPLETED_PLANS_IN_WAVE="${COMPLETED_PLANS_IN_WAVE} ${plan_num}"
        fi
      done
      检查github.enabled和issueMode配置:
      bash
      GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
      ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
      如果
      GITHUB_ENABLED != true
      ISSUE_MODE = never
      跳过GitHub更新。
      否则:
      1. 查找阶段对应的议题编号:
      bash
      VERSION=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
      ISSUE_NUMBER=$(gh issue list \
        --label "phase" \
        --milestone "v${VERSION}" \
        --json number,title \
        --jq ".[] | select(.title | startswith(\"Phase ${PHASE}:\")) | .number" \
        2>/dev/null)
      如果未找到议题:发出警告并跳过(不阻塞流程)。
      1. 读取当前议题内容:
      bash
      ISSUE_BODY=$(gh issue view "$ISSUE_NUMBER" --json body --jq '.body' 2>/dev/null)
      1. 对本波浪中每个已完成的计划,更新复选框:
      bash
      for plan_num in ${COMPLETED_PLANS_IN_WAVE}; do
        # 格式:Plan 01, Plan 02等
        PLAN_ID="Plan $(printf "%02d" $plan_num):"
        # 更新复选框:- [ ] -> - [x]
        ISSUE_BODY=$(echo "$ISSUE_BODY" | sed "s/^- \[ \] ${PLAN_ID}/- [x] ${PLAN_ID}/")
      done
      1. 写入并更新议题:
      bash
      printf '%s\n' "$ISSUE_BODY" > /tmp/phase-issue-body.md
      gh issue edit "$ISSUE_NUMBER" --body-file /tmp/phase-issue-body.md 2>/dev/null \
        && echo "已更新议题#${ISSUE_NUMBER}:标记完成波浪${WAVE_NUM}的计划" \
        || echo "警告:更新议题#${ISSUE_NUMBER}失败"
      此更新在每个波浪完成后执行一次(而非每个计划完成后),避免竞争条件。
    • 创建草稿PR(仅第一个波浪,仅pr_workflow模式):
      第一个波浪完成后(编排器提供PHASE_ARG):
      bash
      # 重新读取配置(bash块不共享状态)
      PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
      GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | head -1 | grep -o 'true\|false' || echo "false")
      ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
      MILESTONE=$(grep -E "^\- \[.\] \*\*Phase|^### v" .planning/ROADMAP.md | grep -E "In Progress" | grep -oE "v[0-9]+\.[0-9]+(\.[0-9]+)?" | head -1 | tr -d 'v')
      [ -z "$MILESTONE" ] && MILESTONE=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v')
      # PHASE_DIR已由步骤1中的通用发现流程设置
      PHASE_NUM=$(basename "$PHASE_DIR" | sed -E 's/^([0-9]+)-.*/\1/')
      BRANCH=$(git branch --show-current)
      
      if [ "$PR_WORKFLOW" = "true" ]; then
        # 检查PR是否已存在(重运行保护 - 也适用于波浪>1的情况)
        EXISTING_PR=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number' 2>/dev/null)
        if [ -n "$EXISTING_PR" ]; then
          echo "PR #${EXISTING_PR}已存在,跳过创建"
          PR_NUMBER="$EXISTING_PR"
        else
          # 推送分支并创建草稿PR
          git push -u origin "$BRANCH"
      
          # 从ROADMAP.md获取阶段名称(格式:#### Phase N: 名称)
          PHASE_NAME=$(grep -E "^#### Phase ${PHASE_NUM}:" .planning/ROADMAP.md | sed -E 's/^#### Phase [0-9]+: //' | xargs)
      
          # 构建PR内容(目标在阶段标题的下一行)
          PHASE_GOAL=$(grep -A 3 "^#### Phase ${PHASE_NUM}:" .planning/ROADMAP.md | grep "Goal:" | sed 's/.*Goal:[[:space:]]*//')
      
          # 获取用于关联的阶段议题编号(如果github.enabled为true)
          CLOSES_LINE=""
          if [ "$GITHUB_ENABLED" = "true" ] && [ "$ISSUE_MODE" != "never" ]; then
            PHASE_ISSUE=$(gh issue list --label phase --milestone "v${MILESTONE}" \
              --json number,title --jq ".[] | select(.title | startswith(\"Phase ${PHASE_NUM}:\")) | .number" 2>/dev/null)
            [ -n "$PHASE_ISSUE" ] && CLOSES_LINE="Closes #${PHASE_ISSUE}"
            # 存储PHASE_ISSUE供步骤10.6的合并流程使用
          fi
      
          # 构建计划复选列表(初始均为未勾选)
          PLANS_CHECKLIST=""
          for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
            plan_name=$(grep -m1 "<name>" "$plan" | sed 's/.*<name>//;s/<\/name>.*//' || basename "$plan" | sed 's/-PLAN.md//')
            plan_num=$(basename "$plan" | sed -E 's/^[0-9]+-([0-9]+)-PLAN\.md$/\1/')
            PLANS_CHECKLIST="${PLANS_CHECKLIST}- [ ] Plan ${plan_num}: ${plan_name}\n"
          done
      
          # 收集所有计划中的source_issue引用
          SOURCE_ISSUES=""
          for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
            source_issue=$(grep -m1 "^source_issue:" "$plan" | cut -d':' -f2- | xargs)
            if echo "$source_issue" | grep -q "^github:#"; then
              issue_num=$(echo "$source_issue" | grep -oE '#[0-9]+')
              [ -n "$issue_num" ] && SOURCE_ISSUES="${SOURCE_ISSUES}Closes ${issue_num}\n"
            fi
          done
          SOURCE_ISSUES=$(echo "$SOURCE_ISSUES" | sed '/^$/d')  # 移除空行
      
          cat > /tmp/pr-body.md << PR_EOF

Phase Goal

阶段目标

${PHASE_GOAL}
${PHASE_GOAL}

Plans

计划列表

${PLANS_CHECKLIST} ${CLOSES_LINE} ${SOURCE_ISSUES:+
${PLANS_CHECKLIST} ${CLOSES_LINE} ${SOURCE_ISSUES:+

Source Issues

源议题

${SOURCE_ISSUES}} PR_EOF
     # Create draft PR
     gh pr create --draft \
       --base main \
       --title "v${MILESTONE} Phase ${PHASE_NUM}: ${PHASE_NAME}" \
       --body-file /tmp/pr-body.md

     PR_NUMBER=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number')
     echo "Created draft PR #${PR_NUMBER}"
   fi
 fi
 ```

 Store PR_NUMBER for step 10.5.

 **Note:** PR body checklist items remain unchecked throughout execution. The PR body is static after creation — it does NOT update as plans complete. The GitHub issue (updated after each wave above) is the source of truth for plan progress during execution.
  • Proceed to next wave
  1. Aggregate results
    • Collect summaries from all plans
    • Report phase completion status
  2. Commit any orchestrator corrections Check for uncommitted changes before verification:
    bash
    git status --porcelain
    If changes exist: Orchestrator made corrections between executor completions. Commit them:
    bash
    git add -u && git commit -m "fix({phase}): orchestrator corrections"
    If clean: Continue to test suite.
6.5. Run project test suite
Before verification, run the project's test suite to catch regressions early:
bash
TEST_SCRIPT=$(cat package.json 2>/dev/null | grep -o '"test"[[:space:]]*:[[:space:]]*"[^"]*"' | head -1)
If package.json has a test script:
  • Run
    npm test
  • If tests pass: proceed to step 7
  • If tests fail: report test failures, still proceed to step 7
If no test script detected:
  • Skip this step, proceed to step 7
Skip for gap phases: If mode is
gap_closure
, skip test suite
  1. Verify phase goal Check config:
    WORKFLOW_VERIFIER=$(cat .planning/config.json 2>/dev/null | grep -o '"verifier"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")
    If
    workflow.verifier
    is
    false
    :
    Skip to step 8 (treat as passed).
    Otherwise:
    • Spawn
      kata-verifier
      subagent with phase directory and goal
    • Verifier checks must_haves against actual codebase (not SUMMARY claims)
    • Creates VERIFICATION.md with detailed report
    • Route by status:
      • passed
        → continue to step 8
      • human_needed
        → present items, get approval or feedback
      • gaps_found
        → present gaps, offer
        /kata-plan-phase {X} --gaps
7.5. Validate completion and move to completed
After verification passes, validate completion artifacts before moving phase to completed:
bash
# Validate completion artifacts
PLAN_COUNT=$(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null | wc -l | tr -d ' ')
MISSING=""
if [ "$PLAN_COUNT" -eq 0 ]; then
  MISSING="${MISSING}\n- No PLAN.md files found"
fi
for plan in $(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
  plan_id=$(basename "$plan" | sed 's/-PLAN\.md$//')
  [ ! -f "$PHASE_DIR/${plan_id}-SUMMARY.md" ] && MISSING="${MISSING}\n- Missing SUMMARY.md for ${plan_id}"
done
# Non-gap phases require VERIFICATION.md
IS_GAP=$(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" -exec grep -l "gap_closure: true" {} + 2>/dev/null | head -1)
if [ -z "$IS_GAP" ] && ! find "$PHASE_DIR" -maxdepth 1 -name "*-VERIFICATION.md" 2>/dev/null | grep -q .; then
  MISSING="${MISSING}\n- Missing VERIFICATION.md (required for non-gap phases)"
fi

if [ -z "$MISSING" ]; then
  DIR_NAME=$(basename "$PHASE_DIR")
  mkdir -p ".planning/phases/completed"
  mv "$PHASE_DIR" ".planning/phases/completed/${DIR_NAME}"
  PHASE_DIR=".planning/phases/completed/${DIR_NAME}"
  echo "Phase validated and moved to completed/"
else
  echo "Warning: Phase incomplete:${MISSING}"
fi
  1. Update roadmap and state
    • Update ROADMAP.md, STATE.md
  2. Update requirements Mark phase requirements as Complete:
    • Read ROADMAP.md, find this phase's
      Requirements:
      line (e.g., "AUTH-01, AUTH-02")
    • Read REQUIREMENTS.md traceability table
    • For each REQ-ID in this phase: change Status from "Pending" to "Complete"
    • Write updated REQUIREMENTS.md
    • Skip if: REQUIREMENTS.md doesn't exist, or phase has no Requirements line
  3. Commit phase completion Check
    COMMIT_PLANNING_DOCS
    from config.json (default: true). If false: Skip git operations for .planning/ files. If true: Bundle all phase metadata updates in one commit:
    • Stage:
      git add .planning/ROADMAP.md .planning/STATE.md
    • Stage REQUIREMENTS.md if updated:
      git add .planning/REQUIREMENTS.md
    • Commit:
      docs({phase}): complete {phase-name} phase
10.5. Mark PR Ready (pr_workflow only)
After phase completion commit:
```bash
if [ "$PR_WORKFLOW" = "true" ]; then
  # Push final commits
  git push origin "$BRANCH"

  # Mark PR ready for review
  gh pr ready

  PR_URL=$(gh pr view --json url --jq '.url')
  echo "PR marked ready: $PR_URL"
fi
```

Store PR_URL for offer_next output.
10.6. Post-Verification Checkpoint (REQUIRED — Loop until user chooses "Skip to completion")
After PR is ready (or after phase commits if pr_workflow=false), present the user with post-verification options. This is the decision point before proceeding to completion output.

**Control flow:**
- UAT → returns here after completion
- PR review → step 10.7 → returns here
- Merge → executes merge → returns here
- Skip → proceeds to step 11

**IMPORTANT:** Do NOT skip this step. Do NOT proceed directly to step 11. The user must choose how to proceed.

Use AskUserQuestion:
- header: "Phase Complete"
- question: "Phase {X} execution complete. What would you like to do?"
- options:
  - "Run UAT (Recommended)" — Walk through deliverables for manual acceptance testing
  - "Run PR review" — 6 specialized agents review code quality
  - "Merge PR" — (if pr_workflow=true) Merge to main
  - "Skip to completion" — Trust automated verification, proceed to next phase/milestone

**Note:** Show "Merge PR" option only if `pr_workflow=true` AND PR exists AND not already merged.

**If user chooses "Run UAT":**
1. Invoke skill: `Skill("kata:kata-verify-work", "{phase}")`
2. UAT skill handles the walkthrough and any issues found
3. After UAT completes, return to this step to ask again (user may want PR review or merge)

**If user chooses "Run PR review":**
4. Invoke skill: `Skill("kata:review-pull-requests")`
5. Display review summary with counts: {N} critical, {M} important, {P} suggestions
6. **STOP and ask what to do with findings** (see step 10.7)
7. After findings handled, return to this step

**If user chooses "Merge PR":**
8. Execute merge:
   ```bash
   gh pr merge "$PR_NUMBER" --merge --delete-branch
   git checkout main && git pull

   # Explicitly close the phase issue (backup in case Closes #X didn't trigger)
   if [ -n "$PHASE_ISSUE" ]; then
     gh issue close "$PHASE_ISSUE" --comment "Closed by PR #${PR_NUMBER} merge" 2>/dev/null \
       && echo "Closed issue #${PHASE_ISSUE}" \
       || echo "Note: Issue #${PHASE_ISSUE} may already be closed"
   fi

   # Close source issues from plans (backup in case Closes #X didn't trigger)
   for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
     source_issue=$(grep -m1 "^source_issue:" "$plan" | cut -d':' -f2- | xargs)
     if echo "$source_issue" | grep -q "^github:#"; then
       issue_num=$(echo "$source_issue" | grep -oE '[0-9]+')
       gh issue close "$issue_num" --comment "Closed by PR #${PR_NUMBER} merge (source issue for plan)" 2>/dev/null || true
     fi
   done
   ```
9. Set MERGED=true
10. Return to this step to ask if user wants UAT or review before continuing

**If user chooses "Skip to completion":**
Continue to step 11.
10.7. Handle Review Findings (required after PR review completes)
**STOP here. Do not proceed until user chooses an action.**

Use AskUserQuestion with options based on what was found:
- header: "Review Findings"
- question: "How do you want to handle the review findings?"
- options (show only applicable ones):
  - "Fix critical issues" — (if critical > 0) Fix critical, then offer to add remaining to backlog
  - "Fix critical & important" — (if critical + important > 0) Fix both, then offer to add suggestions to backlog
  - "Fix all issues" — (if any issues) Fix everything
  - "Add to backlog" — Create issues for all findings without fixing
  - "Ignore and continue" — Skip all issues

**After user chooses:**

**Path A: "Fix critical issues"**
1. Fix each critical issue
2. If important or suggestions remain, ask: "Add remaining {N} issues to backlog?"
   - "Yes" → Create issues, store TODOS_CREATED count
   - "No" → Continue
3. Return to step 10.6 checkpoint

**Path B: "Fix critical & important"**
1. Fix each critical and important issue
2. If suggestions remain, ask: "Add {N} suggestions to backlog?"
   - "Yes" → Create issues, store TODOS_CREATED count
   - "No" → Continue
3. Return to step 10.6 checkpoint

**Path C: "Fix all issues"**
1. Fix all critical, important, and suggestion issues
2. Return to step 10.6 checkpoint

**Path D: "Add to backlog"**
1. Create issues for all findings using `/kata-add-issue`
2. Store TODOS_CREATED count
3. Return to step 10.6 checkpoint

**Path E: "Ignore and continue"**
1. Return to step 10.6 checkpoint

Store REVIEW_SUMMARY and TODOS_CREATED for offer_next output.

**Note:** After handling findings, return to step 10.6 so user can choose UAT, merge, or skip. The checkpoint loop continues until user explicitly chooses "Skip to completion".
11. Offer next steps - Route to next action (see
<offer_next>
) </process>
<offer_next> Output this markdown directly (not as a code block). Route based on status:
StatusRoute
gaps_found
Route C (gap closure)
human_needed
Present checklist, then re-route based on approval
passed
+ more phases
Route A (next phase)
passed
+ last phase
Route B (milestone complete)

Route A: Phase verified, more phases remain
(Merge status already determined in step 10.6)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► PHASE {Z} COMPLETE ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase {Z}: {Name}
{Y} plans executed Goal verified ✓ {If github.enabled: GitHub Issue: #{issue_number} ({checked}/{total} plans checked off)} {If PR_WORKFLOW and MERGED: PR: #{pr_number} — merged ✓} {If PR_WORKFLOW and not MERGED: PR: #{pr_number} ({pr_url}) — ready for review} {If REVIEW_SUMMARY: PR Review: {summary_stats}} {If TODOS_CREATED: Backlog: {N} issues created from review suggestions}
───────────────────────────────────────────────────────────────
${SOURCE_ISSUES}} PR_EOF
     # 创建草稿PR
     gh pr create --draft \
       --base main \
       --title "v${MILESTONE} Phase ${PHASE_NUM}: ${PHASE_NAME}" \
       --body-file /tmp/pr-body.md

     PR_NUMBER=$(gh pr list --head "$BRANCH" --json number --jq '.[0].number')
     echo "已创建草稿PR #${PR_NUMBER}"
   fi
 fi
 ```

 存储PR_NUMBER供步骤10.5使用。

 **注意:** PR内容中的复选列表在执行过程中保持未勾选状态。PR内容创建后即固定,不会随计划完成而更新。GitHub议题(每波浪完成后更新)是执行过程中计划进度的真实来源。
  • 继续处理下一个波浪
  1. 汇总结果
    • 收集所有计划的摘要
    • 报告阶段完成状态
  2. 提交编排器的修正内容 在验证前检查是否有未提交的更改:
    bash
    git status --porcelain
    如果存在更改: 编排器在执行器完成之间进行了修正。提交这些更改:
    bash
    git add -u && git commit -m "fix({phase}): orchestrator corrections"
    如果无更改: 继续执行测试套件。
6.5. 运行项目测试套件
在验证前,运行项目的测试套件以尽早发现回归问题:
bash
TEST_SCRIPT=$(cat package.json 2>/dev/null | grep -o '"test"[[:space:]]*:[[:space:]]*"[^"]*"' | head -1)
如果package.json中有测试脚本:
  • 运行
    npm test
  • 如果测试通过:继续步骤7
  • 如果测试失败:报告测试失败,但仍继续步骤7
如果未检测到测试脚本:
  • 跳过此步骤,继续步骤7
缺口阶段跳过: 如果模式为
gap_closure
,跳过测试套件
  1. 验证阶段目标 读取配置:
    WORKFLOW_VERIFIER=$(cat .planning/config.json 2>/dev/null | grep -o '"verifier"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")
    如果
    workflow.verifier
    false
    跳至步骤8(视为已通过)。
    否则:
    • 生成
      kata-verifier
      子代理,传入阶段目录和目标
    • 验证器会对照实际代码库(而非SUMMARY中的声明)检查must_haves
    • 创建包含详细报告的VERIFICATION.md
    • 根据状态路由:
      • passed
        → 继续步骤8
      • human_needed
        → 展示待办项,获取批准或反馈后重新路由
      • gaps_found
        → 展示缺口,提供
        /kata-plan-phase {X} --gaps
        命令
7.5. 验证完成并移至已完成状态
验证通过后,在将阶段移至已完成状态前验证完成工件:
bash
# 验证完成工件
PLAN_COUNT=$(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null | wc -l | tr -d ' ')
MISSING=""
if [ "$PLAN_COUNT" -eq 0 ]; then
  MISSING="${MISSING}\n- 未找到PLAN.md文件"
fi
for plan in $(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
  plan_id=$(basename "$plan" | sed 's/-PLAN\.md$//')
  [ ! -f "$PHASE_DIR/${plan_id}-SUMMARY.md" ] && MISSING="${MISSING}\n- ${plan_id}缺少SUMMARY.md"
done
# 非缺口阶段需要VERIFICATION.md
IS_GAP=$(find "$PHASE_DIR" -maxdepth 1 -name "*-PLAN.md" -exec grep -l "gap_closure: true" {} + 2>/dev/null | head -1)
if [ -z "$IS_GAP" ] && ! find "$PHASE_DIR" -maxdepth 1 -name "*-VERIFICATION.md" 2>/dev/null | grep -q .; then
  MISSING="${MISSING}\n- 缺少VERIFICATION.md(非缺口阶段必需)"
fi

if [ -z "$MISSING" ]; then
  DIR_NAME=$(basename "$PHASE_DIR")
  mkdir -p ".planning/phases/completed"
  mv "$PHASE_DIR" ".planning/phases/completed/${DIR_NAME}"
  PHASE_DIR=".planning/phases/completed/${DIR_NAME}"
  echo "阶段已验证并移至completed/目录"
else
  echo "警告:阶段未完成:${MISSING}"
fi
  1. 更新路线图和状态
    • 更新ROADMAP.md和STATE.md
  2. 更新需求 将阶段需求标记为已完成:
    • 读取ROADMAP.md,找到本阶段的
      Requirements:
      行(例如:"AUTH-01, AUTH-02")
    • 读取REQUIREMENTS.md的可追溯性表格
    • 对本阶段的每个REQ-ID:将状态从“Pending”改为“Complete”
    • 写入更新后的REQUIREMENTS.md
    • 如果REQUIREMENTS.md不存在,或阶段无Requirements行,则跳过
  3. 提交阶段完成内容 读取config.json中的
    COMMIT_PLANNING_DOCS
    (默认:true)。 如果为false:跳过对.planning/文件的git操作。 如果为true:将所有阶段元数据更新打包为一次提交:
    • 暂存:
      git add .planning/ROADMAP.md .planning/STATE.md
    • 如果更新了REQUIREMENTS.md,也暂存:
      git add .planning/REQUIREMENTS.md
    • 提交:
      docs({phase}): complete {phase-name} phase
10.5. 标记PR为可审核状态(仅pr_workflow模式)
提交阶段完成内容后:
```bash
if [ "$PR_WORKFLOW" = "true" ]; then
  # 推送最终提交
  git push origin "$BRANCH"

  # 标记PR为可审核状态
  gh pr ready

  PR_URL=$(gh pr view --json url --jq '.url')
  echo "PR已标记为可审核:$PR_URL"
fi
```

存储PR_URL供offer_next输出使用。
10.6. 验证后检查点(必需 — 循环直到用户选择“跳至完成”)
PR准备好后(或pr_workflow=false时阶段提交完成后),向用户展示验证后的选项。这是进入完成输出前的决策点。

**控制流程:**
- UAT → 完成后返回此处
- PR审核 → 步骤10.7 → 返回此处
- 合并 → 执行合并 → 返回此处
- 跳过 → 继续步骤11

**重要提示:** 不要跳过此步骤。不要直接进入步骤11。用户必须选择后续操作。

使用AskUserQuestion:
- header: "阶段完成"
- question: "阶段{X}执行完成。您希望进行下一步操作?"
- options:
  - "运行UAT(推荐)" — 遍历交付物进行手动验收测试
  - "运行PR审核" — 6个专业代理审核代码质量
  - "合并PR" — (仅pr_workflow=true)合并到主分支
  - "跳至完成" — 信任自动化验证,继续下一阶段/里程碑

**注意:** 仅当`pr_workflow=true`且PR存在且未合并时,才显示“合并PR”选项。

**如果用户选择“运行UAT”:**
1. 调用技能:`Skill("kata:kata-verify-work", "{phase}")`
2. UAT技能处理遍历过程和发现的任何问题
3. UAT完成后,返回此步骤再次询问(用户可能需要PR审核或合并)

**如果用户选择“运行PR审核”:**
4. 调用技能:`Skill("kata:review-pull-requests")`
5. 显示审核摘要及统计:{N}个严重问题,{M}个重要问题,{P}个建议
6. **停止并询问如何处理发现的问题**(见步骤10.7)
7. 处理完问题后,返回此步骤

**如果用户选择“合并PR”:**
8. 执行合并:
   ```bash
   gh pr merge "$PR_NUMBER" --merge --delete-branch
   git checkout main && git pull

   # 显式关闭阶段议题(作为Closes #X未触发的备份)
   if [ -n "$PHASE_ISSUE" ]; then
     gh issue close "$PHASE_ISSUE" --comment "Closed by PR #${PR_NUMBER} merge" 2>/dev/null \
       && echo "已关闭议题#${PHASE_ISSUE}" \
       || echo "注意:议题#${PHASE_ISSUE}可能已关闭"
   fi

   # 关闭计划中的源议题(作为Closes #X未触发的备份)
   for plan in $(find "${PHASE_DIR}" -maxdepth 1 -name "*-PLAN.md" 2>/dev/null); do
     source_issue=$(grep -m1 "^source_issue:" "$plan" | cut -d':' -f2- | xargs)
     if echo "$source_issue" | grep -q "^github:#"; then
       issue_num=$(echo "$source_issue" | grep -oE '[0-9]+')
       gh issue close "$issue_num" --comment "Closed by PR #${PR_NUMBER} merge (source issue for plan)" 2>/dev/null || true
     fi
   done
   ```
9. 设置MERGED=true
10. 返回此步骤询问用户是否要在继续前进行UAT或审核

**如果用户选择“跳至完成”:**
继续步骤11。
10.7. 处理审核发现的问题(PR审核完成后必需)
**在此处停止。用户选择操作前不要继续。**

根据发现的问题,使用AskUserQuestion提供选项:
- header: "审核发现的问题"
- question: "您希望如何处理审核发现的问题?"
- options(仅显示适用选项):
  - "修复严重问题" — (如果严重问题>0)修复严重问题,然后提供将剩余问题添加到待办事项的选项
  - "修复严重和重要问题" — (如果严重+重要问题>0)修复两者,然后提供将建议添加到待办事项的选项
  - "修复所有问题" — (如果存在任何问题)修复所有问题
  - "添加到待办事项" — 为所有发现的问题创建议题,不进行修复
  - "忽略并继续" — 跳过所有问题

**用户选择后:**

**路径A:“修复严重问题”**
1. 修复每个严重问题
2. 如果仍有重要问题或建议,询问:“将剩余{N}个问题添加到待办事项?”
   - “是” → 创建议题,存储TODOS_CREATED计数
   - “否” → 继续
3. 返回步骤10.6检查点

**路径B:“修复严重和重要问题”**
1. 修复每个严重和重要问题
2. 如果仍有建议,询问:“将{N}个建议添加到待办事项?”
   - “是” → 创建议题,存储TODOS_CREATED计数
   - “否” → 继续
3. 返回步骤10.6检查点

**路径C:“修复所有问题”**
1. 修复所有严重、重要和建议类问题
2. 返回步骤10.6检查点

**路径D:“添加到待办事项”**
1. 使用`/kata-add-issue`为所有发现的问题创建议题
2. 存储TODOS_CREATED计数
3. 返回步骤10.6检查点

**路径E:“忽略并继续”**
1. 返回步骤10.6检查点

存储REVIEW_SUMMARY和TODOS_CREATED供offer_next输出使用。

**注意:** 处理完问题后,返回步骤10.6,以便用户选择UAT、合并或跳过。检查点循环会持续到用户明确选择“跳至完成”。
11. 提供下一步操作建议 - 根据状态路由至下一个操作(见
<offer_next>
</process>
<offer_next> 直接输出此markdown(不要放在代码块中)。根据状态路由:
状态路由
gaps_found
路由C(缺口修复)
human_needed
展示复选列表,然后根据批准结果重新路由
passed
+ 存在更多阶段
路由A(下一阶段)
passed
+ 最后一个阶段
路由B(里程碑完成)

路由A:阶段已验证,存在更多阶段
(合并状态已在步骤10.6中确定)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 阶段{Z}完成 ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段{Z}:{名称}
已执行{Y}个计划 目标已验证 ✓ {如果github.enabled为true:GitHub议题:#{issue_number}(已勾选{checked}/{total}个计划)} {如果PR_WORKFLOW且MERGED:PR:#{pr_number} — 已合并 ✓} {如果PR_WORKFLOW且未MERGED:PR:#{pr_number}({pr_url}) — 已准备好审核} {如果存在REVIEW_SUMMARY:PR审核:{summary_stats}} {如果存在TODOS_CREATED:待办事项:从审核建议中创建了{N}个议题}
───────────────────────────────────────────────────────────────

▶ Next Up

▶ 下一步

Phase {Z+1}: {Name} — {Goal from ROADMAP.md}
/kata-discuss-phase {Z+1}
— gather context and clarify approach
<sub>
/clear
first → fresh context window</sub>
───────────────────────────────────────────────────────────────
Also available:
  • /kata-plan-phase {Z+1}
    — skip discussion, plan directly
  • /kata-verify-work {Z}
    — manual acceptance testing before continuing {If PR_WORKFLOW and not MERGED: -
    gh pr view --web
    — review PR in browser before next phase}
───────────────────────────────────────────────────────────────

Route B: Phase verified, milestone complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► MILESTONE COMPLETE 🎉 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
v1.0
{N} phases completed All phase goals verified ✓ {If PR_WORKFLOW and MERGED: All phase PRs merged ✓} {If PR_WORKFLOW and not MERGED: Phase PRs ready — merge to prepare for release}
───────────────────────────────────────────────────────────────
阶段{Z+1}:{名称} — {来自ROADMAP.md的目标}
/kata-discuss-phase {Z+1}
— 收集上下文并明确方法
<sub>先执行
/clear
→ 刷新上下文窗口</sub>
───────────────────────────────────────────────────────────────
其他可用操作:
  • /kata-plan-phase {Z+1}
    — 跳过讨论,直接规划
  • /kata-verify-work {Z}
    — 继续前进行手动验收测试 {如果PR_WORKFLOW且未MERGED:-
    gh pr view --web
    — 下一阶段前在浏览器中审核PR}
───────────────────────────────────────────────────────────────

路由B:阶段已验证,里程碑完成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 里程碑完成 🎉 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
v1.0
已完成{N}个阶段 所有阶段目标已验证 ✓ {如果PR_WORKFLOW且MERGED:所有阶段PR已合并 ✓} {如果PR_WORKFLOW且未MERGED:阶段PR已准备好 — 合并以准备发布}
───────────────────────────────────────────────────────────────

▶ Next Up

▶ 下一步

Audit milestone — verify requirements, cross-phase integration, E2E flows
/kata-audit-milestone
<sub>/clear first → fresh context window</sub>
───────────────────────────────────────────────────────────────
Also available:
  • /kata-verify-work — manual acceptance testing
  • /kata-complete-milestone — skip audit, archive directly
───────────────────────────────────────────────────────────────

Route C: Gaps found — need additional planning
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► PHASE {Z} GAPS FOUND ⚠ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase {Z}: {Name}
Score: {N}/{M} must-haves verified Report: .planning/phases/{phase_dir}/{phase}-VERIFICATION.md
审核里程碑 — 验证需求、跨阶段集成、端到端流程
/kata-audit-milestone
<sub>先执行/clear → 刷新上下文窗口</sub>
───────────────────────────────────────────────────────────────
其他可用操作:
  • /kata-verify-work — 手动验收测试
  • /kata-complete-milestone — 跳过审核,直接归档
───────────────────────────────────────────────────────────────

路由C:发现缺口 — 需要额外规划
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kata ► 阶段{Z}发现缺口 ⚠ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段{Z}:{名称}
得分:{N}/{M}个必需项已验证 报告:.planning/phases/{phase_dir}/{phase}-VERIFICATION.md

What's Missing

缺失内容

{Extract gap summaries from VERIFICATION.md}
───────────────────────────────────────────────────────────────
{从VERIFICATION.md中提取缺口摘要}
───────────────────────────────────────────────────────────────

▶ Next Up

▶ 下一步

Plan gap closure — create additional plans to complete the phase
/kata-plan-phase {Z} --gaps
<sub>/clear first → fresh context window</sub>
───────────────────────────────────────────────────────────────
Also available:
  • cat .planning/phases/{phase_dir}/{phase}-VERIFICATION.md — see full report
  • /kata-verify-work {Z} — manual testing before planning
───────────────────────────────────────────────────────────────

After user runs /kata-plan-phase {Z} --gaps:
  1. Planner reads VERIFICATION.md gaps
  2. Creates plans 04, 05, etc. to close gaps
  3. User runs /kata-execute-phase {Z} again
  4. phase-execute runs incomplete plans (04, 05...)
  5. Verifier runs again → loop until passed </offer_next>
<wave_execution> Parallel spawning:
Before spawning, read file contents using Read tool. The
@
syntax does not work across Task() boundaries - content must be inlined in the Task prompt.
Read these files:
  • Each plan file in the wave (e.g.,
    {plan_01_path}
    ,
    {plan_02_path}
    , etc.)
  • .planning/STATE.md
  • references/executor-instructions.md
    (relative to skill base directory) — store as
    executor_instructions_content
Spawn all plans in a wave with a single message containing multiple Task calls, with inlined content:
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_01_path}\n\n<plan>\n{plan_01_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_02_path}\n\n<plan>\n{plan_02_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_03_path}\n\n<plan>\n{plan_03_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
All three run in parallel. Task tool blocks until all complete.
No polling. No background agents. No TaskOutput loops. </wave_execution>
<checkpoint_handling> Plans with
autonomous: false
have checkpoints. The phase-execute.md workflow handles the full checkpoint flow:
  • Subagent pauses at checkpoint, returns structured state
  • Orchestrator presents to user, collects response
  • Spawns fresh continuation agent (not resume)
See
@./references/phase-execute.md
step
checkpoint_handling
for complete details. </checkpoint_handling>
<deviation_rules> During execution, handle discoveries automatically:
  1. Auto-fix bugs - Fix immediately, document in Summary
  2. Auto-add critical - Security/correctness gaps, add and document
  3. Auto-fix blockers - Can't proceed without fix, do it and document
  4. Ask about architectural - Major structural changes, stop and ask user
Only rule 4 requires user intervention. </deviation_rules>
<commit_rules> Per-Task Commits:
After each task completes:
  1. Stage only files modified by that task
  2. Commit with format:
    {type}({phase}-{plan}): {task-name}
  3. Types: feat, fix, test, refactor, perf, chore
  4. Record commit hash for SUMMARY.md
Plan Metadata Commit:
After all tasks in a plan complete:
  1. Stage plan artifacts only: PLAN.md, SUMMARY.md
  2. Commit with format:
    docs({phase}-{plan}): complete [plan-name] plan
  3. NO code files (already committed per-task)
Phase Completion Commit:
After all plans in phase complete (step 7):
  1. Stage: ROADMAP.md, STATE.md, REQUIREMENTS.md (if updated), VERIFICATION.md
  2. Commit with format:
    docs({phase}): complete {phase-name} phase
  3. Bundles all phase-level state updates in one commit
NEVER use:
  • git add .
  • git add -A
  • git add src/
    or any broad directory
Always stage files individually. </commit_rules>
<success_criteria>
  • All incomplete plans in phase executed
  • Each plan has SUMMARY.md
  • Phase goal verified (must_haves checked against codebase)
  • VERIFICATION.md created in phase directory
  • STATE.md reflects phase completion
  • ROADMAP.md updated
  • REQUIREMENTS.md updated (phase requirements marked Complete)
  • GitHub issue checkboxes updated per wave (if github.enabled)
  • User informed of next steps </success_criteria>
规划缺口修复 — 创建额外计划以完成阶段
/kata-plan-phase {Z} --gaps
<sub>先执行/clear → 刷新上下文窗口</sub>
───────────────────────────────────────────────────────────────
其他可用操作:
  • cat .planning/phases/{phase_dir}/{phase}-VERIFICATION.md — 查看完整报告
  • /kata-verify-work {Z} — 规划前进行手动测试
───────────────────────────────────────────────────────────────

用户运行/kata-plan-phase {Z} --gaps后:
  1. 规划器读取VERIFICATION.md中的缺口
  2. 创建计划04、05等以修复缺口
  3. 用户再次运行/kata-execute-phase {Z}
  4. phase-execute运行未完成的计划(04、05...)
  5. 验证器再次运行 → 循环直到通过 </offer_next>
<wave_execution> 并行生成:
生成前,使用Read工具读取文件内容。
@
语法在Task()边界之间不起作用 — 内容必须内联到Task提示中。
读取以下文件:
  • 波浪中的每个计划文件(例如:
    {plan_01_path}
    {plan_02_path}
    等)
  • .planning/STATE.md
  • references/executor-instructions.md
    (相对于技能基础目录) — 存储为
    executor_instructions_content
在一条消息中包含多个Task调用,内联内容,并行生成波浪中的所有计划:
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_01_path}\n\n<plan>\n{plan_01_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_02_path}\n\n<plan>\n{plan_02_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
Task(prompt="<agent-instructions>\n{executor_instructions_content}\n</agent-instructions>\n\nExecute plan at {plan_03_path}\n\n<plan>\n{plan_03_content}\n</plan>\n\n<project_state>\n{state_content}\n</project_state>", subagent_type="general-purpose", model="{executor_model}")
三个任务并行运行。Task工具会阻塞直到所有任务完成。
无轮询。 无后台代理。无TaskOutput循环。 </wave_execution>
<checkpoint_handling> 带有
autonomous: false
的计划包含检查点。phase-execute.md工作流处理完整的检查点流程:
  • 子代理在检查点暂停,返回结构化状态
  • 编排器向用户展示,收集响应
  • 生成全新的延续代理(而非恢复)
有关完整详情,请参阅
@./references/phase-execute.md
中的
checkpoint_handling
步骤。 </checkpoint_handling>
<deviation_rules> 执行过程中,自动处理发现的偏差:
  1. 自动修复bug - 立即修复,在摘要中记录
  2. 自动添加关键内容 - 安全/正确性缺口,添加并记录
  3. 自动修复阻塞问题 - 不修复无法继续的问题,修复并记录
  4. 询问架构相关问题 - 重大结构变更,停止并询问用户
仅规则4需要用户干预。 </deviation_rules>
<commit_rules> 每个任务的提交:
每个任务完成后:
  1. 仅暂存该任务修改的文件
  2. 提交格式:
    {type}({phase}-{plan}): {task-name}
  3. 类型:feat、fix、test、refactor、perf、chore
  4. 记录提交哈希用于SUMMARY.md
计划元数据提交:
一个计划中的所有任务完成后:
  1. 仅暂存计划工件:PLAN.md、SUMMARY.md
  2. 提交格式:
    docs({phase}-{plan}): complete [plan-name] plan
  3. 不包含代码文件(已按任务提交)
阶段完成提交:
阶段中所有计划完成后(步骤7):
  1. 暂存:ROADMAP.md、STATE.md、REQUIREMENTS.md(如果更新)、VERIFICATION.md
  2. 提交格式:
    docs({phase}): complete {phase-name} phase
  3. 将所有阶段级状态更新打包为一次提交
禁止使用:
  • git add .
  • git add -A
  • git add src/
    或任何宽泛的目录
始终单独暂存文件。 </commit_rules>
<success_criteria>
  • 阶段中所有未完成计划已执行
  • 每个计划都有SUMMARY.md
  • 阶段目标已验证(对照代码库检查must_haves)
  • 阶段目录中已创建VERIFICATION.md
  • STATE.md反映阶段完成
  • ROADMAP.md已更新
  • REQUIREMENTS.md已更新(阶段需求标记为Complete)
  • GitHub议题复选框按波浪更新(如果github.enabled为true)
  • 已告知用户下一步操作 </success_criteria>