Agent skill

Workflow TDD Plan Plan

by catlog22 in catlog22/Claude-Code-Workflow

Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting.

MITAuto-check: notesTesting & QA

Install Workflow TDD Plan Plan

skills CLI
$ npx skills add catlog22/Claude-Code-Workflow --skill workflow-tdd-plan-plan -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install catlog22/Claude-Code-Workflow workflow-tdd-plan-plan --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/catlog22/Claude-Code-Workflow.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/workflow-tdd-plan .claude/skills/workflow-tdd-plan-plan && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
workflow-tdd-plan-plan
GitHub stars
2.1k
Token cost
~5.9k tokens
SKILL.md length
1,762 words
Files
8
Skills in repo
82
Repo updated
First seen
Licence
MIT

At a glance

Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting.

  • Works in 12 steps: Architecture Overview → Key Design Principles → Interactive Preference Collection → …
  • Workflow-tdd-plan
  • SKILL.md covers 1. Architecture Overview, 2. Key Design Principles, 3. Interactive Preference… and 4. Mode Detection, plus 13 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Workflow TDD Plan Plan is an agent skill from catlog22/Claude-Code-Workflow. Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting. Triggers on "workflow-tdd-plan", "workflow-tdd-verify".

Its SKILL.md is about 5.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files (for example `phases/01-session-discovery.md`, `phases/02-context-gathering.md` and `phases/03-test-coverage-analysis.md`).

It sits in Testing & QA, covering Test-driven development. The repository describes itself as: JSON-driven multi-agent cadence-team development framework with intelligent CLI orchestration (Gemini/Qwen/Codex), context-first architecture, and automated workflow execution. The licence is MIT.

When your agent uses it

  • Workflow-tdd-plan
  • Workflow-tdd-verify

Example prompts

  • “workflow-tdd-plan”
  • “workflow-tdd-verify”
  • “/workflow-tdd-plan-plan”

Requirements

  • Pre-approved tools (allowed-tools): Skill, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep

Workflow steps

12 steps, taken from the step headings in SKILL.md.

  1. Architecture Overview
  2. Key Design Principles
  3. Interactive Preference Collection
  4. Mode Detection
  5. Compact Recovery (Phase Persistence)
  6. Execution Flow — Plan Mode (default)
  7. Execution Flow — Verify Mode
  8. Phase Reference Documents
  9. Core Rules
  10. TDD Compliance Requirements
  11. Input Processing
  12. Data Flow — Plan Mode

What it can do on your machine

Read from SKILL.md and the folder at commit 07491b0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Skill
    • Agent
    • AskUserQuestion
    • TaskCreate
    • TaskUpdate
    • TaskList
    • Read
    • Write
    • Edit
    • Bash

    …and 2 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are json and javascript).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Workflow TDD Plan Plan loads about 5.9k tokens when it runs. Until then it costs about 60 tokens; SKILL.md has 1,762 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~60
When it runs · the whole SKILL.md, loaded when a task matches
~5.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Skill, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from catlog22/Claude-Code-Workflow at commit 07491b0, republished under its MIT licence (© catlog22). 1,762 words, ~5,880 tokens.

Download SKILL.mdSave it as .claude/skills/workflow-tdd-plan-plan/SKILL.md (or your agent's skills folder). This skill also uses 7 other files; get the full folder from GitHub.
name
workflow-tdd-plan-plan
description
Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting. Triggers on "workflow-tdd-plan", "workflow-tdd-verify".
allowed-tools
Skill, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep
<purpose>
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. Triggers on "workflow-tdd-plan" (plan mode) or "workflow-tdd-verify" (verify mode).
</purpose>
<process>

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

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

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

4. 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
}

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

6. Execution Flow — Plan Mode (default)

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. Execution Flow — Verify Mode

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

8. Phase Reference Documents

Read on-demand when phase executes using Read("phases/..."):

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

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

10. TDD Compliance Requirements

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

TDD Compliance Checkpoint
CheckpointValidation PhaseEvidence Required
Test-first structurePhase 5implementation 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"
Core TDD Principles

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

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

12. Data Flow — Plan Mode

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. Data Flow — Verify Mode

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

14. TodoWrite Pattern

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

Initial State (Plan Mode):
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.

Phase 3 (Tasks Attached):
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):
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):
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.

15. 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
Planning Notes (Optional)

Similar to workflow-plan, a planning-notes.md can accumulate context across phases if needed. See Phase 1 for initialization.

