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

核心设计原则

Pure Orchestrator: SKILL.md routes and coordinates only; execution detail lives in phase files
Progressive Phase Loading: Read phase docs ONLY when that phase is about to execute
Multi-Mode Routing: Single skill handles plan/verify via mode detection
Task Attachment Model: Sub-command tasks are ATTACHED, executed sequentially, then COLLAPSED
Auto-Continue: After each phase completes, automatically execute next pending phase
TDD Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST - enforced in task structure

纯协调器：SKILL.md仅负责路由与协调；执行细节存于阶段文件中
渐进式阶段加载：仅当即将执行某阶段时才读取该阶段文档
多模式路由：单个技能通过模式检测处理plan/verify两种模式
任务附加模型：子命令任务被附加到当前工作流，按顺序执行后折叠
自动继续：每个阶段完成后，自动执行下一个待处理阶段
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):

Phase	Document	Purpose	Mode	Compact
1	phases/01-session-discovery.md	Create or discover TDD workflow session	plan	TodoWrite 驱动
2	phases/02-context-gathering.md	Gather project context and analyze codebase	plan	TodoWrite 驱动
3	phases/03-test-coverage-analysis.md	Analyze test coverage and framework detection	plan	TodoWrite 驱动
4	phases/04-conflict-resolution.md	Detect and resolve conflicts (conditional)	plan	TodoWrite 驱动
5	phases/05-tdd-task-generation.md	Generate TDD tasks with Red-Green-Refactor cycles	plan	TodoWrite 驱动 + 🔄 sentinel
6	phases/06-tdd-structure-validation.md	Validate TDD structure and present confirmation gate	plan	TodoWrite 驱动 + 🔄 sentinel
7	phases/07-tdd-verify.md	Full TDD compliance verification with quality gate	verify	TodoWrite 驱动

Compact Rules:

TodoWrite
in_progress
→ 保留完整内容，禁止压缩
TodoWrite
completed
→ 可压缩为摘要
🔄 sentinel fallback → Phase 5/6 包含 compact sentinel；若 compact 后仅存 sentinel 而无完整 Step 协议，必须立即
```
Read()
```
恢复对应 phase 文件

阶段7：TDD验证
   └─ 参考：phases/07-tdd-verify.md
      └─ 输出：带有质量门建议的TDD_COMPLIANCE_REPORT.md

阶段参考文档（仅当即将执行该阶段时才读取）：

阶段	文档	目的	模式	压缩规则
1	phases/01-session-discovery.md	创建或发现TDD工作流会话	plan	TodoWrite 驱动
2	phases/02-context-gathering.md	收集项目上下文并分析代码库	plan	TodoWrite 驱动
3	phases/03-test-coverage-analysis.md	分析测试覆盖情况并检测框架	plan	TodoWrite 驱动
4	phases/04-conflict-resolution.md	检测并解决冲突（条件触发）	plan	TodoWrite 驱动
5	phases/05-tdd-task-generation.md	生成含红-绿-重构周期的TDD任务	plan	TodoWrite 驱动 + 🔄 sentinel
6	phases/06-tdd-structure-validation.md	验证TDD结构并呈现确认门	plan	TodoWrite 驱动 + 🔄 sentinel
7	phases/07-tdd-verify.md	完整TDD合规性验证及质量门	verify	TodoWrite 驱动

压缩规则:

TodoWrite
in_progress
→ 保留完整内容，禁止压缩
TodoWrite
completed
→ 可压缩为摘要
🔄 sentinel兜底 → 阶段5/6包含压缩sentinel；若压缩后仅存sentinel而无完整Step协议，必须立即
```
Read()
```
恢复对应阶段文件

Core Rules

核心规则

Start Immediately: First action is mode detection + TaskCreate initialization, second action is phase execution
No Preliminary Analysis: Do not read files, analyze structure, or gather context before Phase 1
Parse Every Output: Extract required data from each phase output for next phase
Auto-Continue via TaskList: Check TaskList status to execute next pending phase automatically
Track Progress: Update TaskCreate/TaskUpdate dynamically with task attachment/collapse pattern
Task Attachment Model: Skill execute attaches sub-tasks to current workflow. Orchestrator executes these attached tasks itself, then collapses them after completion
Progressive Phase Loading: Read phase docs ONLY when that phase is about to execute
DO NOT STOP: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
TDD Context: All descriptions include "TDD:" prefix

立即启动：第一个操作是模式检测 + TaskCreate初始化，第二个操作是阶段执行
无前置分析：在阶段1之前不读取文件、不分析结构、不收集上下文
解析所有输出：从每个阶段输出中提取所需数据用于下一阶段
通过任务列表自动继续：检查TaskList状态以自动执行下一个待处理阶段
跟踪进度：使用任务附加/折叠模式动态更新TaskCreate/TaskUpdate
任务附加模型：技能执行将子任务附加到当前工作流。协调器自行执行这些附加任务，完成后将其折叠
渐进式阶段加载：仅当即将执行该阶段时才读取阶段文档
不要停止：连续多阶段工作流。执行完所有附加任务后，立即折叠它们并执行下一阶段
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合规检查点

Checkpoint	Validation Phase	Evidence Required
Test-first structure	Phase 5	`implementation` has 3 steps
Red phase exists	Phase 6	Step 1: `tdd_phase: "red"`
Green phase with test-fix	Phase 6	Step 2: `tdd_phase: "green"` + test-fix-cycle
Refactor phase exists	Phase 6	Step 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:

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

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

