⚡

TDD工作流程规划验证技能Skill workflow-tdd

此技能专为软件开发中的测试驱动开发（TDD）设计，提供统一的工作流程，包括TDD规划、任务生成、结构验证和合规检查。它帮助团队遵循TDD原则，确保代码质量。关键词：TDD、测试驱动开发、工作流、规划、验证、任务管理、软件开发、测试。

测试 0 次安装 0 次浏览 更新于 3/16/2026

名称: workflow-tdd 描述: 统一TDD工作流技能，结合6阶段TDD规划和红-绿-重构任务链生成，以及4阶段TDD验证与合规报告。在“workflow:tdd-plan”、“workflow:tdd-verify”上触发。 允许工具: Skill, Task, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep

工作流 TDD

统一TDD工作流技能，结合TDD规划（红-绿-重构任务链生成，带测试优先开发结构）和TDD验证（合规验证与质量门报告）。生成IMPL_PLAN.md、带内部TDD周期的任务JSON和TDD_COMPLIANCE_REPORT.md。

架构概述

┌──────────────────────────────────────────────────────────────────┐
│  工作流 TDD 协调器 (SKILL.md)                                   │
│  → 按模式路由: plan | verify                                    │
│  → 纯协调器: 执行阶段，解析输出，传递上下文                    │
└──────────────────────────────┬───────────────────────────────────┘
                                │
        ┌───────────────────────┴───────────────────────┐
        ↓                                               ↓
  ┌─────────────┐                                ┌───────────┐
  │  规划模式   │                                │   验证    │
  │  (默认)     │                                │   模式    │
  │ 阶段 1-6    │                                │  阶段 7   │
  └──────┬──────┘                                └───────────┘
         │
   ┌─────┼─────┬─────┬─────┬─────┐
   ↓     ↓     ↓     ↓     ↓     ↓
 ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
 │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ 5 │ │ 6 │
 │会话│ │上下文│ │测试│ │冲突│ │生成│ │验证│
 └───┘ └───┘ └───┘ └───┘ └─┬─┘ └───┘
                             ↓
                       ┌───────────┐
                       │   确认    │─── 验证 ──→ 阶段 7
                       │  (选择)   │─── 执行 ──→ Skill("workflow-execute")
                       └───────────┘─── 审查 ──→ 内联显示会话状态

关键设计原则

  1. 纯协调器: SKILL.md仅路由和协调；执行细节存在于阶段文件中
  2. 渐进式阶段加载: 仅在阶段即将执行时读取阶段文档
  3. 多模式路由: 单一技能通过模式检测处理规划/验证
  4. 任务附件模型: 子命令任务被附加，顺序执行，然后折叠
  5. 自动继续: 每个阶段完成后，自动执行下一个待处理阶段
  6. TDD铁律: 没有失败测试之前不编写生产代码 - 在任务结构中强制执行

交互式偏好收集

在分派到阶段执行之前，通过AskUserQuestion收集工作流偏好：

// ★ 统一自动模式检测：-y/--yes 从 $ARGUMENTS 或 ccw 传播
const autoYes = /\b(-y|--yes)\b/.test($ARGUMENTS)

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

  workflowPreferences = {
    autoYes: prefResponse.autoMode === 'Auto'
  }
}

workflowPreferences 作为上下文变量传递给阶段执行，在阶段内引用为 workflowPreferences.autoYes。

模式检测

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

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

执行流程

规划模式（默认）

输入解析:
   └─ 将用户输入转换为TDD结构化格式（目标/范围/上下文/测试焦点）

阶段 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 ≥ 中等）
   └─ 决策（conflictRisk检查）:
      ├─ conflictRisk ≥ 中等 → 参考: phases/04-conflict-resolution.md
      │   ├─ 附加任务: 检测冲突 → 日志分析 → 应用策略
      │   └─ 输出: conflict-resolution.json
      └─ conflictRisk < 中等 → 跳到阶段 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")
      └─ "仅审查状态" → 内联显示会话状态

验证模式

阶段 7: TDD验证
   └─ 参考: phases/07-tdd-verify.md
      └─ 输出: TDD_COMPLIANCE_REPORT.md 带质量门推荐