16. 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
Show full SKILL.md (734 more words)Show less
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
TDD Warning Patterns
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
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

17. Coordinator Checklist — Plan Mode

  • 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

18. Coordinator Checklist — Verify Mode

  • 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

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

<auto_mode> When workflowPreferences.autoYes is true (triggered by -y/--yes flag):

  • Skip all interactive confirmation prompts
  • Use default values for all preference questions
  • At Plan Confirmation Gate: Auto-select "Verify TDD Compliance"
  • After verification: Auto-continue to execute if quality gate returns APPROVED
  • All phases execute continuously without user intervention </auto_mode>

<success_criteria>

  • Mode correctly detected from skill trigger name (plan vs verify)
  • All 6 plan phases execute sequentially with proper data flow between them
  • Phase files loaded progressively via Read() only when phase is about to execute
  • TaskCreate/TaskUpdate tracks all phases with attachment/collapse pattern
  • TDD Iron Law enforced: every task has Red-Green-Refactor structure
  • Phase 4 (Conflict Resolution) conditionally executes based on conflictRisk level
  • Plan Confirmation Gate presents three choices after Phase 6
  • Verify mode (Phase 7) produces TDD_COMPLIANCE_REPORT.md with quality gate
  • All outputs generated: IMPL_PLAN.md, IMPL-*.json, TODO_LIST.md
  • Compact recovery preserves active phase content via TodoWrite status
  • Error handling retries once on parsing failure, reports on persistent errors </success_criteria>

© catlog22, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 7 other files in .claude/skills/workflow-tdd-plan of catlog22/Claude-Code-Workflow.

  • SKILL.md
  • phases/01-session-discovery.md
  • phases/02-context-gathering.md
  • phases/03-test-coverage-analysis.md
  • phases/04-conflict-resolution.md
  • phases/05-tdd-task-generation.md
  • phases/06-tdd-structure-validation.md
  • phases/07-tdd-verify.md

Open the folder on GitHubat commit 07491b0

Compare with similar skills

Workflow TDD Plan Plan next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Workflow TDD Plan Plan compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Workflow TDD Plan Plan this skillcatlog22/Claude-Code-Workflow2.1k—~5.9kAutomated safety check: NotesMIT
TDDpietheinstrengholt/rssmonster56430 repos~906Automated safety check: PassMIT
TDD WorkflowhellangleZ/burn-in-cceverywhere-ralph11211 repos~2.4kAutomated safety check: PassNone
TDDsanity-io/sanity6.4k20 repos~1kAutomated safety check: PassMIT
Test Driven Developmentfarm-fe/farm5.6k51 repos~2.5kAutomated safety check: PassMIT
Tapd Story PipelineTencentBlueKing/bk-bcs840—~2.6kAutomated safety check: PassCustom licence

