workflow-tdd-plan-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workflow TDD

工作流TDD

Unified TDD workflow skill combining TDD planning (Red-Green-Refactor task chain generation with test-first development structure) and TDD verification (compliance validation with quality gate reporting). Produces IMPL_PLAN.md, task JSONs with internal TDD cycles, and TDD_COMPLIANCE_REPORT.md.
整合了TDD规划(含测试优先开发结构的红-绿-重构任务链生成)与TDD验证(含质量门报告的合规校验)的统一TDD工作流技能。可生成IMPL_PLAN.md、包含内部TDD周期的任务JSON文件,以及TDD_COMPLIANCE_REPORT.md。

Architecture Overview

架构概述

┌──────────────────────────────────────────────────────────────────┐
│  Workflow TDD Orchestrator (SKILL.md)                            │
│  → Route by mode: plan | verify                                  │
│  → Pure coordinator: Execute phases, parse outputs, pass context │
└──────────────────────────────┬───────────────────────────────────┘
        ┌───────────────────────┴───────────────────────┐
        ↓                                               ↓
  ┌─────────────┐                                ┌───────────┐
  │  Plan Mode  │                                │  Verify   │
  │  (default)  │                                │   Mode    │
  │ Phase 1-6   │                                │  Phase 7  │
  └──────┬──────┘                                └───────────┘
   ┌─────┼─────┬─────┬─────┬─────┐
   ↓     ↓     ↓     ↓     ↓     ↓
 ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
 │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │ 6 │
 │Ses│ │Ctx│ │Tst│ │Con│ │Gen│ │Val│
 └───┘ └───┘ └───┘ └───┘ └─┬─┘ └───┘
                       ┌───────────┐
                       │ Confirm   │─── Verify ──→ Phase 7
                       │ (choice)  │─── Execute ─→ Skill("workflow-execute")
                       └───────────┘─── Review ──→ Display session status inline
┌──────────────────────────────────────────────────────────────────┐
│  Workflow TDD Orchestrator (SKILL.md)                            │
│  → 按模式路由:plan | verify                                  │
│  → 纯协调器:执行阶段、解析输出、传递上下文 │
└──────────────────────────────┬───────────────────────────────────┘
        ┌───────────────────────┴───────────────────────┐
        ↓                                               ↓
  ┌─────────────┐                                ┌───────────┐
  │  Plan模式  │                                │  Verify   │
  │  (默认)  │                                │   模式    │
  │ 阶段1-6   │                                │  阶段7  │
  └──────┬──────┘                                └───────────┘
   ┌─────┼─────┬─────┬─────┬─────┐
   ↓     ↓     ↓     ↓     ↓     ↓
 ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
 │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │ 6 │
 │会话│ │上下文│ │测试│ │冲突│ │生成│ │验证│
 └───┘ └───┘ └───┘ └───┘ └─┬─┘ └───┘
                       ┌───────────┐
                       │ 确认   │─── 验证 ──→ 阶段7
                       │ (选项)  │─── 执行 ─→ Skill("workflow-execute")
                       └───────────┘─── 查看 ──→ 内联显示会话状态

Key Design Principles

核心设计原则

  1. Pure Orchestrator: SKILL.md routes and coordinates only; execution detail lives in phase files
  2. Progressive Phase Loading: Read phase docs ONLY when that phase is about to execute
  3. Multi-Mode Routing: Single skill handles plan/verify via mode detection
  4. Task Attachment Model: Sub-command tasks are ATTACHED, executed sequentially, then COLLAPSED
  5. Auto-Continue: After each phase completes, automatically execute next pending phase
  6. TDD Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST - enforced in task structure
  1. 纯协调器:SKILL.md仅负责路由与协调;执行细节存于阶段文件中
  2. 渐进式阶段加载:仅当即将执行某阶段时才读取该阶段文档
  3. 多模式路由:单个技能通过模式检测处理plan/verify两种模式
  4. 任务附加模型:子命令任务被附加到当前工作流,按顺序执行后折叠
  5. 自动继续:每个阶段完成后,自动执行下一个待处理阶段
  6. TDD铁律:无失败测试则不编写生产代码 - 在任务结构中强制实施

Interactive Preference Collection

交互式偏好收集

Before dispatching to phase execution, collect workflow preferences via AskUserQuestion:
javascript
// ★ 统一 auto mode 检测:-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

if (autoYes) {
  // 自动模式:跳过所有询问,使用默认值
  workflowPreferences = { autoYes: true }
} else {
  const prefResponse = AskUserQuestion({
    questions: [
      {
        question: "是否跳过所有确认步骤(自动模式)?",
        header: "Auto Mode",
        multiSelect: false,
        options: [
          { label: "Interactive (Recommended)", description: "交互模式,包含确认步骤" },
          { label: "Auto", description: "跳过所有确认,自动执行" }
        ]
      }
    ]
  })

  workflowPreferences = {
    autoYes: prefResponse.autoMode === 'Auto'
  }
}
workflowPreferences is passed to phase execution as context variable, referenced as
workflowPreferences.autoYes
within phases.
在分发到阶段执行前,通过AskUserQuestion收集工作流偏好:
javascript
// ★ 统一 auto mode 检测:-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