File/Issue → Read and structure with TDD

将用户输入转换为TDD结构化格式:

简单文本 → 添加TDD上下文:

用户: "构建认证系统"

结构化:
TDD: 认证系统
GOAL: 构建认证系统
SCOPE: 核心认证功能
CONTEXT: 全新实现
TEST_FOCUS: 认证场景

详细文本 → 提取含TEST_FOCUS的组件:

用户: "添加支持邮箱/密码登录和令牌刷新的JWT认证"

结构化:
TDD: JWT认证
GOAL: 实现基于JWT的认证
SCOPE: 邮箱/密码登录、令牌生成、令牌刷新端点
CONTEXT: JWT令牌安全、刷新令牌轮换
TEST_FOCUS: 登录流程、令牌验证、刷新轮换、错误场景

文件/问题 → 读取并以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

核心原则

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
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
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

任务附加（阶段执行时）:
- 子任务被附加到协调器的TodoWrite
- 阶段3、4、5：附加多个子任务
- 阶段1、2、6：单个任务（原子性）
- 第一个附加任务标记为
```
in_progress
```
  ，其他标记为
```
pending
```
- 协调器按顺序执行这些附加任务
任务折叠（子任务完成后）:
- 适用于阶段3、4、5：从TodoWrite中移除详细子任务
- 折叠为高级阶段摘要
- 阶段1、2、6：无需折叠（单个任务，仅标记为完成）
- 保持协调器级别的清晰视图
连续执行：完成后自动进行下一个待处理阶段

生命周期：初始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 Type	Detection	Recovery Action
Parsing failure	Empty/malformed output	Retry once, then report
Missing context-package	File read error	Re-run Phase 2 (context-gathering)
Invalid task JSON	jq parse error	Report malformed file path
Task count exceeds 18	Count validation ≥19	Request re-scope, split into multiple sessions
Missing cli_execution.id	All tasks lack ID	Regenerate tasks with phase 0 user config
Test-context missing	File not found	Re-run Phase 3 (test-coverage-analysis)
Phase timeout	No response	Retry phase, check CLI connectivity
CLI tool not available	Tool not in cli-tools.json	Fall back to alternative preferred tool

错误类型	检测方式	恢复操作
解析失败	输出为空/格式错误	重试一次，然后报告
缺少context-package	文件读取错误	重新运行阶段2（上下文收集）
无效任务JSON	jq解析错误	报告格式错误的文件路径
任务数超过18	计数验证≥19	请求重新划定范围，拆分为多个会话
缺少cli_execution.id	所有任务均无ID	使用阶段0用户配置重新生成任务
缺少test-context	文件未找到	重新运行阶段3（测试覆盖分析）
阶段超时	无响应	重试阶段，检查CLI连接性
CLI工具不可用	工具不在cli-tools.json中	回退到替代首选工具

TDD Warning Patterns

TDD警告模式

Pattern	Warning Message	Recommended Action
Task count >10	High task count detected	Consider splitting into multiple sessions
Missing test-fix-cycle	Green phase lacks auto-revert	Add `max_iterations: 3` to task config
Red phase missing test path	Test file path not specified	Add explicit test file paths
Generic task names	Vague names like "Add feature"	Use specific behavior descriptions
No refactor criteria	Refactor phase lacks completion criteria	Define 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:

Warnings logged to
```
.process/tdd-warnings.log
```
Summary displayed in Phase 6 output
User decides whether to address before
```
workflow-execute
```
skill

所有警告均为建议性 - 不会停止执行:

警告记录到
```
.process/tdd-warnings.log
```
摘要显示在阶段6输出中
用户决定在执行
```
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（会话验证 → 链验证 → 覆盖分析 → 报告生成）
呈现质量门结果和下一步选项

workflow-tdd-plan-plan

Original

Translation

Workflow TDD

工作流TDD

Architecture Overview

架构概述

Key Design Principles

核心设计原则

Interactive Preference Collection

交互式偏好收集

Mode Detection

模式检测

Compact Recovery (Phase Persistence)

紧凑恢复（阶段持久化）

Execution Flow

执行流程

Plan Mode (default)

Plan模式（默认）

Verify Mode

Verify模式

Core Rules

核心规则

TDD Compliance Requirements

TDD合规要求

The Iron Law

铁律

TDD Compliance Checkpoint

TDD合规检查点

Core TDD Principles

核心TDD原则

Input Processing

输入处理

Data Flow

数据流

Plan Mode

Plan模式

Verify Mode

Verify模式

TodoWrite Pattern

TodoWrite模式

Key Principles

核心原则

Initial State (Plan Mode):

初始状态（Plan模式）:

Phase 3 (Tasks Attached):

阶段3（任务附加后）:

Phase 3 (Collapsed):

阶段3（折叠后）:

Phase 5 (Tasks Attached):

阶段5（任务附加后）:

Post-Phase Updates

阶段后更新

Memory State Check

内存状态检查

Planning Notes (Optional)

规划笔记（可选）

Error Handling

错误处理

Error Handling Quick Reference

错误处理速查表

TDD Warning Patterns

TDD警告模式

Non-Blocking Warning Policy

非阻塞警告策略

Coordinator Checklist

协调器检查清单

Plan Mode

Plan模式

Verify Mode

Verify模式

Related Skills

相关技能