claude-code-workflow 6.3.53 → 7.0.0

package/.claude/commands/workflow/tools/test-task-generate.md

@@ -1,255 +0,0 @@
----
-name: test-task-generate
-description: Generate test planning documents (IMPL_PLAN.md, test task JSONs, TODO_LIST.md) using action-planning-agent - produces test planning artifacts, does NOT execute tests
-argument-hint: "--session WFS-test-session-id"
-examples:
-  - /workflow:tools:test-task-generate --session WFS-test-auth
----
-
-# Generate Test Planning Documents Command
-
-## Overview
-Generate test planning documents (IMPL_PLAN.md, test task JSONs, TODO_LIST.md) using action-planning-agent. This command produces **test planning artifacts only** - it does NOT execute tests or implement code. Actual test execution requires separate execution command (e.g., /workflow:test-cycle-execute).
-
-## Core Philosophy
-- **Planning Only**: Generate test planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) - does NOT execute tests
-- **Agent-Driven Document Generation**: Delegate test plan generation to action-planning-agent
-- **Two-Phase Flow**: Context Preparation (command) → Test Document Generation (agent)
-- **Memory-First**: Reuse loaded documents from conversation memory
-- **MCP-Enhanced**: Use MCP tools for test pattern research and analysis
-- **Path Clarity**: All `focus_paths` prefer absolute paths (e.g., `D:\\project\\src\\module`), or clear relative paths from project root
-- **Leverage Existing Test Infrastructure**: Prioritize using established testing frameworks and tools present in the project
-
-## Test-Specific Execution Modes
-
-### Test Generation (IMPL-001)
-- **Agent Mode** (default): @code-developer generates tests within agent context
-- **CLI Mode**: Use CLI tools when `command` field present in implementation_approach (determined semantically)
-
-### Test Execution & Fix (IMPL-002+)
-- **Agent Mode** (default): Gemini diagnosis → agent applies fixes
-- **CLI Mode**: Gemini diagnosis → CLI applies fixes (when `command` field present in implementation_approach)
-
-## Execution Process
-
-```
-Input Parsing:
-   ├─ Parse flags: --session
-   └─ Validation: session_id REQUIRED
-
-Phase 1: Context Preparation (Command)
-   ├─ Assemble test session paths
-   │  ├─ session_metadata_path
-   │  ├─ test_analysis_results_path (REQUIRED)
-   │  └─ test_context_package_path
-   └─ Provide metadata (session_id, source_session_id)
-
-Phase 2: Test Document Generation (Agent)
-   ├─ Load TEST_ANALYSIS_RESULTS.md as primary requirements source
-   ├─ Generate Test Task JSON Files (.task/IMPL-*.json)
-   │  ├─ IMPL-001: Test generation (meta.type: "test-gen")
-   │  └─ IMPL-002+: Test execution & fix (meta.type: "test-fix")
-   ├─ Create IMPL_PLAN.md (test_session variant)
-   └─ Generate TODO_LIST.md with test phase indicators
-```
-
-## Document Generation Lifecycle
-
-### Phase 1: Context Preparation (Command Responsibility)
-
-**Command prepares test session paths and metadata for planning document generation.**
-
-**Test Session Path Structure**:
-```
-.workflow/active/WFS-test-{session-id}/
-├── workflow-session.json          # Test session metadata
-├── .process/
-│   ├── TEST_ANALYSIS_RESULTS.md   # Test requirements and strategy
-│   ├── test-context-package.json  # Test patterns and coverage
-│   └── context-package.json       # General context artifacts
-├── .task/                         # Output: Test task JSON files
-├── IMPL_PLAN.md                   # Output: Test implementation plan
-└── TODO_LIST.md                   # Output: Test TODO list
-```
-
-**Command Preparation**:
-1. **Assemble Test Session Paths** for agent prompt:
-   - `session_metadata_path`
-   - `test_analysis_results_path` (REQUIRED)
-   - `test_context_package_path`
-   - Output directory paths
-
-2. **Provide Metadata** (simple values):
-   - `session_id`
-   - `source_session_id` (if exists)
-   - `mcp_capabilities` (available MCP tools)
-
-**Note**: CLI tool usage is now determined semantically from user's task description, not by flags.
-
-### Phase 2: Test Document Generation (Agent Responsibility)
-
-**Purpose**: Generate test-specific IMPL_PLAN.md, task JSONs, and TODO_LIST.md - planning documents only, NOT test execution.
-
-**Agent Invocation**:
-```javascript
-Task(
-  subagent_type="action-planning-agent",
-  run_in_background=false,
-  description="Generate test planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md)",
-  prompt=`
-## TASK OBJECTIVE
-Generate test planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) for test workflow session
-
-IMPORTANT: This is TEST PLANNING ONLY - you are generating planning documents, NOT executing tests.
-
-CRITICAL:
-- Use existing test frameworks and utilities from the project
-- Follow the progressive loading strategy defined in your agent specification (load context incrementally from memory-first approach)
-
-## AGENT CONFIGURATION REFERENCE
-
-Refer to your specification for:
-- Test Task JSON Schema (6-field structure with test-specific metadata)
-- Test IMPL_PLAN.md Structure (test_session variant with test-fix cycle)
-- TODO_LIST.md Format (with test phase indicators)
-- Progressive Loading Strategy (memory-first, load TEST_ANALYSIS_RESULTS.md as primary source)
-- Quality Validation Rules (task count limits, requirement quantification)
-
-## SESSION PATHS
-Input:
-  - Session Metadata: .workflow/active/{test-session-id}/workflow-session.json
-  - TEST_ANALYSIS_RESULTS: .workflow/active/{test-session-id}/.process/TEST_ANALYSIS_RESULTS.md (REQUIRED - primary requirements source)
-  - Test Context Package: .workflow/active/{test-session-id}/.process/test-context-package.json
-  - Context Package: .workflow/active/{test-session-id}/.process/context-package.json
-  - Source Session Summaries: .workflow/active/{source-session-id}/.summaries/IMPL-*.md (if exists)
-
-Output:
-  - Task Dir: .workflow/active/{test-session-id}/.task/
-  - IMPL_PLAN: .workflow/active/{test-session-id}/IMPL_PLAN.md
-  - TODO_LIST: .workflow/active/{test-session-id}/TODO_LIST.md
-
-## CONTEXT METADATA
-Session ID: {test-session-id}
-Workflow Type: test_session
-Source Session: {source-session-id} (if exists)
-MCP Capabilities: {exa_code, exa_web, code_index}
-
-## CLI TOOL SELECTION
-Determine CLI tool usage per-step based on user's task description:
-- If user specifies "use Codex/Gemini/Qwen for X" → Add command field to relevant steps
-- Default: Agent execution (no command field) unless user explicitly requests CLI
-
-## TEST-SPECIFIC REQUIREMENTS SUMMARY
-(Detailed specifications in your agent definition)
-
-### Task Structure Requirements
-- Minimum 2 tasks: IMPL-001 (test generation) + IMPL-002 (test execution & fix)
-- Expandable for complex projects: Add IMPL-003+ (per-module, integration, E2E tests)
-
-Task Configuration:
-  IMPL-001 (Test Generation):
-    - meta.type: "test-gen"
-    - meta.agent: "@code-developer"
-    - meta.test_framework: Specify existing framework (e.g., "jest", "vitest", "pytest")
-    - flow_control: Test generation strategy from TEST_ANALYSIS_RESULTS.md
-    - CLI execution: Add `command` field when user requests (determined semantically)
-
-  IMPL-002+ (Test Execution & Fix):
-    - meta.type: "test-fix"
-    - meta.agent: "@test-fix-agent"
-    - flow_control: Test-fix cycle with iteration limits and diagnosis configuration
-    - CLI execution: Add `command` field when user requests (determined semantically)
-
-### Test-Fix Cycle Specification (IMPL-002+)
-Required flow_control fields:
-  - max_iterations: 5
-  - diagnosis_tool: "gemini"
-  - diagnosis_template: "~/.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt"
-  - cycle_pattern: "test → gemini_diagnose → fix → retest"
-  - exit_conditions: ["all_tests_pass", "max_iterations_reached"]
-  - auto_revert_on_failure: true
-  - CLI fix: Add `command` field when user specifies CLI tool usage
-
-### Automation Framework Configuration
-Select automation tools based on test requirements from TEST_ANALYSIS_RESULTS.md:
-- UI interaction testing → E2E browser automation (meta.e2e_framework)
-- API/database integration → integration test tools (meta.test_tools)
-- Performance metrics → load testing tools (meta.perf_framework)
-- Logic verification → unit test framework (meta.test_framework)
-
-**Tool Selection**: Detect from project config > suggest based on requirements
-
-### TEST_ANALYSIS_RESULTS.md Mapping
-PRIMARY requirements source - extract and map to task JSONs:
-  - Test framework config → meta.test_framework (use existing framework from project)
-  - Existing test utilities → flow_control.reusable_test_tools (discovered test helpers, fixtures, mocks)
-  - Test runner commands → flow_control.test_commands (from package.json or pytest config)
-  - Coverage targets → meta.coverage_target
-  - Test requirements → context.requirements (quantified with explicit counts)
-  - Test generation strategy → IMPL-001 flow_control.implementation_approach
-  - Implementation targets → context.files_to_test (absolute paths)
-
-## EXPECTED DELIVERABLES
-1. Test Task JSON Files (.task/IMPL-*.json)
-   - 6-field schema with quantified requirements from TEST_ANALYSIS_RESULTS.md
-   - Test-specific metadata: type, agent, test_framework, coverage_target
-   - flow_control includes: reusable_test_tools, test_commands (from project config)
-   - CLI execution via `command` field when user requests (determined semantically)
-   - Artifact references from test-context-package.json
-   - Absolute paths in context.files_to_test
-
-2. Test Implementation Plan (IMPL_PLAN.md)
-   - Template: ~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt
-   - Test-specific frontmatter: workflow_type="test_session", test_framework, source_session_id
-   - Test-Fix-Retest Cycle section with diagnosis configuration
-   - Source session context integration (if applicable)
-
-3. TODO List (TODO_LIST.md)
-   - Hierarchical structure with test phase containers
-   - Links to task JSONs with status markers
-   - Matches task JSON hierarchy
-
-## QUALITY STANDARDS
-Hard Constraints:
-  - Task count: minimum 2, maximum 18
-  - All requirements quantified from TEST_ANALYSIS_RESULTS.md
-  - Test framework matches existing project framework
-  - flow_control includes reusable_test_tools and test_commands from project
-  - Absolute paths for all focus_paths
-  - Acceptance criteria include verification commands
-  - CLI `command` field added only when user explicitly requests CLI tool usage
-
-## SUCCESS CRITERIA
-- All test planning documents generated successfully
-- Return completion status: task count, test framework, coverage targets, source session status
-`
-)
-```
-
-## Integration & Usage
-
-### Command Chain
-- **Called By**: `/workflow:test-gen` (Phase 4), `/workflow:test-fix-gen` (Phase 4)
-- **Invokes**: `action-planning-agent` for test planning document generation
-- **Followed By**: `/workflow:test-cycle-execute` or `/workflow:execute` (user-triggered)
-
-### Usage Examples
-```bash
-# Standard execution
-/workflow:tools:test-task-generate --session WFS-test-auth
-
-# With semantic CLI request (include in task description)
-# e.g., "Generate tests, use Codex for implementation and fixes"
-```
-
-### CLI Tool Selection
-CLI tool usage is determined semantically from user's task description:
-- Include "use Codex" for automated fixes
-- Include "use Gemini" for analysis
-- Default: Agent execution (no `command` field)
-
-### Output
-- Test task JSON files in `.task/` directory (minimum 2)
-- IMPL_PLAN.md with test strategy and fix cycle specification
-- TODO_LIST.md with test phase indicators
-- Session ready for test execution