if (autoYes) {
  // 自动模式:跳过所有询问,使用默认值
  workflowPreferences = { autoYes: true }
} else {
  const prefResponse = AskUserQuestion({
    questions: [
      {
        question: "是否跳过所有确认步骤(自动模式)?",
        header: "Auto Mode",
        multiSelect: false,
        options: [
          { label: "Interactive (Recommended)", description: "交互模式,包含确认步骤" },
          { label: "Auto", description: "跳过所有确认,自动执行" }
        ]
      }
    ]
  })

  workflowPreferences = {
    autoYes: prefResponse.autoMode === 'Auto'
  }
}
workflowPreferences 作为上下文变量传递给阶段执行,在阶段中通过
workflowPreferences.autoYes
引用。

Mode Detection

模式检测

javascript
const args = $ARGUMENTS
const mode = detectMode(args)

function detectMode(args) {
  // Skill trigger determines mode
  if (skillName === 'workflow-tdd-verify') return 'verify'
  return 'plan'  // default: workflow-tdd-plan
}
javascript
const args = $ARGUMENTS
const mode = detectMode(args)

function detectMode(args) {
  // 技能触发词决定模式
  if (skillName === 'workflow-tdd-verify') return 'verify'
  return 'plan'  // 默认:workflow-tdd-plan
}

Compact Recovery (Phase Persistence)

紧凑恢复(阶段持久化)

Multi-phase TDD planning (Phase 1-6/7) spans long conversations. Uses 双重保险: TodoWrite 跟踪 active phase 保护其不被压缩,sentinel 作为兜底。
⚠️ COMPACT DIRECTIVE: Context compression MUST check TodoWrite phase status. The phase currently marked
in_progress
is the active execution phase — preserve its FULL content. Only compress phases marked
completed
or
pending
.
多阶段TDD规划(阶段1-6/7)会跨长对话。采用双重保险:TodoWrite跟踪active phase以防止其被压缩,sentinel作为兜底方案。
⚠️ 压缩指令:上下文压缩必须检查TodoWrite阶段状态。 当前标记为
in_progress
的阶段是活跃执行阶段 —— 保留其完整内容。 仅压缩标记为
completed
pending
的阶段。

Execution Flow

执行流程

Plan Mode (default)

Plan模式(默认)

Input Parsing:
   └─ Convert user input to TDD structured format (GOAL/SCOPE/CONTEXT/TEST_FOCUS)

Phase 1: Session Discovery
   └─ Ref: phases/01-session-discovery.md
      └─ Output: sessionId (WFS-xxx)

Phase 2: Context Gathering
   └─ Ref: phases/02-context-gathering.md
      ├─ Tasks attached: Analyze structure → Identify integration → Generate package
      └─ Output: contextPath + conflictRisk

Phase 3: Test Coverage Analysis
   └─ Ref: phases/03-test-coverage-analysis.md
      ├─ Tasks attached: Detect framework → Analyze coverage → Identify gaps
      └─ Output: testContextPath

Phase 4: Conflict Resolution (conditional: conflictRisk ≥ medium)
   └─ Decision (conflictRisk check):
      ├─ conflictRisk ≥ medium → Ref: phases/04-conflict-resolution.md
      │   ├─ Tasks attached: Detect conflicts → Log analysis → Apply strategies
      │   └─ Output: conflict-resolution.json
      └─ conflictRisk < medium → Skip to Phase 5

Phase 5: TDD Task Generation
   └─ Ref: phases/05-tdd-task-generation.md
      ├─ Tasks attached: Discovery → Planning → Output
      └─ Output: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md

Phase 6: TDD Structure Validation
   └─ Ref: phases/06-tdd-structure-validation.md
      └─ Output: Validation report + Plan Confirmation Gate

Plan Confirmation (User Decision Gate):
   └─ Decision (user choice):
      ├─ "Verify TDD Compliance" (Recommended) → Route to Phase 7 (tdd-verify)
      ├─ "Start Execution" → Skill(skill="workflow-execute")
      └─ "Review Status Only" → Display session status inline
输入解析:
   └─ 将用户输入转换为TDD结构化格式(GOAL/SCOPE/CONTEXT/TEST_FOCUS)

阶段1:会话发现
   └─ 参考:phases/01-session-discovery.md
      └─ 输出:sessionId (WFS-xxx)

阶段2:上下文收集
   └─ 参考:phases/02-context-gathering.md
      ├─ 附加任务:分析结构 → 识别集成 → 生成包
      └─ 输出:contextPath + conflictRisk

阶段3:测试覆盖分析
   └─ 参考:phases/03-test-coverage-analysis.md
      ├─ 附加任务:检测框架 → 分析覆盖率 → 识别缺口
      └─ 输出:testContextPath

