workflow-tdd-plan-plan

Name: workflow-tdd-plan-plan
Author: catlog22

github.com/catlog22测试与质量2.1k41 次安装19 周前更新

代码仓库

关于 workflow-tdd-plan-plan

workflow-tdd-plan-plan 是用于规划和验证测试驱动开发流程的技能，面向需要生成结构化实现任务或检查 TDD 合规性的开发者。它按模式编排多个阶段，并生成实现计划、任务数据和合规报告。

主要功能

01规划与验证模式路由
02生成 Red-Green-Refactor 任务链
03分析测试覆盖与缺口
04验证 TDD 结构和合规性
05生成实现计划与合规报告

适用场景

01为新功能拆分测试优先的实现任务
02检查任务是否包含完整 TDD 阶段
03评估现有测试覆盖并发现缺口
04生成 TDD 合规报告

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/catlog22/claude-code-workflow --skill workflow-tdd-plan-plan

安装后在 Claude Code 中输入/workflow-tdd-plan-plan确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

phases/

01-session-discovery.md

02-context-gathering.md

03-test-coverage-analysis.md

04-conflict-resolution.md

05-tdd-task-generation.md

06-tdd-structure-validation.md

07-tdd-verify.md

详细介绍

统一的 TDD 工作流技能，结合 TDD 规划（生成 Red-Green-Refactor 任务链，并采用测试优先开发结构）和 TDD 验证（合规性校验并报告质量门禁）。生成 IMPL_PLAN.md、包含内部 TDD 循环的任务 JSON，以及 TDD_COMPLIANCE_REPORT.md。触发词为“workflow-tdd-plan”（规划模式）或“workflow-tdd-verify”（验证模式）。

1. 架构概览

┌──────────────────────────────────────────────────────────────────┐
│  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

2. 核心设计原则

纯编排器：SKILL.md 仅负责路由和协调；执行细节位于各阶段文件中
渐进式阶段加载：仅在某阶段即将执行时读取该阶段文档
多模式路由：单个技能通过模式检测处理规划和验证
任务附加模型：子命令任务会被附加、按顺序执行，然后折叠
自动继续：每个阶段完成后，自动执行下一个待处理阶段
TDD 铁律：没有先编写失败测试，就不编写生产代码——通过任务结构强制执行

3. 交互式偏好收集

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

// ★ 统一 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 引用。

4. 模式检测

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
}

5. 紧凑恢复（阶段持久化）

多阶段 TDD 规划（阶段 1-6/7）会跨越较长对话。采用双重保险：通过 TodoWrite 跟踪活动阶段，防止其被压缩；sentinel 则作为兜底。

⚠️ COMPACT 指令：上下文压缩时，必须检查 TodoWrite 阶段状态。当前标记为 in_progress 的阶段是活动执行阶段——必须保留其完整内容。仅压缩标记为 completed 或 pending 的阶段。

6. 执行流程——规划模式（默认）

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

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

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

