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:
- — Execute only gap closure plans (plans with
--gaps-onlyin frontmatter). Use after phase-verify creates fix plans.gap_closure: true
@.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:
| Agent | quality | balanced | budget |
|---|---|---|---|
| general-purpose (executor) | opus | sonnet | sonnet |
| kata-verifier | sonnet | sonnet | haiku |
| kata-code-reviewer | opus | sonnet | sonnet |
| kata-*-analyzer | sonnet | sonnet | haiku |
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.
- Validate phase exists
Find phase directory using the discovery script:
Outputsbash
bash "${SKILL_BASE_DIR}/scripts/find-phase.sh" "$PHASE_ARG",PHASE_DIR, andPLAN_COUNTas key=value pairs. Exit code 1 = not found, 2 = no plans. Parse the output to set these variables for subsequent steps.PHASE_STATE
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/"
fi1.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:
- 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') - 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]+-//') - 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 - 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.
-
Discover plans
- List all *-PLAN.md files in phase directory
- Check which have *-SUMMARY.md (already complete)
- If : filter to only plans with
--gaps-onlygap_closure: true - Build list of incomplete plans
-
Group by wave
- Read from each plan's frontmatter
wave - Group plans by wave number
- Read
3.5. Display execution banner
Display stage banner and wave structure:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kata ► EXECUTING PHASE {X}: {Phase Name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
{N} plans, {M} waves:
| Wave | Plans | Description |
|---|---|---|
| 1 | 01, 02 | {plan names from frontmatter} |
| 2 | 03 | {plan name} |
Model profile: {profile} (executor → {model})
- Execute waves
For each wave in order:
-
Spawnexecutor for each plan in wave (parallel Task calls)
general-purpose -
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 doneCheck github.enabled and issueMode:bashGITHUB_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")IfORGITHUB_ENABLED != true: Skip GitHub update.ISSUE_MODE = neverOtherwise:- Find phase issue number:
bashVERSION=$(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).- Read current issue body:
bashISSUE_BODY=$(gh issue view "$ISSUE_NUMBER" --json body --jq '.body' 2>/dev/null)- For each completed plan in this wave, update checkbox:
bashfor 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- Write and update:
bashprintf '%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的计划)。在phase-verify生成修复计划后使用。gap_closure: true
@.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”。
模型查找表:
| 代理类型 | quality | balanced | budget |
|---|---|---|---|
| general-purpose (executor) | opus | sonnet | sonnet |
| kata-verifier | sonnet | sonnet | haiku |
| kata-code-reviewer | opus | sonnet | sonnet |
| kata-*-analyzer | sonnet | sonnet | haiku |
注意:审核类代理(kata-code-reviewer、kata--analyzer)由kata-review-pull-requests技能生成,该技能会根据代理的前置元数据自行选择模型。以上表格记录了成本规划中预期的模型使用情况。*
存储解析后的模型,供后续Task调用使用。
- 验证阶段是否存在
使用发现脚本查找阶段目录:
输出bash
bash "${SKILL_BASE_DIR}/scripts/find-phase.sh" "$PHASE_ARG"、PHASE_DIR和PLAN_COUNT的键值对。退出码1表示未找到,2表示无计划。解析输出结果,为后续步骤设置这些变量。PHASE_STATE
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/目录"
fi1.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:
- 从ROADMAP.md获取里程碑版本:
bash
MILESTONE=$(grep -oE 'v[0-9]+\.[0-9]+(\.[0-9]+)?' .planning/ROADMAP.md | head -1 | tr -d 'v') - 从PHASE_DIR获取阶段编号和别名:
bash
PHASE_NUM=$(basename "$PHASE_DIR" | sed -E 's/^([0-9]+)-.*/\1/') SLUG=$(basename "$PHASE_DIR" | sed -E 's/^[0-9]+-//') - 根据阶段目标推断分支类型(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 - 创建分支并支持重运行保护:
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使用。
-
发现计划
- 列出阶段目录下所有*-PLAN.md文件
- 检查哪些文件已有对应的*-SUMMARY.md(表示已完成)
- 如果使用:仅筛选出
--gaps-only的计划gap_closure: true - 构建未完成计划列表
-
按波浪分组
- 读取每个计划前置元数据中的字段
wave - 按波浪编号对计划进行分组
- 读取每个计划前置元数据中的
3.5. 显示执行横幅
显示阶段横幅和波浪结构:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kata ► 正在执行阶段 {X}: {阶段名称}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
{N} 个计划,{M} 个波浪:
| 波浪编号 | 计划 | 描述 |
|---|---|---|
| 1 | 01, 02 | {来自前置元数据的计划名称} |
| 2 | 03 | {计划名称} |
模型配置: {profile}(执行器 → {model})
- 执行波浪计划
按顺序处理每个波浪:
-
为波浪中的每个计划生成执行器(并行Task调用)
general-purpose -
等待所有任务完成(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配置:bashGITHUB_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: 跳过GitHub更新。ISSUE_MODE = never否则:- 查找阶段对应的议题编号:
bashVERSION=$(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)如果未找到议题:发出警告并跳过(不阻塞流程)。- 读取当前议题内容:
bashISSUE_BODY=$(gh issue view "$ISSUE_NUMBER" --json body --jq '.body' 2>/dev/null)- 对本波浪中每个已完成的计划,更新复选框:
bashfor 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- 写入并更新议题:
bashprintf '%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
-
Aggregate results
- Collect summaries from all plans
- Report phase completion status
-
Commit any orchestrator corrections Check for uncommitted changes before verification:bash
git status --porcelainIf changes exist: Orchestrator made corrections between executor completions. Commit them:bashgit 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 , skip test suite
gap_closure-
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")Ifisworkflow.verifier: Skip to step 8 (treat as passed).falseOtherwise:- Spawn subagent with phase directory and goal
kata-verifier - Verifier checks must_haves against actual codebase (not SUMMARY claims)
- Creates VERIFICATION.md with detailed report
- Route by status:
- → continue to step 8
passed - → present items, get approval or feedback
human_needed - → present gaps, offer
gaps_found/kata-plan-phase {X} --gaps
- Spawn
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-
Update roadmap and state
- Update ROADMAP.md, STATE.md
-
Update requirements Mark phase requirements as Complete:
- Read ROADMAP.md, find this phase's line (e.g., "AUTH-01, AUTH-02")
Requirements: - 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
- Read ROADMAP.md, find this phase's
-
Commit phase completion Checkfrom config.json (default: true). If false: Skip git operations for .planning/ files. If true: Bundle all phase metadata updates in one commit:
COMMIT_PLANNING_DOCS- 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
- Stage:
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 )
</process>
<offer_next><offer_next>
Output this markdown directly (not as a code block). Route based on status:
| Status | Route |
|---|---|
| Route C (gap closure) |
| Present checklist, then re-route based on approval |
| Route A (next 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议题(每波浪完成后更新)是执行过程中计划进度的真实来源。- 继续处理下一个波浪
-
汇总结果
- 收集所有计划的摘要
- 报告阶段完成状态
-
提交编排器的修正内容 在验证前检查是否有未提交的更改:bash
git status --porcelain如果存在更改: 编排器在执行器完成之间进行了修正。提交这些更改:bashgit 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-
验证阶段目标 读取配置:
WORKFLOW_VERIFIER=$(cat .planning/config.json 2>/dev/null | grep -o '"verifier"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "true")如果为workflow.verifier: 跳至步骤8(视为已通过)。false否则:- 生成子代理,传入阶段目录和目标
kata-verifier - 验证器会对照实际代码库(而非SUMMARY中的声明)检查must_haves
- 创建包含详细报告的VERIFICATION.md
- 根据状态路由:
- → 继续步骤8
passed - → 展示待办项,获取批准或反馈后重新路由
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-
更新路线图和状态
- 更新ROADMAP.md和STATE.md
-
更新需求 将阶段需求标记为已完成:
- 读取ROADMAP.md,找到本阶段的行(例如:"AUTH-01, AUTH-02")
Requirements: - 读取REQUIREMENTS.md的可追溯性表格
- 对本阶段的每个REQ-ID:将状态从“Pending”改为“Complete”
- 写入更新后的REQUIREMENTS.md
- 如果REQUIREMENTS.md不存在,或阶段无Requirements行,则跳过
- 读取ROADMAP.md,找到本阶段的
-
提交阶段完成内容 读取config.json中的(默认:true)。 如果为false:跳过对.planning/文件的git操作。 如果为true:将所有阶段元数据更新打包为一次提交:
COMMIT_PLANNING_DOCS- 暂存:
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. 提供下一步操作建议
- 根据状态路由至下一个操作(见)
</process>
<offer_next><offer_next>
直接输出此markdown(不要放在代码块中)。根据状态路由:
| 状态 | 路由 |
|---|---|
| 路由C(缺口修复) |
| 展示复选列表,然后根据批准结果重新路由 |
| 路由A(下一阶段) |
| 路由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}<sub> first → fresh context window</sub>
/clear───────────────────────────────────────────────────────────────
Also available:
- — skip discussion, plan directly
/kata-plan-phase {Z+1} - — manual acceptance testing before continuing {If PR_WORKFLOW and not MERGED: -
/kata-verify-work {Z}— review PR in browser before next phase}gh pr view --web
───────────────────────────────────────────────────────────────
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>先执行 → 刷新上下文窗口</sub>
/clear───────────────────────────────────────────────────────────────
其他可用操作:
- — 跳过讨论,直接规划
/kata-plan-phase {Z+1} - — 继续前进行手动验收测试 {如果PR_WORKFLOW且未MERGED:-
/kata-verify-work {Z}— 下一阶段前在浏览器中审核PR}gh pr view --web
───────────────────────────────────────────────────────────────
路由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:
- Planner reads VERIFICATION.md gaps
- Creates plans 04, 05, etc. to close gaps
- User runs /kata-execute-phase {Z} again
- phase-execute runs incomplete plans (04, 05...)
- 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}, etc.){plan_02_path} .planning/STATE.md- (relative to skill base directory) — store as
references/executor-instructions.mdexecutor_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 have checkpoints. The phase-execute.md workflow handles the full checkpoint flow:
autonomous: false- Subagent pauses at checkpoint, returns structured state
- Orchestrator presents to user, collects response
- Spawns fresh continuation agent (not resume)
See step for complete details.
</checkpoint_handling>
@./references/phase-execute.mdcheckpoint_handling<deviation_rules>
During execution, handle discoveries automatically:
- Auto-fix bugs - Fix immediately, document in Summary
- Auto-add critical - Security/correctness gaps, add and document
- Auto-fix blockers - Can't proceed without fix, do it and document
- 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:
- Stage only files modified by that task
- Commit with format:
{type}({phase}-{plan}): {task-name} - Types: feat, fix, test, refactor, perf, chore
- Record commit hash for SUMMARY.md
Plan Metadata Commit:
After all tasks in a plan complete:
- Stage plan artifacts only: PLAN.md, SUMMARY.md
- Commit with format:
docs({phase}-{plan}): complete [plan-name] plan - NO code files (already committed per-task)
Phase Completion Commit:
After all plans in phase complete (step 7):
- Stage: ROADMAP.md, STATE.md, REQUIREMENTS.md (if updated), VERIFICATION.md
- Commit with format:
docs({phase}): complete {phase-name} phase - Bundles all phase-level state updates in one commit
NEVER use:
git add .git add -A- or any broad directory
git add src/
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后:
- 规划器读取VERIFICATION.md中的缺口
- 创建计划04、05等以修复缺口
- 用户再次运行/kata-execute-phase {Z}
- phase-execute运行未完成的计划(04、05...)
- 验证器再次运行 → 循环直到通过 </offer_next>
<wave_execution>
并行生成:
生成前,使用Read工具读取文件内容。语法在Task()边界之间不起作用 — 内容必须内联到Task提示中。
@读取以下文件:
- 波浪中的每个计划文件(例如:、
{plan_01_path}等){plan_02_path} .planning/STATE.md- (相对于技能基础目录) — 存储为
references/executor-instructions.mdexecutor_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>
带有的计划包含检查点。phase-execute.md工作流处理完整的检查点流程:
autonomous: false- 子代理在检查点暂停,返回结构化状态
- 编排器向用户展示,收集响应
- 生成全新的延续代理(而非恢复)
有关完整详情,请参阅中的步骤。
</checkpoint_handling>
@./references/phase-execute.mdcheckpoint_handling<deviation_rules>
执行过程中,自动处理发现的偏差:
- 自动修复bug - 立即修复,在摘要中记录
- 自动添加关键内容 - 安全/正确性缺口,添加并记录
- 自动修复阻塞问题 - 不修复无法继续的问题,修复并记录
- 询问架构相关问题 - 重大结构变更,停止并询问用户
仅规则4需要用户干预。
</deviation_rules>
<commit_rules>
每个任务的提交:
每个任务完成后:
- 仅暂存该任务修改的文件
- 提交格式:
{type}({phase}-{plan}): {task-name} - 类型:feat、fix、test、refactor、perf、chore
- 记录提交哈希用于SUMMARY.md
计划元数据提交:
一个计划中的所有任务完成后:
- 仅暂存计划工件:PLAN.md、SUMMARY.md
- 提交格式:
docs({phase}-{plan}): complete [plan-name] plan - 不包含代码文件(已按任务提交)
阶段完成提交:
阶段中所有计划完成后(步骤7):
- 暂存:ROADMAP.md、STATE.md、REQUIREMENTS.md(如果更新)、VERIFICATION.md
- 提交格式:
docs({phase}): complete {phase-name} phase - 将所有阶段级状态更新打包为一次提交
禁止使用:
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>