阶段4:冲突解决(条件:conflictRisk ≥ medium)
   └─ 决策(conflictRisk检查):
      ├─ conflictRisk ≥ medium → 参考:phases/04-conflict-resolution.md
      │   ├─ 附加任务:检测冲突 → 记录分析 → 应用策略
      │   └─ 输出:conflict-resolution.json
      └─ conflictRisk < medium → 跳过至阶段5

阶段5:TDD任务生成
   └─ 参考:phases/05-tdd-task-generation.md
      ├─ 附加任务:发现 → 规划 → 输出
      └─ 输出:IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md

阶段6:TDD结构验证
   └─ 参考:phases/06-tdd-structure-validation.md
      └─ 输出:验证报告 + 计划确认门

计划确认(用户决策门):
   ├─ "验证TDD合规性"(推荐)→ 路由至阶段7(tdd-verify)
   ├─ "开始执行" → Skill(skill="workflow-execute")
   └─ "仅查看状态" → 内联显示会话状态

Verify Mode

Verify模式

Phase 7: TDD Verification
   └─ Ref: phases/07-tdd-verify.md
      └─ Output: TDD_COMPLIANCE_REPORT.md with quality gate recommendation
Phase Reference Documents (read on-demand when phase executes):
PhaseDocumentPurposeModeCompact
1phases/01-session-discovery.mdCreate or discover TDD workflow sessionplanTodoWrite 驱动
2phases/02-context-gathering.mdGather project context and analyze codebaseplanTodoWrite 驱动
3phases/03-test-coverage-analysis.mdAnalyze test coverage and framework detectionplanTodoWrite 驱动
4phases/04-conflict-resolution.mdDetect and resolve conflicts (conditional)planTodoWrite 驱动
5phases/05-tdd-task-generation.mdGenerate TDD tasks with Red-Green-Refactor cyclesplanTodoWrite 驱动 + 🔄 sentinel
6phases/06-tdd-structure-validation.mdValidate TDD structure and present confirmation gateplanTodoWrite 驱动 + 🔄 sentinel
7phases/07-tdd-verify.mdFull TDD compliance verification with quality gateverifyTodoWrite 驱动
Compact Rules:
  1. TodoWrite
    in_progress
    → 保留完整内容,禁止压缩
  2. TodoWrite
    completed
    → 可压缩为摘要
  3. 🔄 sentinel fallback → Phase 5/6 包含 compact sentinel;若 compact 后仅存 sentinel 而无完整 Step 协议,必须立即
    Read()
    恢复对应 phase 文件
阶段7:TDD验证
   └─ 参考:phases/07-tdd-verify.md
      └─ 输出:带有质量门建议的TDD_COMPLIANCE_REPORT.md
阶段参考文档(仅当即将执行该阶段时才读取):
阶段文档目的模式压缩规则
1phases/01-session-discovery.md创建或发现TDD工作流会话planTodoWrite 驱动
2phases/02-context-gathering.md收集项目上下文并分析代码库planTodoWrite 驱动
3phases/03-test-coverage-analysis.md分析测试覆盖情况并检测框架planTodoWrite 驱动
4phases/04-conflict-resolution.md检测并解决冲突(条件触发)planTodoWrite 驱动
5phases/05-tdd-task-generation.md生成含红-绿-重构周期的TDD任务planTodoWrite 驱动 + 🔄 sentinel
6phases/06-tdd-structure-validation.md验证TDD结构并呈现确认门planTodoWrite 驱动 + 🔄 sentinel
7phases/07-tdd-verify.md完整TDD合规性验证及质量门verifyTodoWrite 驱动
压缩规则:
  1. TodoWrite
    in_progress
    → 保留完整内容,禁止压缩
  2. TodoWrite
    completed
    → 可压缩为摘要
  3. 🔄 sentinel兜底 → 阶段5/6包含压缩sentinel;若压缩后仅存sentinel而无完整Step协议,必须立即
    Read()
    恢复对应阶段文件

Core Rules

核心规则

  1. Start Immediately: First action is mode detection + TaskCreate initialization, second action is phase execution
  2. No Preliminary Analysis: Do not read files, analyze structure, or gather context before Phase 1
  3. Parse Every Output: Extract required data from each phase output for next phase
  4. Auto-Continue via TaskList: Check TaskList status to execute next pending phase automatically
  5. Track Progress: Update TaskCreate/TaskUpdate dynamically with task attachment/collapse pattern
  6. Task Attachment Model: Skill execute attaches sub-tasks to current workflow. Orchestrator executes these attached tasks itself, then collapses them after completion
  7. Progressive Phase Loading: Read phase docs ONLY when that phase is about to execute
  8. DO NOT STOP: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
  9. TDD Context: All descriptions include "TDD:" prefix
  1. 立即启动:第一个操作是模式检测 + TaskCreate初始化,第二个操作是阶段执行
  2. 无前置分析:在阶段1之前不读取文件、不分析结构、不收集上下文
  3. 解析所有输出:从每个阶段输出中提取所需数据用于下一阶段
  4. 通过任务列表自动继续:检查TaskList状态以自动执行下一个待处理阶段
  5. 跟踪进度:使用任务附加/折叠模式动态更新TaskCreate/TaskUpdate
  6. 任务附加模型:技能执行将子任务附加到当前工作流。协调器自行执行这些附加任务,完成后将其折叠
  7. 渐进式阶段加载:仅当即将执行该阶段时才读取阶段文档
  8. 不要停止:连续多阶段工作流。执行完所有附加任务后,立即折叠它们并执行下一阶段
  9. TDD上下文:所有描述均包含"TDD:"前缀