阶段参考文档（在阶段执行时按需读取）：

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

核心规则

  1. 立即开始: 第一个动作是模式检测 + TaskCreate初始化，第二个动作是阶段执行
  2. 无初步分析: 在阶段1之前不读取文件、分析结构或收集上下文
  3. 解析每个输出: 从每个阶段输出中提取所需数据以供下一阶段使用
  4. 通过TaskList自动继续: 检查TaskList状态以自动执行下一个待处理阶段
  5. 跟踪进度: 使用任务附件/折叠模式动态更新TaskCreate/TaskUpdate
  6. 任务附件模型: 技能执行将子任务附加到当前工作流。协调器本身执行这些附加任务，然后在完成后折叠它们
  7. 渐进式阶段加载: 仅在阶段即将执行时读取阶段文档
  8. 不要停止: 连续多阶段工作流。执行所有附加任务后，立即折叠它们并执行下一阶段
  9. TDD上下文: 所有描述包括“TDD:”前缀

TDD合规要求

铁律

没有失败测试之前不编写生产代码

强制执行方法:

  • 阶段5: implementation 包括测试优先步骤（红 → 绿 → 重构）
  • 绿阶段: 包括测试修复循环配置（最多3次迭代）
  • 自动恢复: 当达到最大迭代次数但测试未通过时触发

验证: 阶段6验证所有生成任务中的红-绿-重构结构

TDD合规检查点

检查点 验证阶段 所需证据
测试优先结构 阶段5 implementation 有3个步骤
红阶段存在 阶段6 步骤1: tdd_phase: "red"
绿阶段带测试修复 阶段6 步骤2: tdd_phase: "green" + test-fix-cycle
重构阶段存在 阶段6 步骤3: tdd_phase: "refactor"

核心TDD原则

红灯 - 停止并重新评估:

  • 在测试之前编写代码
  • 测试立即通过（未见证红阶段）
  • 无法解释为什么测试应该失败
  • “仅此一次”合理化
  • “测试后也能达到相同目标”的想法

为什么顺序重要:

  • 测试在代码后编写立即通过 → 证明不了什么
  • 测试优先迫使在实现前发现边界情况
  • 测试后验证已构建的内容，而不是所需的内容

输入处理

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

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

    用户: “构建认证系统”

结构化:
TDD: 认证系统
目标: 构建认证系统
范围: 核心认证功能
上下文: 新实现
测试焦点: 认证场景

  2. 详细文本 → 提取带测试焦点的组件:

    用户: “添加带电子邮件/密码登录和令牌刷新的JWT认证”

结构化:
TDD: JWT认证
目标: 实现基于JWT的认证
范围: 电子邮件/密码登录、令牌生成、令牌刷新端点
上下文: JWT令牌安全、刷新令牌轮换
测试焦点: 登录流程、令牌验证、刷新轮换、错误案例

  3. 文件/问题 → 读取并用TDD结构化

数据流

规划模式

用户输入（任务描述）
    ↓
[转换为TDD结构化格式]
    ↓ 结构化描述:
    ↓   TDD: [功能名称]
    ↓   目标: [目标]
    ↓   范围: [边界]
    ↓   上下文: [背景]
    ↓   测试焦点: [测试场景]
    ↓
阶段1: session:start --auto "TDD: 结构化描述"
    ↓ 输出: sessionId
    ↓
阶段2: context-gather --session sessionId "结构化描述"
    ↓ 输入: sessionId + 结构化描述
    ↓ 输出: contextPath (context-package.json) + conflictRisk
    ↓
阶段3: test-context-gather --session sessionId
    ↓ 输入: sessionId
    ↓ 输出: testContextPath (test-context-package.json)
    ↓
阶段4: conflict-resolution [条件性: conflictRisk ≥ 中等]
    ↓ 输入: sessionId + contextPath + conflictRisk
    ↓ 输出: conflict-resolution.json
    ↓ 如果conflictRisk为无/低 → 直接进入阶段5
    ↓
阶段5: task-generate-tdd --session sessionId
    ↓ 输入: sessionId + 所有累积上下文
    ↓ 输出: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
    ↓