Similar skills

  • TDD

    pietheinstrengholt/rssmonster

    Test-driven development. An agent skill from pietheinstrengholt/rssmonster.

    564 GitHub starsUsed in 30 repos~906 tokens
    Testing & QAAuto-check passed
  • TDD Workflow

    hellangleZ/burn-in-cceverywhere-ralph

    A skill your agent uses when writing new features, fixing bugs, or refactoring code.

    112 GitHub starsUsed in 11 repos~2.4k tokens
    Testing & QAAuto-check passed
  • TDD

    sanity-io/sanity

    Official

    Test-driven development with red-green-refactor loop. An agent skill from sanity-io/sanity.

    6.4k GitHub starsUsed in 20 repos~1k tokens
    Testing & QAAuto-check passed
  • A skill your agent uses when implementing any feature or bugfix, before writing implementation code

    5.6k GitHub starsUsed in 51 repos~2.5k tokens
    Testing & QAAuto-check passed
  • Tapd Story Pipeline

    TencentBlueKing/bk-bcs

    单需求实现流水线——把一个 TAPD 需求从零推进到代码提交。自动串联技术澄清、 开发计划、任务拆分、TDD 实现、架构/安全校验、代码提交六个阶段。

    840 GitHub stars~2.6k tokensUpdated today
    Testing & QAAuto-check passed
  • Absolute Init

    maddhruv/absolute

    One-time setup for absolute: interview how you want it to behave (output style, autonomy, TDD strictness, spec dir, families) + detect the stack once, then write .absolute.config.json (project…

    218 GitHub starsUsed in 1 repo~3k tokens
    Testing & QAAuto-check passed

More from catlog22/Claude-Code-Workflow

All 82 skills in this repo
  • Prompt Generator

    catlog22/Claude-Code-Workflow

    Generate or convert Claude Code prompt files — command orchestrators, skill files, agent role definitions, or style conversion of existing files.

    2.1k GitHub starsUsed in 1 repo~4.7k tokens
    Auto-check: notes
  • Ccw Help

    catlog22/Claude-Code-Workflow

    CCW command help system. An agent skill from catlog22/Claude-Code-Workflow.

    2.1k GitHub stars~2.5k tokensUpdated 3 mo ago
    Auto-check passed
  • Team Ultra Analyze

    catlog22/Claude-Code-Workflow

    Deep collaborative analysis team skill. An agent skill from catlog22/Claude-Code-Workflow.

    2.1k GitHub starsUsed in 1 repo~2.4k tokens
    Auto-check: notes
  • Brainstorm

    catlog22/Claude-Code-Workflow

    Unified brainstorming skill with dual-mode operation — auto mode (framework generation, parallel multi-role analysis, cross-role synthesis) and single role analysis.

    2.1k GitHub stars~4.8k tokensUpdated 3 mo ago
    Auto-check: notes
  • Ccw Chain

    catlog22/Claude-Code-Workflow

    Chain-based CCW workflow orchestrator. An agent skill from catlog22/Claude-Code-Workflow.

    2.1k GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check: notes
  • Delegation Check

    catlog22/Claude-Code-Workflow

    Check workflow delegation prompts against agent role definitions for content separation violations.

    2.1k GitHub stars~2.8k tokensUpdated 3 mo ago
    Auto-check: notes

Categories

Questions about Workflow TDD Plan Plan

What does Workflow TDD Plan Plan do?

Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting. Workflow TDD Plan Plan is an agent skill from catlog22/Claude-Code-Workflow. Unified TDD workflow skill combining 6-phase TDD planning with Red-Green-Refactor task chain generation, and 4-phase TDD verification with compliance reporting.

When should I use Workflow TDD Plan Plan?

Workflow TDD Plan Plan fits situations like: workflow-tdd-plan; workflow-tdd-verify.

How do I install Workflow TDD Plan Plan in Claude Code?

Run `npx skills add catlog22/Claude-Code-Workflow --skill workflow-tdd-plan-plan -a claude-code`. Or copy the skill folder (.claude/skills/workflow-tdd-plan in catlog22/Claude-Code-Workflow) into .claude/skills/workflow-tdd-plan-plan in your project. Claude Code loads it when a task matches its description.

How do I install Workflow TDD Plan Plan in Codex?

Run `npx skills add catlog22/Claude-Code-Workflow --skill workflow-tdd-plan-plan -a codex`. Or copy the skill folder (.claude/skills/workflow-tdd-plan in catlog22/Claude-Code-Workflow) into .agents/skills/workflow-tdd-plan-plan in your project. Codex loads it when a task matches its description.

Can I use Workflow TDD Plan Plan in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add catlog22/Claude-Code-Workflow --skill workflow-tdd-plan-plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/workflow-tdd-plan-plan, .gemini/skills/workflow-tdd-plan-plan, .github/skills/workflow-tdd-plan-plan and .opencode/skills/workflow-tdd-plan-plan in your project.

What does Workflow TDD Plan Plan need to run?

SKILL.md names no scripts, command-line tools or credentials: Workflow TDD Plan Plan is instructions for the agent only. Its frontmatter pre-approves these tools: Skill, Agent, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, Read, Write, Edit, Bash, Glob, Grep.

Does Workflow TDD Plan Plan access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Workflow TDD Plan Plan safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Workflow TDD Plan Plan use?

Workflow TDD Plan Plan is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Workflow TDD Plan Plan use?

About 5.9k tokens (SKILL.md is roughly 24k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Workflow TDD Plan Plan?

Skills that share tags, products or a category with Workflow TDD Plan Plan: TDD (pietheinstrengholt/rssmonster, 564 stars), TDD Workflow (hellangleZ/burn-in-cceverywhere-ralph, 112 stars), TDD (sanity-io/sanity, 6.4k stars) and Test Driven Development (farm-fe/farm, 5.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Workflow TDD Plan Plan?

catlog22 (a GitHub user) maintains it in catlog22/Claude-Code-Workflow, which has 2,130 GitHub stars. The repository holds 82 skills in this directory. The repository was last updated on June 18, 2026.

Source: catlog22/Claude-Code-Workflow on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.