TDD Compliance Requirements

TDD合规要求

The Iron Law

铁律

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Enforcement Method:
  • Phase 5:
    implementation
    includes test-first steps (Red → Green → Refactor)
  • Green phase: Includes test-fix-cycle configuration (max 3 iterations)
  • Auto-revert: Triggered when max iterations reached without passing tests
Verification: Phase 6 validates Red-Green-Refactor structure in all generated tasks
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
执行方法:
  • 阶段5:
    implementation
    包含测试优先步骤(红 → 绿 → 重构)
  • 绿阶段:包含测试修复周期配置(最多3次迭代)
  • 自动回滚:当达到最大迭代次数仍未通过测试时触发
验证:阶段6验证所有生成任务中的红-绿-重构结构

TDD Compliance Checkpoint

TDD合规检查点

CheckpointValidation PhaseEvidence Required
Test-first structurePhase 5
implementation
has 3 steps
Red phase existsPhase 6Step 1:
tdd_phase: "red"
Green phase with test-fixPhase 6Step 2:
tdd_phase: "green"
+ test-fix-cycle
Refactor phase existsPhase 6Step 3:
tdd_phase: "refactor"
检查点验证阶段所需证据
测试优先结构阶段5
implementation
包含3个步骤
红阶段存在阶段6步骤1:
tdd_phase: "red"
含测试修复的绿阶段阶段6步骤2:
tdd_phase: "green"
+ 测试修复周期
重构阶段存在阶段6步骤3:
tdd_phase: "refactor"

Core TDD Principles

核心TDD原则

Red Flags - STOP and Reassess:
  • Code written before test
  • Test passes immediately (no Red phase witnessed)
  • Cannot explain why test should fail
  • "Just this once" rationalization
  • "Tests after achieve same goals" thinking
Why Order Matters:
  • Tests written after code pass immediately → proves nothing
  • Test-first forces edge case discovery before implementation
  • Tests-after verify what was built, not what's required
红色警示 - 停止并重新评估:
  • 在编写测试前编写生产代码
  • 测试立即通过(未经历红阶段)
  • 无法解释测试为何应该失败
  • “就这一次”的合理化借口
  • “事后测试达到相同目标”的想法
为何顺序重要:
  • 代码编写后再写测试会立即通过 → 无法证明任何事情
  • 测试优先迫使在实现前发现边缘情况
  • 事后测试仅验证已构建的内容,而非所需的内容

Input Processing

输入处理

Convert User Input to TDD Structured Format:
  1. Simple text → Add TDD context:
    User: "Build authentication system"
    
    Structured:
    TDD: Authentication System
    GOAL: Build authentication system
    SCOPE: Core authentication features
    CONTEXT: New implementation
    TEST_FOCUS: Authentication scenarios
  2. Detailed text → Extract components with TEST_FOCUS:
    User: "Add JWT authentication with email/password login and token refresh"
    
    Structured:
    TDD: JWT Authentication
    GOAL: Implement JWT-based authentication
    SCOPE: Email/password login, token generation, token refresh endpoints
    CONTEXT: JWT token-based security, refresh token rotation
    TEST_FOCUS: Login flow, token validation, refresh rotation, error cases
  3. File/Issue → Read and structure with TDD
将用户输入转换为TDD结构化格式:
  1. 简单文本 → 添加TDD上下文:
    用户: "构建认证系统"
    
    结构化:
    TDD: 认证系统
    GOAL: 构建认证系统
    SCOPE: 核心认证功能
    CONTEXT: 全新实现
    TEST_FOCUS: 认证场景
  2. 详细文本 → 提取含TEST_FOCUS的组件:
    用户: "添加支持邮箱/密码登录和令牌刷新的JWT认证"
    
    结构化:
    TDD: JWT认证
    GOAL: 实现基于JWT的认证
    SCOPE: 邮箱/密码登录、令牌生成、令牌刷新端点
    CONTEXT: JWT令牌安全、刷新令牌轮换
    TEST_FOCUS: 登录流程、令牌验证、刷新轮换、错误场景
  3. 文件/问题 → 读取并以TDD格式结构化

Data Flow

数据流

Plan Mode

Plan模式

User Input (task description)
[Convert to TDD Structured Format]
    ↓ Structured Description:
    ↓   TDD: [Feature Name]
    ↓   GOAL: [objective]
    ↓   SCOPE: [boundaries]
    ↓   CONTEXT: [background]
    ↓   TEST_FOCUS: [test scenarios]
Phase 1: session:start --auto "TDD: structured-description"
    ↓ Output: sessionId