阶段6: TDD结构验证（内部）
    ↓ 验证红-绿-重构结构
    ↓ 呈现计划确认门
    ↓
计划确认（用户决策门）:
    ├─ “验证TDD合规性”（推荐） → 路由到阶段7
    ├─ “开始执行” → Skill(skill="workflow-execute")
    └─ “仅审查状态” → 内联显示会话状态

验证模式

输入: --session sessionId（或自动检测）
    ↓
阶段7: 会话发现 → 链验证 → 覆盖分析 → 报告
    ↓ 输出: TDD_COMPLIANCE_REPORT.md 带质量门

会话内存流: 每个阶段接收会话ID，提供访问：

  • 先前任务摘要
  • 现有上下文和分析
  • 会话特定配置

TodoWrite模式

核心概念: 动态任务附件和折叠，以实时可见TDD工作流执行。

实现说明: 阶段文件使用 TodoWrite 语法描述概念跟踪模式。在运行时，这些通过 TaskCreate/TaskUpdate/TaskList 工具实现。映射如下：

  • 初始列表创建 → 为每个项目 TaskCreate
  • 状态更改 → TaskUpdate({ taskId, status })
  • 子任务附件 → TaskCreate + TaskUpdate({ addBlockedBy })
  • 子任务折叠 → TaskUpdate({ status: "completed" }) + TaskUpdate({ status: "deleted" }) 用于折叠的子项

关键原则

  1. 任务附件（阶段执行时）：

    • 子任务被附加到协调器的TodoWrite
    • 阶段3, 4, 5: 多个子任务附加
    • 阶段1, 2, 6: 单个任务（原子）
    • 第一个附加任务标记为 in_progress，其他为 pending
    • 协调器顺序执行这些附加任务

  2. 任务折叠（子任务完成后）：

    • 适用于阶段3, 4, 5: 从TodoWrite中移除详细子任务
    • 折叠到高级阶段摘要
    • 阶段1, 2, 6: 无需折叠（单个任务，仅标记完成）
    • 保持协调器级别视图清晰

  3. 连续执行: 完成后，自动进入下一个待处理阶段

生命周期: 初始待处理 → 阶段执行（任务附加） → 子任务顺序执行 → 阶段完成（阶段3/4/5折叠，阶段1/2/6标记完成） → 下一阶段 → 重复

初始状态（规划模式）：

[
  {"content": "阶段1: 会话发现", "status": "in_progress", "activeForm": "执行会话发现"},
  {"content": "阶段2: 上下文收集", "status": "pending", "activeForm": "执行上下文收集"},
  {"content": "阶段3: 测试覆盖分析", "status": "pending", "activeForm": "执行测试覆盖分析"},
  {"content": "阶段5: TDD任务生成", "status": "pending", "activeForm": "执行TDD任务生成"},
  {"content": "阶段6: TDD结构验证", "status": "pending", "activeForm": "验证TDD结构"}
]

注意: 阶段4（冲突解决）在阶段2后动态添加，如果conflictRisk ≥ 中等。

阶段3（任务附加）：

[
  {"content": "阶段1: 会话发现", "status": "completed"},
  {"content": "阶段2: 上下文收集", "status": "completed"},
  {"content": "阶段3: 测试覆盖分析", "status": "in_progress"},
  {"content": "  → 检测测试框架和约定", "status": "in_progress"},
  {"content": "  → 分析现有测试覆盖", "status": "pending"},
  {"content": "  → 识别覆盖差距", "status": "pending"},
  {"content": "阶段5: TDD任务生成", "status": "pending"},
  {"content": "阶段6: TDD结构验证", "status": "pending"}
]

阶段3（折叠）：

[
  {"content": "阶段1: 会话发现", "status": "completed"},
  {"content": "阶段2: 上下文收集", "status": "completed"},
  {"content": "阶段3: 测试覆盖分析", "status": "completed"},
  {"content": "阶段5: TDD任务生成", "status": "pending"},
  {"content": "阶段6: TDD结构验证", "status": "pending"}
]

阶段5（任务附加）：