package/.claude/skills/ccw-loop/SKILL.md

@@ -1,259 +0,0 @@
----
-name: ccw-loop
-description: Stateless iterative development loop workflow with documented progress. Supports develop, debug, and validate phases with file-based state tracking. Triggers on "ccw-loop", "dev loop", "development loop", "开发循环", "迭代开发".
-allowed-tools: Task(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*), TodoWrite(*)
----
-
-# CCW Loop - Stateless Iterative Development Workflow
-
-无状态迭代开发循环工作流，支持开发 (develop)、调试 (debug)、验证 (validate) 三个阶段，每个阶段都有独立的文件记录进展。
-
-## Arguments
-
-| Arg | Required | Description |
-|-----|----------|-------------|
-| task | No | Task description (for new loop, mutually exclusive with --loop-id) |
-| --loop-id | No | Existing loop ID to continue (from API or previous session) |
-| --auto | No | Auto-cycle mode (develop → debug → validate → complete) |
-
-## Unified Architecture (API + Skill Integration)
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│                     Dashboard (UI)                              │
-│  [Create] [Start] [Pause] [Resume] [Stop] [View Progress]       │
-└─────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────┐
-│              loop-v2-routes.ts (Control Plane)                  │
-│                                                                 │
-│  State: .loop/{loopId}.json (MASTER)                            │
-│  Tasks: .loop/{loopId}.tasks.jsonl                              │
-│                                                                 │
-│  /start → Trigger ccw-loop skill with --loop-id                 │
-│  /pause → Set status='paused' (skill checks before action)      │
-│  /stop  → Set status='failed' (skill terminates)                │
-│  /resume → Set status='running' (skill continues)               │
-└─────────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────────┐
-│               ccw-loop Skill (Execution Plane)                  │
-│                                                                 │
-│  Reads/Writes: .loop/{loopId}.json (unified state)              │
-│  Writes: .loop/{loopId}.progress/* (progress files)             │
-│                                                                 │
-│  BEFORE each action:                                            │
-│    → Check status: paused/stopped → exit gracefully             │
-│    → running → continue with action                             │
-│                                                                 │
-│  Actions: init → develop → debug → validate → complete          │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-## Key Design Principles
-
-1. **统一状态**: API 和 Skill 共享 `.loop/{loopId}.json` 状态文件
-2. **控制信号**: Skill 每个 Action 前检查 status 字段 (paused/stopped)
-3. **文件驱动**: 所有进度、理解、结果都记录在 `.loop/{loopId}.progress/`
-4. **可恢复**: 任何时候可以继续之前的循环 (`--loop-id`)
-5. **双触发**: 支持 API 触发 (`--loop-id`) 和直接调用 (task description)
-6. **Gemini 辅助**: 使用 CLI 工具进行深度分析和假设验证
-
-## Execution Modes
-
-### Mode 1: Interactive (交互式)
-
-用户手动选择每个动作，适合复杂任务。
-
-```
-用户 → 选择动作 → 执行 → 查看结果 → 选择下一动作
-```
-
-### Mode 2: Auto-Loop (自动循环)
-
-按预设顺序自动执行，适合标准开发流程。
-
-```
-Develop → Debug → Validate → (如有问题) → Develop → ...
-```
-
-## Session Structure (Unified Location)
-
-```
-.loop/
-├── {loopId}.json              # 主状态文件 (API + Skill 共享)
-├── {loopId}.tasks.jsonl       # 任务列表 (API 管理)
-└── {loopId}.progress/         # Skill 进度文件
-    ├── develop.md             # 开发进度记录
-    ├── debug.md               # 理解演变文档
-    ├── validate.md            # 验证报告
-    ├── changes.log            # 代码变更日志 (NDJSON)
-    └── debug.log              # 调试日志 (NDJSON)
-```
-
-## Directory Setup
-
-```javascript
-// loopId 来源:
-// 1. API 触发时: 从 --loop-id 参数获取
-// 2. 直接调用时: 生成新的 loop-v2-{timestamp}-{random}
-
-const loopId = args['--loop-id'] || generateLoopId()
-const loopFile = `.loop/${loopId}.json`
-const progressDir = `.loop/${loopId}.progress`
-
-// 创建进度目录
-Bash(`mkdir -p "${progressDir}"`)
-```
-
-## Action Catalog
-
-| Action | Purpose | Output Files | CLI Integration |
-|--------|---------|--------------|-----------------|
-| [action-init](phases/actions/action-init.md) | 初始化循环会话 | meta.json, state.json | - |
-| [action-develop-with-file](phases/actions/action-develop-with-file.md) | 开发任务执行 | progress.md, tasks.json | gemini --mode write |
-| [action-debug-with-file](phases/actions/action-debug-with-file.md) | 假设驱动调试 | understanding.md, hypotheses.json | gemini --mode analysis |
-| [action-validate-with-file](phases/actions/action-validate-with-file.md) | 测试与验证 | validation.md, test-results.json | gemini --mode analysis |
-| [action-complete](phases/actions/action-complete.md) | 完成循环 | summary.md | - |
-| [action-menu](phases/actions/action-menu.md) | 显示操作菜单 | - | - |
-
-## Usage
-
-```bash
-# 启动新循环 (直接调用)
-/ccw-loop "实现用户认证功能"
-
-# 继续现有循环 (API 触发或手动恢复)
-/ccw-loop --loop-id loop-v2-20260122-abc123
-
-# 自动循环模式
-/ccw-loop --auto "修复登录bug并添加测试"
-
-# API 触发自动循环
-/ccw-loop --loop-id loop-v2-20260122-abc123 --auto
-```
-
-## Execution Flow
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  /ccw-loop [<task> | --loop-id <id>] [--auto]                    │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                  │
-│  1. Parameter Detection:                                         │
-│     ├─ IF --loop-id provided:                                    │
-│     │   ├─ Read .loop/{loopId}.json                              │
-│     │   ├─ Validate status === 'running'                         │
-│     │   └─ Continue from skill_state.current_action              │
-│     └─ ELSE (task description):                                  │
-│         ├─ Generate new loopId                                   │
-│         ├─ Create .loop/{loopId}.json                            │
-│         └─ Initialize with action-init                           │
-│                                                                  │
-│  2. Orchestrator Loop:                                           │
-│     ├─ Read state from .loop/{loopId}.json                       │
-│     ├─ Check control signals:                                    │
-│     │   ├─ status === 'paused' → Exit (wait for resume)          │
-│     │   ├─ status === 'failed' → Exit with error                 │
-│     │   └─ status === 'running' → Continue                       │
-│     ├─ Show menu / auto-select next action                       │
-│     ├─ Execute action                                            │
-│     ├─ Update .loop/{loopId}.progress/{action}.md                │
-│     ├─ Update .loop/{loopId}.json (skill_state)                  │
-│     └─ Loop or exit based on user choice / completion            │
-│                                                                  │
-│  3. Action Execution:                                            │
-│     ├─ BEFORE: checkControlSignals() → exit if paused/stopped    │
-│     ├─ Develop: Plan → Implement → Document progress             │
-│     ├─ Debug: Hypothesize → Instrument → Analyze → Fix           │
-│     ├─ Validate: Test → Check → Report                           │
-│     └─ AFTER: Update skill_state in .loop/{loopId}.json          │
-│                                                                  │
-│  4. Termination:                                                 │
-│     ├─ Control signal: paused (graceful exit, wait resume)       │
-│     ├─ Control signal: stopped (failed state)                    │
-│     ├─ User exits (interactive mode)                             │
-│     ├─ All tasks completed (status → completed)                  │
-│     └─ Max iterations reached                                    │
-│                                                                  │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-## Reference Documents
-
-| Document | Purpose |
-|----------|---------|
-| [phases/orchestrator.md](phases/orchestrator.md) | 编排器：状态读取 + 动作选择 |
-| [phases/state-schema.md](phases/state-schema.md) | 状态结构定义 |
-| [specs/loop-requirements.md](specs/loop-requirements.md) | 循环需求规范 |
-| [specs/action-catalog.md](specs/action-catalog.md) | 动作目录 |
-| [templates/progress-template.md](templates/progress-template.md) | 进度文档模板 |
-| [templates/understanding-template.md](templates/understanding-template.md) | 理解文档模板 |
-
-## Integration with Loop Monitor (Dashboard)
-
-此 Skill 与 CCW Dashboard 的 Loop Monitor 实现 **控制平面 + 执行平面** 分离架构：
-
-### Control Plane (Dashboard/API → loop-v2-routes.ts)
-
-1. **创建循环**: `POST /api/loops/v2` → 创建 `.loop/{loopId}.json`
-2. **启动执行**: `POST /api/loops/v2/:loopId/start` → 触发 `/ccw-loop --loop-id {loopId} --auto`
-3. **暂停执行**: `POST /api/loops/v2/:loopId/pause` → 设置 `status='paused'` (Skill 下次检查时退出)
-4. **恢复执行**: `POST /api/loops/v2/:loopId/resume` → 设置 `status='running'` → 重新触发 Skill
-5. **停止执行**: `POST /api/loops/v2/:loopId/stop` → 设置 `status='failed'`
-
-### Execution Plane (ccw-loop Skill)
-
-1. **读取状态**: 从 `.loop/{loopId}.json` 读取 API 设置的状态
-2. **检查控制**: 每个 Action 前检查 `status` 字段
-3. **执行动作**: develop → debug → validate → complete
-4. **更新进度**: 写入 `.loop/{loopId}.progress/*.md` 和更新 `skill_state`
-5. **状态同步**: Dashboard 通过读取 `.loop/{loopId}.json` 获取进度
-
-## CLI Integration Points
-
-### Develop Phase
-```bash
-ccw cli -p "PURPOSE: Implement {task}...
-TASK: • Analyze requirements • Write code • Update progress
-MODE: write
-CONTEXT: @progress.md @tasks.json
-EXPECTED: Implementation + updated progress.md
-" --tool gemini --mode write --rule development-implement-feature
-```
-
-### Debug Phase
-```bash
-ccw cli -p "PURPOSE: Generate debugging hypotheses...
-TASK: • Analyze error • Generate hypotheses • Add instrumentation
-MODE: analysis
-CONTEXT: @understanding.md @debug.log
-EXPECTED: Hypotheses + instrumentation plan
-" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
-```
-
-### Validate Phase
-```bash
-ccw cli -p "PURPOSE: Validate implementation...
-TASK: • Run tests • Check coverage • Verify requirements
-MODE: analysis
-CONTEXT: @validation.md @test-results.json
-EXPECTED: Validation report
-" --tool gemini --mode analysis --rule analysis-review-code-quality
-```
-
-## Error Handling
-
-| Situation | Action |
-|-----------|--------|
-| Session not found | Create new session |
-| State file corrupted | Rebuild from file contents |
-| CLI tool fails | Fallback to manual analysis |
-| Tests fail | Loop back to develop/debug |
-| >10 iterations | Warn user, suggest break |
-
-## Post-Completion Expansion
-
-完成后询问用户是否扩展为 issue (test/enhance/refactor/doc)，选中项调用 `/issue:new "{summary} - {dimension}"`