Phase 2: context-gather --session sessionId "structured-description"
    ↓ Input: sessionId + structured description
    ↓ Output: contextPath (context-package.json) + conflictRisk
Phase 3: test-context-gather --session sessionId
    ↓ Input: sessionId
    ↓ Output: testContextPath (test-context-package.json)
Phase 4: conflict-resolution [conditional: conflictRisk ≥ medium]
    ↓ Input: sessionId + contextPath + conflictRisk
    ↓ Output: conflict-resolution.json
    ↓ Skip if conflictRisk is none/low → proceed directly to Phase 5
Phase 5: task-generate-tdd --session sessionId
    ↓ Input: sessionId + all accumulated context
    ↓ Output: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
Phase 6: TDD Structure Validation (internal)
    ↓ Validate Red-Green-Refactor structure
    ↓ Present Plan Confirmation Gate
Plan Confirmation (User Decision Gate):
    ├─ "Verify TDD Compliance" (Recommended) → Route to Phase 7
    ├─ "Start Execution" → Skill(skill="workflow-execute")
    └─ "Review Status Only" → Display session status inline
用户输入(任务描述)
[转换为TDD结构化格式]
    ↓ 结构化描述:
    ↓   TDD: [功能名称]
    ↓   GOAL: [目标]
    ↓   SCOPE: [边界]
    ↓   CONTEXT: [背景]
    ↓   TEST_FOCUS: [测试场景]
阶段1: session:start --auto "TDD: structured-description"
    ↓ 输出: sessionId
阶段2: context-gather --session sessionId "structured-description"
    ↓ 输入: sessionId + 结构化描述
    ↓ 输出: contextPath (context-package.json) + conflictRisk
阶段3: test-context-gather --session sessionId
    ↓ 输入: sessionId
    ↓ 输出: testContextPath (test-context-package.json)
阶段4: conflict-resolution [条件: conflictRisk ≥ medium]
    ↓ 输入: sessionId + contextPath + conflictRisk
    ↓ 输出: conflict-resolution.json
    ↓ 若conflictRisk为none/low则跳过 → 直接进入阶段5
阶段5: task-generate-tdd --session sessionId
    ↓ 输入: sessionId + 所有累积上下文
    ↓ 输出: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
阶段6: TDD结构验证(内部)
    ↓ 验证红-绿-重构结构
    ↓ 呈现计划确认门
计划确认(用户决策门):
    ├─ "验证TDD合规性"(推荐)→ 路由至阶段7
    ├─ "开始执行" → Skill(skill="workflow-execute")
    └─ "仅查看状态" → 内联显示会话状态

Verify Mode

Verify模式

Input: --session sessionId (or auto-detect)
Phase 7: Session discovery → Chain validation → Coverage analysis → Report
    ↓ Output: TDD_COMPLIANCE_REPORT.md with quality gate
Session Memory Flow: Each phase receives session ID, which provides access to:
  • Previous task summaries
  • Existing context and analysis
  • Session-specific configuration
输入: --session sessionId(或自动检测)
阶段7: 会话发现 → 链验证 → 覆盖分析 → 报告
    ↓ 输出: 带有质量门的TDD_COMPLIANCE_REPORT.md
会话内存流:每个阶段接收会话ID,通过它可访问:
  • 先前的任务摘要
  • 现有上下文和分析
  • 会话特定配置

TodoWrite Pattern

TodoWrite模式

Core Concept: Dynamic task attachment and collapse for real-time visibility into TDD workflow execution.
Implementation Note: Phase files use
TodoWrite
syntax to describe the conceptual tracking pattern. At runtime, these are implemented via
TaskCreate/TaskUpdate/TaskList
tools. Map as follows:
  • Initial list creation →
    TaskCreate
    for each item
  • Status changes →
    TaskUpdate({ taskId, status })
  • Sub-task attachment →
    TaskCreate
    +
    TaskUpdate({ addBlockedBy })
  • Sub-task collapse →
    TaskUpdate({ status: "completed" })
    +
    TaskUpdate({ status: "deleted" })
    for collapsed sub-items