[
  {"content": "阶段1: 会话发现", "status": "completed"},
  {"content": "阶段2: 上下文收集", "status": "completed"},
  {"content": "阶段3: 测试覆盖分析", "status": "completed"},
  {"content": "阶段5: TDD任务生成", "status": "in_progress"},
  {"content": "  → 发现 - 分析TDD需求", "status": "in_progress"},
  {"content": "  → 规划 - 设计红-绿-重构循环", "status": "pending"},
  {"content": "  → 输出 - 生成带内部TDD阶段的IMPL任务", "status": "pending"},
  {"content": "阶段6: TDD结构验证", "status": "pending"}
]

注意: 见个别阶段描述获取详细TodoWrite更新示例。

阶段后更新

内存状态检查

在重阶段（阶段2-3）后，评估上下文窗口使用：

  • 如果内存使用高（>110K令牌或接近上下文限制）：
    Skill(skill="memory-capture")
  • 内存压缩在分析阶段后尤为重要

规划笔记（可选）

类似于workflow-plan，如果需要，可以跨阶段累积 planning-notes.md。见阶段1以获取初始化。

错误处理

  • 解析失败: 如果输出解析失败，重试命令一次，然后报告错误
  • 验证失败: 报告哪个文件/数据缺失或无效
  • 命令失败: 保持阶段 in_progress，向用户报告错误，不继续
  • TDD验证失败: 报告不完整链或错误依赖
  • 会话未找到（验证模式）: 报告错误，列出可用会话

错误处理快速参考

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

TDD警告模式

模式 警告消息 推荐操作
任务数>10 检测到高任务数 考虑拆分为多个会话
缺少test-fix-cycle 绿阶段缺少自动恢复 添加 max_iterations: 3 到任务配置
红阶段缺少测试路径 未指定测试文件路径 添加显式测试文件路径
通用任务名称 模糊名称如“添加功能” 使用特定行为描述
无重构标准 重构阶段缺少完成标准 定义明确重构范围

非阻塞警告策略

所有警告为建议性 - 它们不停止执行：

  1. 警告记录到 .process/tdd-warnings.log
  2. 摘要显示在阶段6输出中
  3. 用户决定在 workflow-execute 技能前是否处理

协调器清单

规划模式

  • 阶段前: 将用户输入转换为TDD结构化格式（TDD/目标/范围/上下文/测试焦点）
  • 在任何命令前初始化TaskCreate（阶段4在阶段2后动态添加）
  • 立即执行阶段1，带结构化描述
  • 从阶段1输出解析会话ID，存储在内存中
  • 将会话ID和结构化描述传递给阶段2命令
  • 从阶段2输出解析contextPath，存储在内存中
  • 从context-package.json中提取conflictRisk: 决定阶段4执行
  • 执行阶段3（测试覆盖分析）带sessionId
  • 从阶段3输出解析testContextPath，存储在内存中
  • 如果conflictRisk ≥ 中等: 启动阶段4 conflict-resolution，带sessionId和contextPath
  • 等待阶段4完成执行（如果执行），验证conflict-resolution.json创建
  • 如果conflictRisk为无/低: 跳过阶段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状态

验证模式

  • 检测/验证会话（从–session标志或自动检测）
  • 用验证任务初始化TaskCreate
  • 执行阶段7通过所有子阶段（会话验证 → 链验证 → 覆盖分析 → 报告生成）
  • 呈现质量门结果和下一步选项

相关技能

前提技能:

  • 无 - TDD规划自包含（可先运行brainstorm命令）

被规划模式调用（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 skill - 阶段4: 内存优化（如果上下文接近限制）
  • phases/05-tdd-task-generation.md - 阶段5: 生成带红-绿-重构周期的TDD任务（内联）

被验证模式调用:

  • phases/07-tdd-verify.md - 阶段7: 测试覆盖和循环分析（内联）

后续技能:

  • workflow-tdd skill (tdd-verify phase) - 验证TDD合规性（也可通过验证模式调用）
  • workflow-plan skill (plan-verify phase) - 验证计划质量和依赖
  • 内联显示会话状态 - 审查TDD任务分解
  • Skill(skill="workflow-execute") - 开始TDD实施