Phase 3: Test Coverage Analysis
   └─ Read("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 → Read("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
   └─ Read("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
   └─ Read("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

7. 执行流程——验证模式

Phase 7: TDD Verification
   └─ Read("phases/07-tdd-verify.md")
      └─ Output: TDD_COMPLIANCE_REPORT.md with quality gate recommendation

8. 阶段参考文档

阶段执行时按需使用 Read("phases/...") 读取：

阶段	文档	用途	模式	压缩
1	phases/01-session-discovery.md	创建或发现 TDD 工作流会话	规划	TodoWrite 驱动
2	phases/02-context-gathering.md	收集项目上下文并分析代码库	规划	TodoWrite 驱动
3	phases/03-test-coverage-analysis.md	分析测试覆盖率并检测框架	规划	TodoWrite 驱动
4	phases/04-conflict-resolution.md	检测并解决冲突（有条件执行）	规划	TodoWrite 驱动
5	phases/05-tdd-task-generation.md	生成包含 Red-Green-Refactor 循环的 TDD 任务	规划	TodoWrite 驱动 + sentinel
6	phases/06-tdd-structure-validation.md	验证 TDD 结构并显示确认关卡	规划	TodoWrite 驱动 + sentinel
7	phases/07-tdd-verify.md	全面验证 TDD 合规性并检查质量门禁	验证	TodoWrite 驱动

压缩规则：

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

## 9. 核心规则

立即开始：第一步是检测模式并初始化 TaskCreate，第二步是执行阶段
不做前期分析：Phase 1 开始前，不得读取文件、分析结构或收集上下文
解析每项输出：从各阶段的输出中提取下一阶段所需的数据
通过 TaskList 自动继续：检查 TaskList 状态，自动执行下一个待处理阶段
跟踪进度：通过动态更新 TaskCreate/TaskUpdate，采用任务附加/折叠模式
任务附加模型：技能执行会将子任务附加到当前工作流。编排器会自行执行这些附加的任务，然后在完成后将其折叠
渐进式加载阶段文档：仅在即将执行某个阶段时读取该阶段的文档
不得停止：持续执行多阶段工作流。执行完所有附加任务后，立即将其折叠并执行下一阶段
TDD 上下文：所有描述都包含前缀「TDD:」

10. TDD 合规要求

铁律

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

执行方式：

Phase 5：implementation 包含先编写测试的步骤（Red → Green → Refactor）
Green 阶段：包含测试修复循环配置（最多 3 次迭代）
自动回退：达到最大迭代次数仍未通过测试时触发

验证：Phase 6 验证所有生成的任务是否符合 Red-Green-Refactor 结构

TDD 合规检查点

检查点	验证阶段	所需证据
先编写测试的结构	Phase 5	`implementation` 有 3 个步骤
存在 Red 阶段	Phase 6	步骤 1：`tdd_phase: "red"`
Green 阶段包含测试修复	Phase 6	步骤 2：`tdd_phase: "green"` + 测试修复循环
存在 Refactor 阶段	Phase 6	步骤 3：`tdd_phase: "refactor"`

TDD 核心原则

警示信号——停止并重新评估：

先写代码，再写测试
测试立即通过（未经历 Red 阶段）
无法解释测试为何应该失败
以「就这一次」为由自我辩解
认为「之后再写测试也能达到相同目的」

顺序为何重要：

先写代码再写测试，测试会立即通过 → 证明不了任何事
先写测试能迫使你在实现前发现边界情况
事后编写的测试验证的是已构建的内容，而非所需内容

11. 输入处理

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

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

User: "Build authentication system"

Structured:
TDD: Authentication System
GOAL: Build authentication system
SCOPE: Core authentication features
CONTEXT: New implementation
TEST_FOCUS: Authentication scenarios

详细文本 → 使用 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

文件/Issue → 读取并按 TDD 结构化

12. 数据流 — 规划模式

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

13. 数据流 — 验证模式

Input: --session sessionId (or auto-detect)
    ↓
Phase 7: Session discovery → Chain validation → Coverage analysis → Report
    ↓ Output: TDD_COMPLIANCE_REPORT.md with quality gate

会话记忆流：每个阶段都会接收会话 ID，从而访问：

之前的任务摘要
现有上下文和分析
特定于会话的配置

14. TodoWrite 模式

核心概念：动态附加和折叠任务，实时查看 TDD 工作流的执行情况。

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

创建初始列表 → 为每个项目调用 TaskCreate

更改状态 → TaskUpdate({ taskId, status })

附加子任务 → TaskCreate + TaskUpdate({ addBlockedBy })

折叠子任务 → TaskUpdate({ status: "completed" }) + 对折叠的子项目调用 TaskUpdate({ status: "deleted" })

核心原则

任务附加（阶段执行时）：
- 子任务会附加到编排器的 TodoWrite
- 阶段 3、4、5：附加多个子任务
- 阶段 1、2、6：单个任务（原子任务）
- 第一个附加任务标记为 in_progress，其余标记为 pending
- 编排器按顺序执行这些附加任务
任务折叠（子任务完成后）：
- 适用于阶段 3、4、5：从 TodoWrite 中移除详细子任务
- 折叠为高层阶段摘要
- 阶段 1、2、6：无需折叠（单个任务，只需标记为已完成）
- 保持编排器级视图整洁
持续执行：完成后，自动继续下一个待处理阶段

生命周期：初始为 pending → 阶段已执行（任务已附加）→ 按顺序执行子任务 → 阶段已完成（阶段 3/4/5 的任务已折叠，阶段 1/2/6 的任务标记为已完成）→ 下一阶段 → 重复

初始状态（规划模式）：

[
  {"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"}
]

注意：如果 conflictRisk ≥ medium，则阶段 4（冲突解决）会在阶段 2 之后动态添加。

阶段 3（已附加任务）：

[
  {"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"}
]

阶段 3（已折叠）：

[
  {"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"}
]

阶段 5（已附加任务）：

[
  {"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 更新示例，请参阅各阶段的说明。

15. 阶段后更新

内存状态检查

在重要阶段（阶段 2–3）之后，评估上下文窗口的使用情况：

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

规划备注（可选）

与 workflow-plan 类似，如果需要，planning-notes.md 可以在各阶段累积上下文。有关初始化，请参阅阶段 1。

16. 错误处理

解析失败：如果输出解析失败，将命令重试一次，然后报告错误
验证失败：报告缺失或无效的文件/数据
命令失败：将阶段保持为 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	Green 阶段缺少自动回滚	在任务配置中添加 `max_iterations: 3`
Red 阶段缺少测试路径	未指定测试文件路径	添加明确的测试文件路径
任务名称过于笼统	名称模糊，例如“添加功能”	使用具体的行为描述
没有重构标准	Refactor 阶段缺少完成标准	明确定义重构范围

非阻塞警告策略

所有警告仅供参考——不会中止执行：

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

17. 协调器检查清单 — 计划模式

预备阶段：将用户输入转换为 TDD 结构化格式（TDD/GOAL/SCOPE/CONTEXT/TEST_FOCUS）
在执行任何命令之前初始化 TaskCreate（第 4 阶段在第 2 阶段之后动态添加）
立即使用结构化描述执行第 1 阶段
从第 1 阶段输出中解析会话 ID，并将其存储在内存中
将会话 ID 和结构化描述传递给第 2 阶段命令
从第 2 阶段输出中解析上下文路径，并将其存储在内存中
从 context-package.json 中提取 conflictRisk：确定是否执行第 4 阶段
使用 sessionId 执行第 3 阶段（测试覆盖率分析）
从第 3 阶段输出中解析 testContextPath，并将其存储在内存中
如果 conflictRisk ≥ medium：启动第 4 阶段冲突解决，并传入 sessionId 和 contextPath
等待第 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 合规性”，如果结果为 APPROVED，则自动继续执行
每个阶段结束后更新 TaskCreate/TaskUpdate
每个阶段结束后，根据 TaskList 状态自动继续下一阶段

18. 协调器检查清单 — 验证模式

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

19. 相关技能

前置技能：

无 — TDD 规划是自成一体的（可选择先运行头脑风暴命令）

由计划模式调用（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：生成包含 Red-Green-Refactor 循环的 TDD 任务（内联）

由验证模式调用：

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

后续技能：

workflow-tdd-plan 技能（tdd-verify 阶段）— 验证 TDD 合规性（也可通过验证模式调用）
workflow-plan 技能（plan-verify 阶段）— 验证计划质量和依赖关系
内联显示会话状态 — 检查 TDD 任务拆分
Skill(skill="workflow-execute") — 开始 TDD 实施

<auto_mode> 当 workflowPreferences.autoYes 为 true（由 -y/--yes 标志触发）时：

跳过所有交互式确认提示
对所有偏好设置问题使用默认值
在计划确认关卡：自动选择“验证 TDD 合规性”
验证后：如果质量关卡返回 APPROVED，则自动继续执行
所有阶段连续执行，无需用户干预 </auto_mode>

<success_criteria>

支持 Markdown

登录后评论

基本信息

作者: catlog22
仓库: catlog22/claude-code-workflow
分类: 测试与质量
安装次数: 41
GitHub Stars: 2,119

报告问题