核心概念:动态任务附加与折叠,用于实时查看TDD工作流执行情况。
实现说明:阶段文件使用
TodoWrite
语法描述概念性跟踪模式。在运行时,这些通过
TaskCreate/TaskUpdate/TaskList
工具实现。映射关系如下:
  • 初始列表创建 → 为每个项目执行
    TaskCreate
  • 状态变更 →
    TaskUpdate({ taskId, status })
  • 子任务附加 →
    TaskCreate
    +
    TaskUpdate({ addBlockedBy })
  • 子任务折叠 →
    TaskUpdate({ status: "completed" })
    + 对折叠子项执行`TaskUpdate({ status: "deleted" })

Key Principles

核心原则

  1. Task Attachment (when phase executed):
    • Sub-tasks are attached to orchestrator's TodoWrite
    • Phase 3, 4, 5: Multiple sub-tasks attached
    • Phase 1, 2, 6: Single task (atomic)
    • First attached task marked as
      in_progress
      , others as
      pending
    • Orchestrator executes these attached tasks sequentially
  2. Task Collapse (after sub-tasks complete):
    • Applies to Phase 3, 4, 5: Remove detailed sub-tasks from TodoWrite
    • Collapse to high-level phase summary
    • Phase 1, 2, 6: No collapse needed (single task, just mark completed)
    • Maintains clean orchestrator-level view
  3. Continuous Execution: After completion, automatically proceed to next pending phase
Lifecycle: Initial pending → Phase executed (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED for 3/4/5, marked completed for 1/2/6) → Next phase → Repeat
  1. 任务附加(阶段执行时):
    • 子任务被附加到协调器的TodoWrite
    • 阶段3、4、5:附加多个子任务
    • 阶段1、2、6:单个任务(原子性)
    • 第一个附加任务标记为
      in_progress
      ,其他标记为
      pending
    • 协调器按顺序执行这些附加任务
  2. 任务折叠(子任务完成后):
    • 适用于阶段3、4、5:从TodoWrite中移除详细子任务
    • 折叠为高级阶段摘要
    • 阶段1、2、6:无需折叠(单个任务,仅标记为完成)
    • 保持协调器级别的清晰视图
  3. 连续执行:完成后自动进行下一个待处理阶段
生命周期:初始pending → 阶段执行(任务被附加)→ 子任务按顺序执行 → 阶段完成(3/4/5的任务被折叠,1/2/6的任务标记为完成)→ 下一阶段 → 重复

Initial State (Plan Mode):

初始状态(Plan模式):

json
[
  {"content": "Phase 1: Session Discovery", "status": "in_progress", "activeForm": "Executing session discovery"},
  {"content": "Phase 2: Context Gathering", "status": "pending", "activeForm": "Executing context gathering"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "pending", "activeForm": "Executing test coverage analysis"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending", "activeForm": "Executing TDD task generation"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending", "activeForm": "Validating TDD structure"}
]
Note: Phase 4 (Conflict Resolution) is added dynamically after Phase 2 if conflictRisk ≥ medium.
json
[
  {"content": "Phase 1: Session Discovery", "status": "in_progress", "activeForm": "Executing session discovery"},
  {"content": "Phase 2: Context Gathering", "status": "pending", "activeForm": "Executing context gathering"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "pending", "activeForm": "Executing test coverage analysis"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending", "activeForm": "Executing TDD task generation"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending", "activeForm": "Validating TDD structure"}
]
注意:阶段4(冲突解决)在阶段2后若conflictRisk ≥ medium则动态添加。

Phase 3 (Tasks Attached):

阶段3(任务附加后):

json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "in_progress"},
  {"content": "  → Detect test framework and conventions", "status": "in_progress"},
  {"content": "  → Analyze existing test coverage", "status": "pending"},
  {"content": "  → Identify coverage gaps", "status": "pending"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]
json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "in_progress"},
  {"content": "  → Detect test framework and conventions", "status": "in_progress"},
  {"content": "  → Analyze existing test coverage", "status": "pending"},
  {"content": "  → Identify coverage gaps", "status": "pending"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]

Phase 3 (Collapsed):

阶段3(折叠后):

json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]
json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]

Phase 5 (Tasks Attached):

阶段5(任务附加后):

json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "in_progress"},
  {"content": "  → Discovery - analyze TDD requirements", "status": "in_progress"},
  {"content": "  → Planning - design Red-Green-Refactor cycles", "status": "pending"},
  {"content": "  → Output - generate IMPL tasks with internal TDD phases", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]
Note: See individual Phase descriptions for detailed TodoWrite Update examples.
json
[
  {"content": "Phase 1: Session Discovery", "status": "completed"},
  {"content": "Phase 2: Context Gathering", "status": "completed"},
  {"content": "Phase 3: Test Coverage Analysis", "status": "completed"},
  {"content": "Phase 5: TDD Task Generation", "status": "in_progress"},
  {"content": "  → Discovery - analyze TDD requirements", "status": "in_progress"},
  {"content": "  → Planning - design Red-Green-Refactor cycles", "status": "pending"},
  {"content": "  → Output - generate IMPL tasks with internal TDD phases", "status": "pending"},
  {"content": "Phase 6: TDD Structure Validation", "status": "pending"}
]
注意:详细的TodoWrite更新示例请参阅各阶段描述。

Post-Phase Updates

阶段后更新

Memory State Check

内存状态检查

After heavy phases (Phase 2-3), evaluate context window usage:
  • If memory usage is high (>110K tokens or approaching context limits):
    javascript
    Skill(skill="memory-capture")
  • Memory compaction is particularly important after analysis phases
在重负载阶段(阶段2-3)后,评估上下文窗口使用情况:
  • 若内存使用率高(>110K tokens或接近上下文限制):
    javascript
    Skill(skill="memory-capture")
  • 分析阶段后的内存压缩尤为重要

Planning Notes (Optional)

规划笔记(可选)

Similar to workflow-plan, a
planning-notes.md
can accumulate context across phases if needed. See Phase 1 for initialization.
与workflow-plan类似,若需要可通过
planning-notes.md
跨阶段累积上下文。请参阅阶段1了解初始化方法。

Error Handling

错误处理

  • Parsing Failure: If output parsing fails, retry command once, then report error
  • Validation Failure: Report which file/data is missing or invalid
  • Command Failure: Keep phase
    in_progress
    , report error to user, do not proceed
  • TDD Validation Failure: Report incomplete chains or wrong dependencies
  • Session Not Found (verify mode): Report error with available sessions list
  • 解析失败:若输出解析失败,重试命令一次,然后报告错误
  • 验证失败:报告缺少或无效的文件/数据
  • 命令失败:保持阶段
    in_progress
    ,向用户报告错误,不继续执行
  • TDD验证失败:报告不完整的链或错误的依赖关系
  • 会话未找到(verify模式):报告错误并列出可用会话

Error Handling Quick Reference

错误处理速查表

Error TypeDetectionRecovery Action
Parsing failureEmpty/malformed outputRetry once, then report
Missing context-packageFile read errorRe-run Phase 2 (context-gathering)
Invalid task JSONjq parse errorReport malformed file path
Task count exceeds 18Count validation ≥19Request re-scope, split into multiple sessions
Missing cli_execution.idAll tasks lack IDRegenerate tasks with phase 0 user config
Test-context missingFile not foundRe-run Phase 3 (test-coverage-analysis)
Phase timeoutNo responseRetry phase, check CLI connectivity
CLI tool not availableTool not in cli-tools.jsonFall back to alternative preferred tool
错误类型检测方式恢复操作
解析失败输出为空/格式错误重试一次,然后报告
缺少context-package文件读取错误重新运行阶段2(上下文收集)
无效任务JSONjq解析错误报告格式错误的文件路径
任务数超过18计数验证≥19请求重新划定范围,拆分为多个会话
缺少cli_execution.id所有任务均无ID使用阶段0用户配置重新生成任务
缺少test-context文件未找到重新运行阶段3(测试覆盖分析)
阶段超时无响应重试阶段,检查CLI连接性
CLI工具不可用工具不在cli-tools.json中回退到替代首选工具

TDD Warning Patterns

TDD警告模式

PatternWarning MessageRecommended Action
Task count >10High task count detectedConsider splitting into multiple sessions
Missing test-fix-cycleGreen phase lacks auto-revertAdd
max_iterations: 3
to task config
Red phase missing test pathTest file path not specifiedAdd explicit test file paths
Generic task namesVague names like "Add feature"Use specific behavior descriptions
No refactor criteriaRefactor phase lacks completion criteriaDefine clear refactor scope
模式警告消息推荐操作
任务数>10检测到任务数过多考虑拆分为多个会话
缺少test-fix-cycle绿阶段缺少自动回滚向任务配置添加
max_iterations: 3
红阶段缺少测试路径未指定测试文件路径添加明确的测试文件路径
通用任务名称模糊名称如"Add feature"使用具体的行为描述
无重构标准重构阶段缺少完成标准定义清晰的重构范围

Non-Blocking Warning Policy

非阻塞警告策略

All warnings are advisory - they do not halt execution:
  1. Warnings logged to
    .process/tdd-warnings.log
  2. Summary displayed in Phase 6 output
  3. User decides whether to address before
    workflow-execute
    skill
所有警告均为建议性 - 不会停止执行:
  1. 警告记录到
    .process/tdd-warnings.log
  2. 摘要显示在阶段6输出中
  3. 用户决定在执行
    workflow-execute
    技能前是否处理

Coordinator Checklist

协调器检查清单

Plan Mode

Plan模式

  • Pre-Phase: Convert user input to TDD structured format (TDD/GOAL/SCOPE/CONTEXT/TEST_FOCUS)
  • Initialize TaskCreate before any command (Phase 4 added dynamically after Phase 2)
  • Execute Phase 1 immediately with structured description
  • Parse session ID from Phase 1 output, store in memory
  • Pass session ID and structured description to Phase 2 command
  • Parse context path from Phase 2 output, store in memory
  • Extract conflictRisk from context-package.json: Determine Phase 4 execution
  • Execute Phase 3 (test coverage analysis) with sessionId
  • Parse testContextPath from Phase 3 output, store in memory
  • If conflictRisk ≥ medium: Launch Phase 4 conflict-resolution with sessionId and contextPath
  • Wait for Phase 4 to finish executing (if executed), verify conflict-resolution.json created
  • If conflictRisk is none/low: Skip Phase 4, proceed directly to Phase 5
  • Pass session ID to Phase 5 command (TDD task generation)
  • Verify all Phase 5 outputs (IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md)
  • Execute Phase 6 (internal TDD structure validation)
  • Plan Confirmation Gate: Present user with choice (Verify → Phase 7 / Execute / Review Status)
  • If user selects Verify: Read phases/07-tdd-verify.md, execute Phase 7 in-process
  • If user selects Execute: Skill(skill="workflow-execute")
  • If user selects Review: Display session status inline
  • Auto mode (workflowPreferences.autoYes): Auto-select "Verify TDD Compliance", then auto-continue to execute if APPROVED
  • Update TaskCreate/TaskUpdate after each phase
  • After each phase, automatically continue to next phase based on TaskList status
  • 阶段前:将用户输入转换为TDD结构化格式(TDD/GOAL/SCOPE/CONTEXT/TEST_FOCUS)
  • 在任何命令前初始化TaskCreate(阶段4在阶段2后动态添加)
  • 使用结构化描述立即执行阶段1
  • 从阶段1输出中解析会话ID,存储到内存
  • 将会话ID和结构化描述传递给阶段2命令
  • 从阶段2输出中解析contextPath,存储到内存
  • 从context-package.json中提取conflictRisk:决定是否执行阶段4
  • 使用sessionId执行阶段3(测试覆盖分析)
  • 从阶段3输出中解析testContextPath,存储到内存
  • 若conflictRisk ≥ medium:使用sessionId和contextPath启动阶段4冲突解决
  • 等待阶段4完成执行(若已执行),验证conflict-resolution.json已创建
  • 若conflictRisk为none/low:跳过阶段4,直接进入阶段5
  • 将会话ID传递给阶段5命令(TDD任务生成)
  • 验证阶段5的所有输出(IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md)
  • 执行阶段6(内部TDD结构验证)
  • 计划确认门:向用户呈现选项(验证 → 阶段7 / 执行 / 查看状态)
  • 若用户选择验证:读取phases/07-tdd-verify.md,在进程内执行阶段7
  • 若用户选择执行:Skill(skill="workflow-execute")
  • 若用户选择查看:内联显示会话状态
  • 自动模式(workflowPreferences.autoYes):自动选择“验证TDD合规性”,若通过则自动继续执行
  • 每个阶段后更新TaskCreate/TaskUpdate
  • 每个阶段后,根据TaskList状态自动继续执行下一阶段

Verify Mode

Verify模式

  • Detect/validate session (from --session flag or auto-detect)
  • Initialize TaskCreate with verification tasks
  • Execute Phase 7 through all sub-phases (session validation → chain validation → coverage analysis → report generation)
  • Present quality gate result and next step options
  • 检测/验证会话(来自--session标志或自动检测)
  • 初始化带有验证任务的TaskCreate
  • 通过所有子阶段执行阶段7(会话验证 → 链验证 → 覆盖分析 → 报告生成)
  • 呈现质量门结果和下一步选项

Related Skills

相关技能

Prerequisite Skills:
  • None - TDD planning is self-contained (can optionally run brainstorm commands before)
Called by Plan Mode (6 phases):
  • /workflow:session:start
    - Phase 1: Create or discover TDD workflow session
  • phases/02-context-gathering.md
    - Phase 2: Gather project context and analyze codebase (inline)
  • phases/03-test-coverage-analysis.md
    - Phase 3: Analyze existing test patterns and coverage (inline)
  • phases/04-conflict-resolution.md
    - Phase 4: Detect and resolve conflicts (inline, conditional)
  • memory-capture
    skill - Phase 4: Memory optimization (if context approaching limits)
  • phases/05-tdd-task-generation.md
    - Phase 5: Generate TDD tasks with Red-Green-Refactor cycles (inline)
Called by Verify Mode:
  • phases/07-tdd-verify.md
    - Phase 7: Test coverage and cycle analysis (inline)
Follow-up Skills:
  • workflow-tdd-plan
    skill (tdd-verify phase) - Verify TDD compliance (can also invoke via verify mode)
  • workflow-plan
    skill (plan-verify phase) - Verify plan quality and dependencies
  • Display session status inline - Review TDD task breakdown
  • Skill(skill="workflow-execute")
    - Begin TDD implementation
前置技能:
  • 无 - TDD规划是自包含的(可选在之前运行头脑风暴命令)
Plan模式调用(6个阶段):
  • /workflow:session:start
    - 阶段1:创建或发现TDD工作流会话
  • phases/02-context-gathering.md
    - 阶段2:收集项目上下文并分析代码库(内联)
  • phases/03-test-coverage-analysis.md
    - 阶段3:分析现有测试模式和覆盖情况(内联)
  • phases/04-conflict-resolution.md
    - 阶段4:检测并解决冲突(内联,条件触发)
  • memory-capture
    技能 - 阶段4:内存优化(若上下文接近限制)
  • phases/05-tdd-task-generation.md
    - 阶段5:生成含红-绿-重构周期的TDD任务(内联)
Verify模式调用:
  • phases/07-tdd-verify.md
    - 阶段7:测试覆盖和周期分析(内联)
后续技能:
  • workflow-tdd-plan
    技能(tdd-verify阶段)- 验证TDD合规性(也可通过verify模式调用)
  • workflow-plan
    技能(plan-verify阶段)- 验证计划质量和依赖关系
  • 内联显示会话状态 - 查看TDD任务细分
  • Skill(skill="workflow-execute")
    - 开始TDD实现