Compare commits

..

490 Commits

Author SHA1 Message Date
catlog22
357d3524f5 chore: bump version to 6.3.46 2026-01-24 14:31:29 +08:00
catlog22
4334162ddf refactor: remove unused command definitions from ccw-coordinator 2026-01-24 14:29:51 +08:00
catlog22
2dcd1637f0 refactor: enhance documentation on Minimum Execution Units and command grouping in CCW 2026-01-24 14:27:58 +08:00
catlog22
38e1cdc737 chore(release): publish 6.3.45
## Features

- New `ccw` command: Main process workflow orchestrator with auto intent-based workflow selection
- New CommandRegistry for dynamic command discovery and metadata management

## Improvements

- Optimize ccw-coordinator: Serial blocking execution model with hook-based continuation
- Refactor execution flow: Stop after CLI launch, wait for hook callbacks (no polling)
- Add task_id tracking and state.json checkpoints for resumable execution
- Consolidate documentation: Reduce report verbosity while maintaining all core information

## Documentation

- Add Execution Model comparison (main process vs external CLI)
- Add State Management section with TodoWrite tracking examples
- Update Type Comparison table highlighting ccw vs ccw-coordinator differences
- Simplify code examples with inline comments

## Changes Summary

- ccw-coordinator.md: +272/-26 (serial blocking), -143 docs (consolidation)
- ccw.md: +121/-352 (state management, execution model)
- Rename: CCW-COORDINATOR.md → ccw-coordinator.md (lowercase)
2026-01-24 14:09:52 +08:00
catlog22
097a7346b9 refactor: optimize ccw.md with streamlined documentation and state management
- Add Execution Model section (Synchronous vs Async blocking comparison)
- Add State Management section (TodoWrite-based tracking)
- Simplify Phase 1-5 code (remove verbose comments, consolidate logic)
- Consolidate Pipeline Examples into table format (5 examples → 1 table)
- Update Type Comparison table (highlight ccw vs ccw-coordinator differences)
- Maintain all core information (no content loss)

Changes:
- -352 lines (verbose explanations, redundant code)
- +121 lines (consolidated content, new sections)
- net: -231 lines (35% reduction: 665→433 lines)

Key additions:
- Execution Model flow diagram
- State Management with TodoWrite example
- Type Comparison: Synchronous (main) vs Async (external CLI)
2026-01-24 14:06:31 +08:00
catlog22
9df8063fbd refactor: reduce documentation report, consolidate overlapping content
- Eliminate redundant Stop-Action explanations (moved to CLI Execution Model)
- Remove verbose hook/error handling examples (keep in code only)
- Consolidate 5-step CLI example into 1-line pattern
- Simplify handleCliCompletion function comments
- Streamline executor loop exit notes
- Maintain all core information (no content loss)
- Reduce report from ~1000 lines to ~900 lines

Changes:
- -143 lines (old verbose explanations)
- +21 lines (consolidated content)
- net: -122 lines
2026-01-24 14:00:34 +08:00
catlog22
d00f0bc7ca refactor: improve CCW orchestrator with serial blocking execution and hook-based continuation
- Rename file to lowercase: CCW-COORDINATOR.md → ccw-coordinator.md
- Replace polling waitForTaskCompletion with stop-action blocking model
- CLI commands execute in background with immediate stop (no polling)
- Hook callbacks (handleCliCompletion) trigger continuation to next command
- Add task_id and completed_at fields to execution_results
- Maintain state checkpoint after each command launch
- Add status flow documentation (running → waiting → completed)
- Include CLI invocation example with hook configuration
- Separate concerns: orchestrator launches, hooks handle callbacks
- Support serial execution: one command at a time with break after launch
2026-01-24 13:57:08 +08:00
catlog22
24efef7f17 feat: Add main workflow orchestrator (ccw) with intent analysis and command execution
- Implemented the ccw command as a main workflow orchestrator.
- Added a 5-phase workflow including intent analysis, requirement clarification, workflow selection, user confirmation, and command execution.
- Developed functions for analyzing user input, selecting workflows, and executing command chains.
- Integrated TODO tracking for command execution progress.
- Created comprehensive tests for the CommandRegistry, covering YAML parsing, command retrieval, and error handling.
2026-01-24 13:43:47 +08:00
catlog22
44b8269a74 feat: add CommandRegistry for command management and direct imports 2026-01-24 13:29:50 +08:00
catlog22
dd51837bbc Enhance CCW Coordinator: Refactor command execution flow, improve prompt generation, and update documentation
- Refactored the command execution process to support dynamic command chaining and intelligent prompt generation.
- Updated the architecture overview to reflect changes in the orchestrator and command execution logic.
- Improved the prompt generation strategy to directly include complete command calls, enhancing clarity and usability.
- Added detailed examples and templates for command prompts in the documentation.
- Enhanced error handling and user decision-making during command execution failures.
- Introduced logging for command execution details and state updates for better traceability.
- Updated specifications and README files to align with the new command execution and prompt generation logic.
2026-01-24 12:44:40 +08:00
catlog22
a17edc3e50 chore(release): publish 6.3.44 2026-01-24 11:29:39 +08:00
catlog22
01ab3cf3fa feat: enhance tdd-verify command with detailed compliance reporting and validation improvements 2026-01-24 11:10:31 +08:00
catlog22
a2c1b9b47c fix: replace hardcoded Windows paths with dynamic cross-platform paths in CodexLens error messages
- Remove hardcoded Windows paths (D:\Claude_dms3\codex-lens) that were displayed to macOS/Linux users
- Generate dynamic possible paths list based on runtime environment
- Support multiple installation locations (cwd, project root, home directory)
- Improve error messages with platform-appropriate paths
- Maintain consistency across both bootstrapWithUv() and installSemanticWithUv() functions

Fixes remaining issue from #104 regarding cross-platform error message compatibility
2026-01-24 11:08:02 +08:00
catlog22
780e118844 fix: resolve CodexLens installation failure with NPM global install
Implements two-pass search strategy to support CodexLens in NPM global installations. Fixes issue #104.
2026-01-24 10:52:07 +08:00
catlog22
159dfd179e Refactor action plan verification command to plan verification
- Updated all references from `/workflow:action-plan-verify` to `/workflow:plan-verify` across various documentation and command files.
- Introduced a new command file for `/workflow:plan-verify` that performs read-only verification analysis on planning artifacts.
- Adjusted command relationships and help documentation to reflect the new command structure.
- Ensured consistency in command usage throughout the workflow guide and getting started documentation.
2026-01-24 10:46:15 +08:00
catlog22
6c80168612 feat: enhance project root detection with caching and debug logging 2026-01-24 10:04:04 +08:00
catlog22
a293a01d85 feat: add --yes flag for auto-confirmation across multiple workflows
- Enhanced lite-execute, lite-fix, lite-lite-lite, lite-plan, multi-cli-plan, plan, replan, session complete, session solidify, and various UI design commands to support a --yes or -y flag for skipping user confirmations and auto-selecting defaults.
- Updated argument hints and examples to reflect new auto mode functionality.
- Implemented auto mode defaults for confirmation, execution methods, and code review options.
- Improved error handling and validation in command parsing and execution processes.
2026-01-24 09:23:24 +08:00
jerry
ab259b1970 fix: resolve CodexLens installation failure with NPM global install
- Implement two-pass search strategy for codex-lens path detection
- First pass: prefer non-node_modules paths (development environment)
- Second pass: allow node_modules paths (NPM global install)
- Fixes CodexLens installation for all NPM global install users
- No breaking changes, maintains backward compatibility

Resolves issue where NPM global install users could not install CodexLens
because the code rejected paths containing /node_modules/, which is the
only valid location for codex-lens in NPM installations.

Tested on macOS with Node.js v22.18.0 via NPM global install.
2026-01-24 08:58:44 +08:00
catlog22
fd50adf581 feat: Update command validation tools and improve README documentation 2026-01-24 08:41:32 +08:00
catlog22
24a28f289d refactor: Rename command-registry.js to command-registry.cjs and update references 2026-01-23 23:54:08 +08:00
catlog22
e727a07fc5 feat: Implement CCW Coordinator for interactive command orchestration
- Add action files for session management, command selection, building, execution, and completion.
- Introduce orchestrator logic to drive state transitions and action selection.
- Create state schema to define session state structure.
- Develop command registry and validation tools for command metadata extraction and chain validation.
- Establish skill configuration and specifications for command library and validation rules.
- Implement tools for command registry and chain validation with CLI support.
2026-01-23 23:39:16 +08:00
catlog22
8179472e56 fix: auto-sync CLI tools availability on first config creation (Issue #95)
**问题描述**:
新安装 CCW 后,默认配置中所有 CLI 工具 enabled: true,但实际上用户可能没有安装这些工具,导致执行任务时尝试调用未安装的工具而失败。

**根本原因**:
- DEFAULT_TOOLS_CONFIG 中所有工具默认 enabled: true
- 首次创建配置时不检测工具实际可用性
- 现有的 syncBuiltinToolsAvailability() 只在用户手动触发时才执行

**修复内容**:
1. 新增 ensureClaudeCliToolsAsync() 异步版本
   - 在创建默认配置后自动调用 syncBuiltinToolsAvailability()
   - 通过 which/where 命令检测工具实际可用性
   - 根据检测结果自动调整 enabled 状态

2. 更新两个关键 API 端点使用新函数
   - /api/cli/endpoints - 获取 API 端点列表
   - /api/cli/tools-config - 获取 CLI 工具配置

**效果**:
- 首次安装时自动检测并禁用未安装的工具
- 避免调用不可用工具导致的错误
- 用户可在 Dashboard 中看到准确的工具状态

Fixes #95
2026-01-23 23:20:58 +08:00
catlog22
277b3f86f1 feat: Enhance TDD workflow with specialized executor and optimized task generation
- Create tdd-developer.md: Specialized TDD agent with Red-Green-Refactor awareness
  - Full TDD metadata parsing (tdd_workflow, max_iterations, cli_execution)
  - Green phase Test-Fix Cycle with automatic diagnosis and repair
  - CLI session resumption strategies (new/resume/fork/merge_fork)
  - Auto-revert safety mechanism when max_iterations reached

- Optimize task-generate-tdd.md: Enhanced task generation with CLI support
  - Phase 0: User configuration questionnaire (materials, execution method, CLI tool)
  - Phase 1: Progressive loading strategy (Core → Selective → On-Demand)
  - CLI Execution ID management with dependency-based strategy selection
  - Fixed task limit to 18 (consistent with system-wide limit)
  - Fixed double-slash path issues in output structure
  - Enhanced tdd_cycles schema documentation with full structure
  - Unified resume_from type documentation (string | string[])

- Update tdd-plan.md: Workflow orchestrator improvements
  - Phase 0 user configuration details
  - Enhanced validation rules for CLI execution IDs
  - Updated error handling for 18-task limit

Validated by Gemini CLI analysis - complete execution chain compatibility confirmed.
2026-01-23 23:01:56 +08:00
catlog22
7a6f4c3f22 chore: bump version to 6.3.43 - fix parallel-dev-cycle documentation inconsistencies 2026-01-23 17:52:12 +08:00
catlog22
2f32d08d87 feat: Update documentation and file references for changes.log in parallel development cycle 2026-01-23 17:51:21 +08:00
catlog22
79d20add43 feat: Enhance Code Developer and Requirements Analyst agents with proactive debugging and self-enhancement strategies 2026-01-23 17:41:17 +08:00
catlog22
f363c635f5 feat: Enhance issue loading with intelligent grouping for batch processing 2026-01-23 17:03:27 +08:00
catlog22
61e3747768 feat: Add batch solutions endpoint (ccw issue solutions)
- Add solutionsAction() to query all bound solutions in one call
- Reduces O(N) queries to O(1) for queue formation
- Update /issue:queue command to use new endpoint
- Performance: 18 individual queries → 1 batch query

Version: 6.3.42
2026-01-23 16:56:08 +08:00
catlog22
54ec6a7c57 feat: Enhance issue management with batch processing and solution querying
- Updated issue loading process to create batches based on size (max 3 per batch).
- Removed semantic grouping in favor of simple size-based batching.
- Introduced a new command to batch query solutions for multiple issues.
- Improved solution loading to fetch all planned issues with bound solutions in a single call.
- Added detailed handling for multi-solution issues, including user selection for binding.
- Created a new workflow command for multi-agent development with documented progress and incremental iteration support.
- Added .gitignore for ace-tool directory to prevent unnecessary files from being tracked.
2026-01-23 16:55:10 +08:00
catlog22
d6a3da2084 chore: bump version to 6.3.41 2026-01-23 12:40:01 +08:00
catlog22
b9f17f0fcf fix: Add required 'name' field to Codex skill YAML frontmatter
According to OpenAI Codex skill specification, SKILL.md files must have both
'name' and 'description' fields in YAML frontmatter. Added missing 'name' field
to all three skills:
- CCW Loop
- CCW Loop-B
- Parallel Dev Cycle

Also enhanced ccw-loop description with Chinese trigger keywords for better
multi-language support.
2026-01-23 12:38:45 +08:00
catlog22
88eb42f65b chore: bump version to 6.3.40 2026-01-23 10:23:43 +08:00
catlog22
b1ac0cf8ff feat: Add communication optimization and coordination protocol for multi-agent system
- Introduced a new specification for agent communication optimization focusing on file references instead of content transfer to enhance efficiency and reduce message size.
- Established a coordination protocol detailing communication channels, message formats, and dependency resolution strategies among agents (RA, EP, CD, VAS).
- Created a unified progress format specification for all agents, standardizing documentation structure and versioning practices.
2026-01-23 10:04:31 +08:00
catlog22
09eeb84cda chore: bump version to 6.3.39 2026-01-22 23:39:02 +08:00
catlog22
2fb1d1243c feat: prioritize user config, do not merge default tools
Changed loadClaudeCliTools() to only load tools explicitly defined
in user config. Previously, DEFAULT_TOOLS_CONFIG.tools was spread
before user tools, causing all default tools to be loaded even if
not present in user config.

User config now has complete control over which tools are loaded.
2026-01-22 23:37:42 +08:00
catlog22
ac62bf70db fix: preserve envFile in ensureToolTags merge function
The ensureToolTags() function was only returning enabled, primaryModel,
secondaryModel, and tags - missing envFile. This caused envFile to be
lost during config merge in loadClaudeCliTools().

Related to #96 - gemini envFile setting lost after page refresh
2026-01-22 23:35:33 +08:00
catlog22
edb55c4895 fix: include envFile in getFullConfigResponse API response
Fixes #96 - gemini/qwen envFile setting was lost after page refresh
because getFullConfigResponse() was not including the envFile field
when converting config to the legacy API format.

Changes:
- Add envFile?: string | null to CliToolConfig interface
- Include envFile in getFullConfigResponse() conversion
2026-01-22 23:30:01 +08:00
catlog22
8a7f636a85 feat: Refactor intelligent cleanup command for clarity and efficiency 2026-01-22 23:25:34 +08:00
catlog22
97ab82628d Add intelligent cleanup command with mainline detection and artifact discovery
- Introduced the `/workflow:clean` command for intelligent code cleanup.
- Implemented mainline detection to identify active development branches and core modules.
- Added drift analysis to discover stale sessions, abandoned documents, and dead code.
- Included safe execution features with staged deletion and confirmation.
- Documented usage, execution process, and implementation details in `clean.md`.
2026-01-22 23:19:54 +08:00
catlog22
be89552b0a feat: Add ccw-loop-b hybrid orchestrator skill with specialized workers
Create new ccw-loop-b skill implementing coordinator + workers architecture:

**Skill Structure**:
- SKILL.md: Entry point with three execution modes (interactive/auto/parallel)
- phases/state-schema.md: Unified state structure
- specs/action-catalog.md: Complete action reference

**Worker Agents**:
- ccw-loop-b-init.md: Session initialization and task breakdown
- ccw-loop-b-develop.md: Code implementation and file operations
- ccw-loop-b-debug.md: Root cause analysis and problem diagnosis
- ccw-loop-b-validate.md: Testing, coverage, and quality checks
- ccw-loop-b-complete.md: Session finalization and commit preparation

**Execution Modes**:
- Interactive: Menu-driven, user selects actions
- Auto: Predetermined sequential workflow
- Parallel: Concurrent worker execution with batch wait

**Features**:
- Flexible coordination patterns (single/multi-agent/hybrid)
- Batch wait API for parallel execution
- Unified state management (.loop/ directory)
- Per-worker progress tracking
- No Claude/Codex comparison content (follows new guidelines)

Follows updated design principles:
- Content independence (no framework comparisons)
- Mode flexibility (no over-constraining)
- Coordinator pattern with specialized workers
2026-01-22 23:10:43 +08:00
catlog22
df25b43884 fix(install): change default for Git Bash multi-line prompt fix to false 2026-01-22 22:59:22 +08:00
catlog22
04cd536da5 chore: bump version to 6.3.38 2026-01-22 22:54:42 +08:00
catlog22
9a3608173a feat: Add multi-perspective issue discovery and structured issue creation
- Implemented issue discovery prompt to analyze code from various perspectives (bug, UX, test, quality, security, performance, maintainability, best-practices).
- Created structured issue generation prompt from GitHub URLs or text descriptions, including clarity detection and optional clarification questions.
- Introduced CCW Loop-B hybrid orchestrator pattern for iterative development, featuring a coordinator and specialized workers with batch wait support.
- Defined state management, session structure, and output schemas for the CCW Loop-B workflow.
- Added error handling and best practices documentation for the new features.
2026-01-22 22:53:05 +08:00
catlog22
f5b6bb97bc feat(issue-manager): update queue status display logic in renderQueueCard function 2026-01-22 22:33:44 +08:00
catlog22
2819f3597f feat: Add validation action and orchestrator for CCW Loop
- Implemented the VALIDATE action to run tests, check coverage, and generate reports.
- Created orchestrator for managing CCW Loop execution using Codex subagent pattern.
- Defined state schema for unified loop state management.
- Updated action catalog with new actions and their specifications.
- Enhanced CLI and issue routes to support new features and data structures.
- Improved documentation for Codex subagent design principles and action flow.
2026-01-22 22:32:37 +08:00
catlog22
c0c1a2eb92 fix(dashboard): make showHidden state match checkbox checked state
Fixes #97 - File browser "Show Hidden Files" checkbox appeared checked
but hidden files weren't displayed until the checkbox was toggled.

Root cause: Timing mismatch where loadFileBrowserDirectory() was called
before initFileBrowserEvents(), causing the initial API request to send
showHidden: false while the checkbox was checked.

Fix: Initialize fileBrowserState.showHidden = true in showFileBrowserModal()
to match the checkbox's default checked state.
2026-01-22 22:21:54 +08:00
catlog22
012197a861 删除 Plan-A 与 Plan-B 的比较部分,以简化文档内容 2026-01-22 21:42:20 +08:00
catlog22
407b2e6930 Add lightweight interactive planning workflows: Lite-Plan-B and Lite-Plan-C
- Introduced Lite-Plan-B for hybrid mode planning with multi-agent parallel exploration and primary agent merge/clarify/plan capabilities.
- Added Lite-Plan-C for Codex subagent orchestration, featuring intelligent task analysis, parallel exploration, and adaptive planning based on task complexity.
- Both workflows include detailed execution processes, session setup, and structured output formats for exploration and planning results.
2026-01-22 21:40:57 +08:00
catlog22
6428febdf6 Add universal-executor agent and enhance Codex subagent documentation
- Introduced a new agent: universal-executor, designed for versatile task execution across various domains with a systematic approach.
- Added comprehensive documentation for Codex subagents, detailing core architecture, API usage, lifecycle management, and output templates.
- Created a new markdown file for Codex subagent usage guidelines, emphasizing parallel processing and structured deliverables.
- Updated codex_prompt.md to clarify the deprecation of custom prompts in favor of skills for reusable instructions.
2026-01-22 20:41:37 +08:00
catlog22
9f9ef1d054 Refactor code structure for improved readability and maintainability 2026-01-22 18:22:38 +08:00
catlog22
ea04663035 fix(multi-cli): populate multiCliPlan sessions in liteTaskDataStore
Fix task click handlers not working in multi-CLI planning detail page.

Root cause: liteTaskDataStore was not being populated with multiCliPlan
sessions during initialization, so task click handlers couldn't access
session data using currentSessionDetailKey.

Changes:
- navigation.js: Add code to populate multiCliPlan sessions in liteTaskDataStore
- notifications.js: Add code to populate multiCliPlan sessions when data refreshes

Now when task detail page loads, liteTaskDataStore contains the correct key
'multi-cli-${sessionId}' matching currentSessionDetailKey, allowing task
click handlers to find session data and open detail drawer.

Verified: Task clicks now properly open detail panel for all 7 tasks.
2026-01-22 15:41:01 +08:00
catlog22
f0954b3247 fix(lite-execute): pass project-guidelines.json to execution phase
Ensure buildExecutionPrompt includes project constraints reference,
maintaining consistency with full workflow (plan + execute) which passes
project_guidelines via context-package.json. This allows execution phase
to respect user-defined constraints (via /workflow:session:solidify).
2026-01-22 15:30:36 +08:00
catlog22
2fffe78dc9 fix(multi-cli): complete solution details display in summary tab (#98)
Fixed issue where multi-CLI planning solution cards only showed count,
feasibility, effort, and risk badges but had empty content area.

Changes:
- Enhanced renderMultiCliSummaryContent() to extract and display all solution fields
  - Solution name (name/title)
  - Feasibility score (feasibility)
  - Effort level (effort)
  - Risk level (risk)
  - Summary/description (summary)
  - Pros list (pros)
  - Cons list (cons)

- Added CSS styles for solution cards
  - .solution-details, .details-label, .details-list
  - .solution-header, .solution-title-row, .solution-badges
  - .badge with variants for feasibility/effort/risk

- Fixed related issues:
  - Added multiCliPlan support to backend data structures
  - Exposed liteTaskDataStore to window for global access
  - Fixed header left-alignment in detail pages
  - Added 'active' class to tab content for visibility

Files modified:
- ccw/src/templates/dashboard-js/views/lite-tasks.js
- ccw/src/templates/dashboard-css/04-lite-tasks.css
- ccw/src/core/server.ts
- ccw/src/core/routes/system-routes.ts
- ccw/src/templates/dashboard-js/state.js
- ccw/src/templates/dashboard-css/02-session.css
- ccw/src/config/litellm-api-config-manager.ts (fix homedir import)

Closes #98
2026-01-22 15:30:35 +08:00
catlog22
02531c4d15 feat: i18n for CLI history view; fix Claude session discovery path encoding
## Changes

### i18n 中文化 (i18n.js, cli-history.js)
- 添加 60+ 个翻译键用于 CLI 执行历史和对话详情
- 将 cli-history.js 中的硬编码英文字符串替换为 t() 函数调用
- 覆盖范围: 执行历史、对话详情、状态、工具标签、按钮、提示等

### 修复 Claude 会话追踪 (native-session-discovery.ts)
- 问题: Claude 使用路径编码存储会话 (D:\path -> D--path),但代码使用 SHA256 哈希导致无法发现
- 解决方案:
  - 添加 encodeClaudeProjectPath() 函数用于路径编码
  - 更新 ClaudeSessionDiscoverer.getSessions() 使用路径编码
  - 增强 extractFirstUserMessage() 支持多种消息格式 (string/array)
- 结果: Claude 会话现可正确关联,UI 按钮 "查看完整过程对话" 应可正常显示

## 验证
- npm run build 通过 
- Claude 会话发现 1267 个会话 
- 消息提取成功率 80% 
- 路径编码验证正确 
2026-01-22 14:53:38 +08:00
catlog22
5fa7524ad7 feat(loop): support external CLI tools (cli-wrapper) in task management
- Fix missing i18n translations: loop.add, loop.save, loop.cancel
- Replace hardcoded validTools with dynamic tool loading from cli-tools.json
- Support external CLI wrappers (like doubao) in task creation and updates
- Add getEnabledToolsList() helper to fetch enabled tools dynamically
- Update mapIssueToolToLoopTool() to accept any string tool name
- Update validateTool() to use dynamic tool list
- Change LoopTask.tool type from specific strings to string (accepts any tool)

This allows tasks to use any enabled CLI tool from configuration,
including builtin tools, cli-wrappers, and api-endpoints, not just
the hardcoded ['bash', 'gemini', 'codex', 'qwen', 'claude'].
2026-01-22 12:43:37 +08:00
catlog22
21fbdbc55e feat(loop-monitor): add 'In Development' badge and bump to v6.3.37
- Add 'In Development' (开发中) badge to Loop Monitor navigation item
- Use yellow highlight to indicate development status
- Add i18n translations: nav.inDevelopment ('In Dev' / '开发中')
- Bump version to 6.3.37

The Loop Monitor feature is now clearly marked as under development,
helping users understand it may have limited functionality.
2026-01-22 11:59:07 +08:00
catlog22
1f1a078450 feat(loop-monitor): implement dynamic tool loading for task modals
- Add getEnabledTools() async function to fetch tools from /api/cli/tools-config
- Cache enabled tools in window.enabledTools to avoid repeated API calls
- Replace hardcoded tool options in add task modal with dynamic generation
- Replace hardcoded tool options in edit task modal with dynamic generation
- Fallback to ['claude'] if no tools enabled, all tools if API fails
- Make showAddTaskModal() and showEditTaskModal() async functions
- Update editTask() to use await when calling showEditTaskModal()

Fixes issue where task modals only showed hardcoded tools instead of
loading enabled tools from CLI configuration.
2026-01-22 11:53:17 +08:00
catlog22
d3aeac4e9f style: replace square icon with inbox icon for created status
Icon Update:
- created status: square → inbox

Rationale:
- Inbox icon is more visually intuitive
- Better conveys the meaning of 'new/pending task'
- Improves visual clarity and user understanding

Status Icons Now:
- created: 📥 inbox (new/pending)
- running:  zap (active)
- paused: ⏸ pause (paused)
- completed: ✓ check (finished)
- failed: ⚠️ alert-triangle (error)
2026-01-22 11:46:43 +08:00
catlog22
e2e3d5a815 style: improve task list CSS styling and layout
Task List Styling Improvements:

1. Added .tasks-list-header styling
   - Flexbox layout with space-between alignment
   - Border bottom separator line
   - Proper heading (h4) with icon and spacing
   - Muted text color for counts

2. Added .task-list-empty styling
   - Full centered empty state container
   - Proper spacing and padding (3rem)
   - Icon styling with reduced opacity
   - Title and hint text with correct colors and sizes
   - Button margin adjustment

3. Enhanced .empty-state styling
   - Added button margin-top (1rem) for better spacing
   - Applied to both .empty-state and .empty-detail-state

Result: Task list now has consistent, professional styling with:
- Clear visual hierarchy for headers
- Properly centered empty states
- Better spacing and typography
- Improved user experience
2026-01-22 11:41:00 +08:00
catlog22
ddb7fb7d7a style: simplify loop cards and update status icons
Loop Cards:
- Remove left border accent from cards (cleaner look)
- Remove status-specific border-left colors
- Keep simple 1px border all around

Status Icons Updated:
- created: circle → square
- running: activity → zap (lightning bolt)
- paused: pause-circle → pause
- completed: check-circle-2 → check
- failed: x-circle → alert-triangle

Both renderLoopCard() and getStatusIcon() functions updated for consistency.
2026-01-22 11:33:45 +08:00
catlog22
62d5ce3f34 style: unify Loop Monitor UI design with improved clarity
Major visual improvements across all components:

Left Sidebar (Loop Cards):
- Enhanced card styling with better shadows and borders (4px left border)
- Improved hover states with subtle elevation
- Better selected state with primary color highlight
- Increased padding and spacing (1rem padding, 0.75rem margin)
- Cleaner status indicator badges

Right Panel (Detail View):
- Added background containers to all detail sections with borders
- Improved section headers with bottom borders for clear separation
- Enhanced progress items with individual card styling
- Better visual hierarchy with consistent spacing (1rem gaps)
- Added info-box component for V2 loop information

Meta Information:
- Detail-meta items now have pill-style backgrounds
- Dashed separator line for better visual grouping
- Improved spacing and padding

CLI Steps:
- Enhanced step cards with better borders and hover states
- 3px left accent border for status indication
- Smooth transitions on hover

Typography & Colors:
- Unified border-radius: 0.625rem for sections, 0.5rem for items
- Consistent background: hsl(var(--muted) / 0.25) for sections
- Better border opacity: hsl(var(--border) / 0.5) and 0.6 variants
- Improved font weights and sizes for clarity

Overall result: Cleaner, more professional interface with better visual hierarchy and clarity.
2026-01-22 11:20:16 +08:00
catlog22
15b3977e88 fix: reorganize left sidebar into 3-row layout
- Row 1: Tab buttons (循环 | 任务) + New Loop button
- Row 2: Filter dropdown (全部 / 运行中 / 已暂停 / 已完成 / 失败)
- Row 3: Loop list items

This fixes the layout issue where multiple elements were stacking vertically
and appearing on multiple lines. Now creates a clear, organized left panel.
2026-01-22 11:13:07 +08:00
catlog22
d70f02abed fix: resolve Loop Monitor UI styling issues
- Add missing i18n keys: 'loop.listView' and 'loop.addTask' for both English and Chinese
- Fix kanban board header layout: wrap title and loop name in separate container (.kanban-header-left)
- Add CSS styling for .kanban-header-left and .kanban-loop-title to properly display loop titles
- Improve visual separation between 'Tasks Board' label and loop title

This fixes the issue where loop titles were appearing inline with the 'Tasks Board' header,
making them appear jumbled (e.g., '任务看板 在' instead of '任务看板' | '在').
2026-01-22 11:07:47 +08:00
catlog22
e11c4ba8ed feat: Loop Monitor UI optimization - Phases 1-6 complete
Complete comprehensive optimization of Loop Monitor interface with 6 phases:

Phase 1: Internationalization (i18n)
- Added 28 new translation keys (English + Chinese)
- Complete dual-language support for all new features
- Coverage: kanban board, task status, navigation, priority

Phase 2: CSS Styling Optimization
- 688 lines of kanban board styling system
- Task cards, status badges, priority badges
- Drag-and-drop visual feedback
- Base responsive design

Phase 3: UI Layout Design
- Left navigation panel optimization
- Kanban board layout (4 columns: Pending, In Progress, Blocked, Done)
- Task card information architecture
- Status update flow design

Phase 4: Backend API Extensions
- New PATCH /api/loops/v2/:loopId/status endpoint for quick status updates
- Extended PUT /api/loops/v2/:loopId with metadata support (tags, priority, notes)
- Enhanced V2LoopStorage interface
- Improved validation and error handling
- WebSocket broadcasting for real-time updates

Phase 5: Frontend JavaScript Implementation
- 967 lines of interactive functionality
- View switching system (Loops ↔ Kanban)
- Kanban board rendering with 4-column layout
- Drag-and-drop functionality (HTML5 API)
- Status update functions (updateLoopStatus, updateTaskStatus, updateLoopMetadata)
- Task context menu (right-click)
- Navigation grouping by status

Phase 6: Final Optimization
- Smooth animations (@keyframes slideInUp, fadeIn, modalFadeIn, pulse)
- Enhanced responsive design (desktop, tablet, mobile)
- Full ARIA accessibility support
- Complete keyboard navigation (arrow keys, Enter/Space, Ctrl+K, ?)
- Performance optimizations (debounce, throttle, will-change)
- Screen reader support

Key Features:
 Kanban board with drag-and-drop task management
 Task status management (pending, in_progress, blocked, done)
 Loop status quick update via PATCH API
 Navigation grouping with status-based filtering
 Full keyboard navigation support
 ARIA accessibility attributes
 Responsive design (mobile, tablet, desktop)
 Smooth animations and transitions
 Internationalization (English & Chinese)
 Performance optimizations

Code Statistics:
- Total: ~1798 lines
- loop-monitor.js: +967 lines (frontend logic)
- 36-loop-monitor.css: +688 lines (styling)
- loop-v2-routes.ts: +86/-3 lines (API backend)
- i18n.js: +60 lines (translations)

Technical Stack:
- JavaScript ES6+ (frontend)
- CSS3 with animations
- TypeScript (backend)
- HTML5 Drag & Drop API
- ARIA accessibility
- Responsive design

Browser Compatibility:
- Chrome/Edge 90+
- Firefox 88+
- Safari 14+

All TypeScript compilation tests pass. Ready for production deployment.
2026-01-22 11:01:05 +08:00
catlog22
60eab98782 feat: Add comprehensive tests for CCW Loop System flow state
- Implemented loop control tasks in JSON format for testing.
- Created comprehensive test scripts for loop flow and standalone tests.
- Developed a shell script to automate the testing of the entire loop system flow, including mock endpoints and state transitions.
- Added error handling and execution history tests to ensure robustness.
- Established variable substitution and success condition evaluations in tests.
- Set up cleanup and workspace management for test environments.
2026-01-22 10:13:00 +08:00
catlog22
d9f1d14d5e feat: add CCW Loop System for automated iterative workflow execution
Implements a complete loop execution system with multi-loop parallel support,
dashboard monitoring, and comprehensive security validation.

Core features:
- Loop orchestration engine (loop-manager, loop-state-manager)
- Multi-loop parallel execution with independent state management
- REST API endpoints for loop control (pause, resume, stop, retry)
- WebSocket real-time status updates
- Dashboard Loop Monitor view with live updates
- Security: path traversal protection and sandboxed JavaScript evaluation

Test coverage:
- 42 comprehensive tests covering multi-loop, API, WebSocket, security
- Security validation for success_condition injection attacks
- Edge case handling and end-to-end workflow tests
2026-01-21 22:55:24 +08:00
catlog22
64e064e775 feat(workflow): enhance lite-fix to support plan.json new fields (rationale, verification, risks)
- Add rationale/verification field generation for Medium severity bugs
- Add risks/code_skeleton/data_flow field support for High/Critical severity
- Update fix-plan.json requirements in cli-lite-planning-agent prompt
- Ensure executionContext includes complexity field for lite-execute consumption
- Align with plan-json-schema.json complexity-based field requirements
2026-01-21 22:35:54 +08:00
catlog22
8c1d62208e chore: bump version to 6.3.36 2026-01-21 19:50:51 +08:00
catlog22
c4960c3e84 feat: 添加基于文件的交互式假设驱动调试功能,记录探索过程和理解演变 2026-01-21 19:49:03 +08:00
catlog22
82b8fcc608 feat: 增加失败历史详情渲染功能,展示失败反馈信息 2026-01-21 18:32:52 +08:00
catlog22
a7c8ea04f1 feat: 增加失败分析功能,改进问题规划和解决方案生成 2026-01-21 17:46:22 +08:00
catlog22
2084ff3e21 fix: 增加对空设置文件的处理,确保返回空对象 2026-01-21 17:04:16 +08:00
catlog22
890ca455b2 Revert "feat: 调整主面板位置和高度以改善布局"
This reverts commit 572c103fbf.
2026-01-21 16:34:36 +08:00
catlog22
1dfabf6bda fix: resolve CodexLens installation issues by correcting package name and improving local path detection
- Updated package name from `codexlens` to `codex-lens` in all relevant files to ensure consistency with `pyproject.toml`.
- Enhanced `findLocalPackagePath()` to always search for local paths, even when running from `node_modules`.
- Removed fallback logic for PyPI installation in several functions, providing clearer error messages for local installation failures.
- Added detailed documentation on installation steps and error handling for local development packages.
- Introduced a new summary document outlining the issues and fixes related to CodexLens installation.
2026-01-21 15:32:41 +08:00
catlog22
604405b2d6 chore: bump version to 6.3.35 2026-01-21 14:39:52 +08:00
catlog22
190d2280fd feat: 更新codex-review和lite-execute命令示例,增加多种用法说明 2026-01-21 14:36:22 +08:00
catlog22
4e66864cfd chore: bump version to 6.3.34 2026-01-21 13:02:54 +08:00
catlog22
cac0566627 feat: 更新检查更新按钮的加载状态和通知功能,增加工具提示 2026-01-21 13:00:25 +08:00
catlog22
572c103fbf feat: 调整主面板位置和高度以改善布局 2026-01-21 12:40:32 +08:00
catlog22
9d6bc92837 feat: add workflow management commands and utilities
- Implemented workflow installation, listing, and syncing commands in `workflow.ts`.
- Created utility functions for project root detection and package version retrieval in `project-root.ts`.
- Added update checker functionality to notify users of new package versions in `update-checker.ts`.
- Developed unit tests for project root utilities and update checker to ensure functionality and version comparison accuracy.
2026-01-21 12:35:33 +08:00
catlog22
ffe9898fd3 feat: 增加调试日志以跟踪活动执行状态和钩子事件 2026-01-21 11:15:53 +08:00
catlog22
a602a46985 feat: 更新 LSP 测试,调整测试文件和增加分析等待时间 2026-01-21 10:57:36 +08:00
catlog22
f7dd3d23ff feat: 添加多个 LSP 测试示例,包括能力测试、调用层次和原始 LSP 测试 2026-01-21 10:43:53 +08:00
catlog22
200812d204 feat: 更新 CLI 自动调用触发器和执行原则,增强文档说明 2026-01-20 22:14:45 +08:00
catlog22
261c98549d feat: Implement association tree for LSP-based code relationship discovery
- Add `association_tree` module with components for building and processing call association trees using LSP call hierarchy capabilities.
- Introduce `AssociationTreeBuilder` for constructing call trees from seed locations with depth-first expansion.
- Create data structures: `TreeNode`, `CallTree`, and `UniqueNode` for representing nodes and relationships in the call tree.
- Implement `ResultDeduplicator` to extract unique nodes from call trees and assign relevance scores based on depth, frequency, and kind.
- Add unit tests for `AssociationTreeBuilder` and `ResultDeduplicator` to ensure functionality and correctness.
2026-01-20 22:09:04 +08:00
catlog22
b85d9b9eb1 feat(workflow): 更新 multi-cli-plan 采用 in-memory 调用模式
- Phase 4 扩展:收集执行方法和代码审查工具选项
- Phase 5 重构:构建 executionContext 并调用 lite-execute --in-memory
- 移除 IMPL_PLAN.md 生成,仅保留 plan.json
- 更新执行流程图和相关文档
- executionContext 结构与 lite-plan 保持一致
- 修改 Agent Roles 职责描述
2026-01-20 20:33:38 +08:00
catlog22
4610018193 feat(lsp): 更新 TypeScript 语言服务器命令以支持 Windows 环境 2026-01-20 15:28:18 +08:00
catlog22
9c9b1ad01c Add TypeScript LSP setup guide and enhance debugging tests
- Created a comprehensive guide for setting up TypeScript LSP in Claude Code, detailing installation methods, configuration, and troubleshooting.
- Added multiple debugging test scripts to validate LSP communication with pyright, including direct communication tests, configuration checks, and document symbol retrieval.
- Implemented error handling and logging for better visibility during LSP interactions.
2026-01-20 14:53:18 +08:00
catlog22
2f3a14e946 Add unit tests for LspGraphBuilder class
- Implement comprehensive unit tests for the LspGraphBuilder class to validate its functionality in building code association graphs.
- Tests cover various scenarios including single level graph expansion, max nodes and depth boundaries, concurrent expansion limits, document symbol caching, error handling during node expansion, and edge cases such as empty seed lists and self-referencing nodes.
- Utilize pytest and asyncio for asynchronous testing and mocking of LspBridge methods.
2026-01-20 12:49:31 +08:00
catlog22
1376dc71d9 feat(workflow): 更新 lite-lite-lite 和 tdd-plan 文档,增强描述和工具支持 2026-01-20 11:59:06 +08:00
catlog22
c1d12384c3 feat(mcp): 添加 CCW_DISABLE_SANDBOX 环境变量支持禁用工作空间访问限制
- 在 path-validator.ts 中添加 isSandboxDisabled() 函数
- 修改 validatePath() 在沙箱禁用时跳过路径限制检查
- MCP server 启动日志显示沙箱状态
- /api/mcp-install-ccw API 支持 disableSandbox 参数
- Dashboard UI 添加禁用沙箱的复选框选项
- 添加中英文 i18n 翻译支持
2026-01-20 11:50:23 +08:00
catlog22
eea859dd6f fix(cli): 修复 Windows 路径反斜杠被吞掉的问题并添加跨平台路径支持
- 重写 escapeWindowsArg 函数,正确处理反斜杠和引号转义
- 添加 escapeUnixArg 函数支持 Linux/macOS shell 转义
- 添加 normalizePathSeparators 函数自动转换路径分隔符
- 修复 vscode-lsp.ts 中的 TypeScript 类型错误
2026-01-20 09:44:49 +08:00
catlog22
3fe630f221 Add tests and documentation for CodexLens LSP tool
- Introduced a new test script for the CodexLens LSP tool to validate core functionalities including symbol search, find definition, find references, and get hover.
- Created comprehensive documentation for the MCP endpoint design, detailing the architecture, features, and integration with the CCW MCP Manager.
- Developed a detailed implementation plan for transitioning to a real LSP server, outlining phases, architecture, and acceptance criteria.
2026-01-19 23:26:35 +08:00
catlog22
eeaefa7208 feat(queue): 添加队列合并功能,支持跳过重复项并标记源队列为已合并 2026-01-19 15:35:41 +08:00
catlog22
e58c33fb6e fix(cli-history): 转义 sourceDir 以支持 onclick 处理程序 2026-01-19 12:22:33 +08:00
catlog22
6716772e0a fix(codexlens): 添加 Yarn PnP 支持以改进环境检测
问题分析:
- Yarn PnP 不使用 node_modules 目录
- 原有逻辑仅检测 node_modules 会错误识别为开发环境
- 导致在 Yarn PnP 项目中尝试使用本地路径安装失败

修复内容:
- 在 isDevEnvironment() 中添加 Yarn PnP 检测
- 检查 process.versions.pnp 属性判断是否为 Yarn PnP 环境
- Yarn PnP 环境被视为生产环境,使用 PyPI 安装

改进影响:
- npm/pnpm: 使用 node_modules 检测(原有逻辑)
- Yarn PnP: 使用 pnp 版本检测(新增逻辑)
- 开发环境: 两项检测均不满足时识别为开发环境

Based on Gemini code review suggestion (ID: 1768794060352-gemini)
2026-01-19 11:43:12 +08:00
catlog22
a8367bd4d7 fix(codexlens): 修复 npm install 后 CodexLens 配置被重置的问题
问题分析:
- npm install 时,`__dirname` 指向 node_modules 内的路径
- 使用 `pip install -e`(editable mode)会保存源码路径引用
- npm 升级后旧路径失效,导致需要删除虚拟环境才能重新安装

修复内容:
- 添加 isInsideNodeModules() 检测函数
- 添加 isDevEnvironment() 判断是否在开发环境
- 添加 findLocalPackagePath() 统一的本地包路径查找函数
- 当运行在 node_modules 中时,跳过本地路径,直接使用 PyPI 安装

影响的函数:
- bootstrapWithUv()
- installSemanticWithUv()
- bootstrapVenv()
- ensureLiteLLMEmbedderReady()

行为变化:
- 开发环境(不在 node_modules 中):使用本地路径安装(editable mode)
- 生产环境(npm install 安装):使用 PyPI 安装(稳定的包引用)
2026-01-19 11:32:50 +08:00
catlog22
ea13f9a575 fix(config): 修复测试污染用户配置的问题,支持 CCW_DATA_DIR 环境变量
修改内容:
- getGlobalConfigPath() 和 getGlobalSettingsPath() 现在尊重 CCW_DATA_DIR 环境变量
- ensureClaudeCliTools()、saveClaudeCliTools()、saveClaudeCliSettings() 同步更新
- 测试现在使用独立的临时目录,不会修改用户的生产配置文件 ~/.claude/cli-tools.json

修复问题:
- 集成测试会修改用户的 gemini primaryModel 为 test-model
- 导致后续 Codex CLI 执行时读取到错误的配置

验证:
- 所有集成测试通过 (4/4)
- 用户配置保持不变
- 生产环境默认行为不受影响
2026-01-19 11:28:06 +08:00
catlog22
7d152b7bf9 feat(doc): 添加 CLI 自动触发调用场景和执行原则 2026-01-18 19:51:00 +08:00
catlog22
16c96229f9 feat(cli): add agent_message type for precise --final output filtering
Introduce dedicated agent_message IR type to distinguish final AI responses
from generic stdout. This enables --final flag to show only agent messages,
filtering out all intermediate content (JSONL events, reasoning, tool calls).

Changes:
- Add agent_message type to CliOutputUnitType
- Update JsonLinesParser to map final responses from all tools (codex,
  gemini, claude, opencode) to agent_message type
- Add final_output field to database schema with migration
- Update getCachedOutput and getConversation to return finalOutput
- Prefer finalOutput in outputAction for --final flag

Fixes issue where --final showed raw JSONL instead of filtered content.
2026-01-18 19:49:33 +08:00
catlog22
40b003be68 fix(cli): 增强 CLI 输出处理,添加解析输出和过滤功能 2026-01-18 18:35:23 +08:00
catlog22
46111b3987 fix(cli): 更新提示格式以包含协议和模板信息 2026-01-18 14:22:36 +08:00
catlog22
f47726d43b fix(cli): 更新 CLI 流查看器的样式以确保在深色背景上文本可见性 2026-01-18 13:48:20 +08:00
catlog22
502d088c98 feat(cli): 添加交互式选择功能以选择 shell 配置文件并安装 Git Bash 修复 2026-01-18 13:03:22 +08:00
catlog22
f845e6e0ee fix(cli): 修复安全审计示例中的多行提示格式 2026-01-18 12:02:05 +08:00
catlog22
e96eed817c fix(cli): 修复多行提示的命令示例,更新为正确的用法 2026-01-18 12:01:42 +08:00
catlog22
6a6d1885d8 feat(install): 添加 Git Bash 多行提示修复功能并在卸载时询问移除
refactor(cli): 删除不再使用的 CLI 脚本和测试文件
fix(cli): 移除多行参数提示的输出
2026-01-18 11:53:49 +08:00
catlog22
a34eeb63bf feat(cli): add CLI prompt simulation and testing scripts
- Introduced `simulate-cli-prompt.js` to simulate various prompt formats and display the final content passed to the CLI.
- Added `test-shell-prompt.js` to test actual shell execution of different prompt formats, demonstrating correct vs incorrect multi-line prompt handling.
- Created comprehensive tests in `cli-prompt-parsing.test.ts` to validate prompt parsing, including single-line, multi-line, special characters, and template concatenation.
- Implemented edge case handling for empty lines, long prompts, and Unicode characters.
2026-01-18 11:10:05 +08:00
catlog22
56acc4f19c fix(cli): 修复通用提示模板格式,移除多余换行 2026-01-17 22:46:09 +08:00
catlog22
fdf468ed99 refactor(cli): 移除关于 --rule 选项的工作原理说明 2026-01-17 22:08:36 +08:00
catlog22
680c2a0597 fix(cli): allow codex review with target flags without prompt
- Skip template concatenation when using --uncommitted/--base/--commit
- Allow empty prompt for review mode with target flags
- Add hasReviewTarget check in command routing
- Update documentation with validation constraints

codex review constraint: target flags and prompt are mutually exclusive
2026-01-17 22:07:26 +08:00
catlog22
5b5dc85677 refactor(cli): change from env var injection to direct prompt concatenation
- Replace $PROTO/$TMPL environment variable injection with systemRules/roles direct concatenation
- Append rules to END of prompt instead of prepending
- Change prompt field name from RULES to CONSTRAINTS in all prompts
- Default to universal-rigorous-style template when --rule not specified
- Update all .claude documentation, agents, commands, and skills
- Add streaming_content type support for Gemini delta messages

Breaking: Prompts now use CONSTRAINTS field instead of RULES
2026-01-17 21:30:05 +08:00
catlog22
1e691fa751 feat(cli): default to universal-rigorous-style template when --rule not specified
- Add default template fallback in cli.ts (effectiveRule)
- Update cli-tools-usage.md with English descriptions
- Add ACE semantic search to Pattern Discovery Workflow
- Simplify Template System documentation (list template names only)
- Filter CLI progress messages (auth, loading) in output converter

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-17 19:51:21 +08:00
catlog22
1f87ca0be3 refactor(routes): 更新 rules-routes 和 claude-routes 使用 $PROTO $TMPL
- rules-routes.ts: 替换 4 处 $(cat ...) 模板引用为 $PROTO $TMPL
- claude-routes.ts: 替换 2 处 $(cat ...) 模板引用为 $PROTO $TMPL
- 添加 loadProtocol/loadTemplate 导入
- 在 executeCliTool 调用中添加 rulesEnv 参数

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-17 19:40:28 +08:00
catlog22
f14418603a feat(cli): 添加 --rule 选项支持模板自动发现
重构 ccw cli 模板系统:

- 新增 template-discovery.ts 模块,支持扁平化模板自动发现
- 添加 --rule <template> 选项,自动加载 protocol 和 template
- 模板目录从嵌套结构 (prompts/category/file.txt) 迁移到扁平结构 (prompts/category-function.txt)
- 更新所有 agent/command 文件,使用 $PROTO $TMPL 环境变量替代 $(cat ...) 模式
- 支持模糊匹配:--rule 02-review-architecture 可匹配 analysis-review-architecture.txt

其他更新:
- Dashboard: 添加 Claude Manager 和 Issue Manager 页面
- Codex-lens: 增强 chain_search 和 clustering 模块

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-17 19:20:24 +08:00
catlog22
1fae35c05d docs: 添加 Semantic CLI Invocation 实践说明 2026-01-17 11:44:27 +08:00
catlog22
8523079a99 docs: 更新 ACE Tool 配置文档 2026-01-17 11:40:30 +08:00
catlog22
4daeb0eead docs: 打字机动画增加 OpenCode 2026-01-17 11:36:03 +08:00
catlog22
86548af518 docs: 修复语义CLI和文档表格居中
- 添加 div align center 包裹 Semantic CLI Invocation 表格
- 添加 div align center 包裹 Documentation 表格
- 同步更新中英文 README 文件
2026-01-17 11:35:10 +08:00
catlog22
4e5eb6cd40 docs: 修复核心特性表格居中 2026-01-17 11:28:31 +08:00
catlog22
021ce619f0 docs: 表格居中对齐 2026-01-17 11:26:02 +08:00
catlog22
63aaab596c docs: 统一简约风格
- 徽章改为 flat-square 风格
- 移除表格内所有 emoji 图标
- 保留章节标题图标
- 统一色彩方案
2026-01-17 11:23:38 +08:00
catlog22
bc52af540e docs: 重新设计酷炫主页
- 添加渐变动画 Header (capsule-render)
- 添加打字动画效果 (typing-svg)
- 使用 for-the-badge 风格徽章
- 添加 Stars/Forks/Issues 统计
- 使用 HTML 表格优化布局
- 添加快速导航按钮
- 使用折叠面板整理长内容
- 添加渐变动画 Footer
2026-01-17 11:17:33 +08:00
catlog22
8bbbdc61eb docs: 修复标题居中和 CLI 链接
- 标题移入 div align=center
- 修正 CLI 官方链接:
  - Gemini: google-gemini/gemini-cli
  - Codex: openai/codex
  - OpenCode: opencode-ai/opencode
  - Qwen: QwenLM
2026-01-17 11:09:23 +08:00
catlog22
fd5f6c2c97 docs: 简化 CLI 工具安装说明
- 移除详细配置步骤
- 使用表格形式简明展示
- 提供官方文档链接
2026-01-17 11:06:21 +08:00
catlog22
fd145c34cd docs: 优化自定义 CLI 注册说明
- 明确通过 Dashboard 界面注册
- 简化配置说明为表格形式
- 强调注册一次永久语义调用
2026-01-17 11:05:30 +08:00
catlog22
10b3ace917 docs: 添加自定义 CLI 注册说明
- 通过 API Settings 注册任意 API 为自定义 CLI
- 注册后可语义调用自定义 CLI
- 支持自定义 CLI 与内置 CLI 协同编排
2026-01-17 11:02:20 +08:00
catlog22
d6a2e0de59 docs: 添加语义化 CLI 调用说明
- 用户语义指定 CLI 工具,系统自动调用
- 支持协同、并行、迭代、流水线等编排模式
- 示例:'使用 Gemini 和 Codex 协同分析'
2026-01-17 11:01:29 +08:00
catlog22
35c6605681 docs: 简化 ACE Tool 配置为链接形式
- 官方文档: docs.augmentcode.com
- 代理版本: github.com/eastxiaodong/ace-tool
2026-01-17 10:50:35 +08:00
catlog22
ef2229b0bb docs: 更新 README.md 添加符号和 CLI 工具安装指南
- 添加 emoji 符号丰富视觉效果
- 添加 Gemini/Codex/OpenCode/Qwen CLI 安装说明
- 添加 ACE Tool 配置(官方和代理方式)
- 添加 CodexLens 开发状态说明
- Dashboard 功能表格化展示
- 与中文版 README_CN.md 结构保持一致
2026-01-17 10:44:41 +08:00
catlog22
b65977d8dc docs: 更新 README_CN.md 添加 CLI 工具安装指南和 CodexLens 说明
- 添加 Gemini/Codex/OpenCode/Qwen CLI 安装说明
- 添加 ACE Tool 配置(官方和代理方式)
- 添加 CodexLens 开发状态说明
- 精简文档结构与英文版保持一致
- 更新 4 级工作流系统说明
2026-01-17 10:42:38 +08:00
catlog22
bc4176fda0 docs: consolidate documentation with 4-level workflow guide
- Add WORKFLOW_GUIDE.md (EN) and WORKFLOW_GUIDE_CN.md (CN)
- Simplify README.md to highlight 4-level workflow system
- Remove redundant docs: MCP_*.md, WORKFLOW_DECISION_GUIDE*.md, WORKFLOW_DIAGRAMS.md
- Move COMMAND_SPEC.md to docs/
- Move codex_mcp.md, CODEX_LENS_AUTO_HYBRID.md to codex-lens/docs/
- Delete temporary debug documents and outdated files

Root directory: 28 → 14 MD files
2026-01-17 10:38:06 +08:00
catlog22
464f3343f3 chore: bump version to 6.3.33 2026-01-16 15:50:32 +08:00
catlog22
bb6cf42df6 fix: 更新 issue 执行文档,明确队列 ID 要求和用户交互流程 2026-01-16 15:49:26 +08:00
catlog22
0f0cb7e08e refactor: 优化 brainstorm 上下文溢出保护文档
- conceptual-planning-agent.md: 34行 → 10行(-71%)
- auto-parallel.md: 42行 → 9行(-79%)
- 消除重复定义,workflow 引用 agent 限制
- 移除冗余的策略列表、自检清单、代码示例
- 保留核心功能:限制数字、简要策略、恢复方法
2026-01-16 15:36:59 +08:00
catlog22
39d070eab6 fix: resolve GitHub issues (#50, #54)
- #54: Add API endpoint configuration documentation to DASHBOARD_GUIDE.md
- #50: Add brainstorm context overflow protection with output size limits

Note: #72 and #53 not changed per user feedback - existing behavior is sufficient
(users can configure envFile themselves; default Python version is appropriate)
2026-01-16 15:09:31 +08:00
catlog22
9ccaa7e2fd fix: 更新 CLI 工具配置缓存失效逻辑 2026-01-16 14:28:10 +08:00
catlog22
eeb90949ce chore: bump version to 6.3.32
- Fix: Dashboard project overview display issue (#80)
- Refactor: Update project structure to use project-tech.json
2026-01-16 14:09:09 +08:00
catlog22
7b677b20fb fix: 更新项目文档,修正项目上下文和学习固化流程描述 2026-01-16 14:01:27 +08:00
catlog22
e2d56bc08a refactor: 更新项目结构,替换 project.json 为 project-tech.json,添加新架构和技术分析 2026-01-16 13:33:38 +08:00
catlog22
d515090097 feat: add --mode review support for codex CLI
- Add 'review' to mode enum in ParamsSchema and schema
- Implement codex review subcommand in buildCommand (uses --uncommitted by default)
- Other tools (gemini/qwen/claude) accept review mode but no operation change
- Update cli-tools-usage.md with review mode documentation
2026-01-16 13:01:02 +08:00
catlog22
d81dfaf143 fix: add cross-platform support for hook installation (#82)
- Add PlatformUtils module for platform detection (Windows/macOS/Linux)
- Add escapeForShell() for platform-specific shell escaping
- Add checkCompatibility() to warn about incompatible hooks before install
- Add getVariant() to support platform-specific template variants
- Fix node -e commands: use double quotes on Windows, single quotes on Unix
2026-01-16 12:54:56 +08:00
catlog22
d7e5ee44cc fix: adapt help-routes.ts to new command.json structure (fixes #81)
- Replace getIndexDir() with getCommandFilePath() to find command.json
- Update file watcher to monitor command.json instead of index/ directory
- Modify API routes to read from unified command.json structure
- Add buildWorkflowRelationships() to dynamically build workflow data from flow fields
- Add /api/help/agents endpoint for agents list
- Add category merge logic for frontend compatibility (cli includes general)
- Add cli-init command to command.json
2026-01-16 12:46:50 +08:00
catlog22
dde39fc6f5 fix: 更新 CLI 调用后说明,移除不必要的轮询建议 2026-01-16 09:40:21 +08:00
catlog22
9b4fdc1868 Refactor code structure for improved readability and maintainability 2026-01-15 22:43:44 +08:00
catlog22
623afc1d35 6.3.31 2026-01-15 22:30:57 +08:00
catlog22
085652560a refactor: 移除 ccw cli 内部超时参数,改由外部 bash 控制
- 移除 --timeout 命令行选项和内部超时处理逻辑
- 进程生命周期跟随父进程(bash)状态
- 简化代码,超时控制交由外部调用者管理
2026-01-15 22:30:22 +08:00
catlog22
af4ddb1280 feat: 添加队列和议题删除功能,支持归档议题 2026-01-15 19:58:54 +08:00
catlog22
7db659f0e1 feat: 增强议题搜索功能与多队列卡片界面优化
搜索增强:
- 添加防抖处理修复快速输入导致页面卡死的问题
- 扩展搜索范围至解决方案的描述和方法字段
- 新增搜索结果高亮显示匹配关键词
- 添加搜索下拉建议,支持键盘导航

多队列界面:
- 优化队列展开视图的卡片布局使用CSS Grid
- 添加取消激活队列功能及API端点
- 改进状态颜色分布和统计卡片样式
- 添加激活/取消激活按钮的中文国际化

修复:
- 修复路由冲突导致的deactivate 404错误
- 修复异步加载后拖拽排序失效的问题
2026-01-15 19:44:44 +08:00
catlog22
ba526ea09e fix: 修复 Dashboard 概况页面无法显示项目信息的问题
添加 extractStringArray 辅助函数来处理混合数组类型(字符串数组和对象数组),
使 loadProjectOverview 函数能够正确处理 project-tech.json 中的数据结构。

修复的字段包括:
- languages: 对象数组 [{name, file_count, primary}] → 字符串数组
- frameworks: 保持兼容字符串数组
- key_components: 对象数组 [{name, description, path}] → 字符串数组
- layers/patterns: 保持兼容混合类型

Closes #79
2026-01-15 18:58:42 +08:00
catlog22
c308e429f8 feat: 添加增量更新命令以支持单文件索引更新 2026-01-15 18:14:51 +08:00
catlog22
c24ed016cb feat: 更新执行命令文档,添加队列ID要求和用户提示功能 2026-01-15 16:22:48 +08:00
catlog22
0c9a6d4154 chore: bump version to 6.3.29
Release 6.3.29 with:
- Multi-CLI task and discussion tabs i18n support
- Collapsible sections for discussion and summary tabs
- Post-Completion Expansion for execution commands
- Enhanced multi-CLI session handling
- Code structure refactoring
2026-01-15 15:38:15 +08:00
catlog22
7b5c3cacaa feat: 添加多CLI任务和讨论标签的国际化支持 2026-01-15 15:35:09 +08:00
catlog22
e6e7876b38 feat: Add collapsible sections and enhance layout for discussion and summary tabs 2026-01-15 15:30:11 +08:00
catlog22
0eda520fd7 feat: Enhance multi-CLI session handling and UI updates
- Added loading of plan.json in scanMultiCliDir to improve task extraction.
- Implemented normalization of tasks from plan.json format to support new UI.
- Updated CSS for multi-CLI plan summary and task item badges for better visibility.
- Refactored hook-manager to use Node.js for cross-platform compatibility in command execution.
- Improved i18n support for new CLI tool configuration in the hook wizard.
- Enhanced lite-tasks view to utilize normalized tasks and provide better fallback mechanisms.
- Updated memory-update-queue to return string messages for better integration with hooks.
2026-01-15 15:20:20 +08:00
catlog22
e22b525e9c feat: add Post-Completion Expansion to execution commands
执行命令完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 /issue:new
2026-01-15 13:00:50 +08:00
catlog22
86536aaa10 Refactor code structure for improved readability and maintainability 2026-01-15 11:51:19 +08:00
catlog22
3ef766708f chore: bump version to 6.3.28
Fixes #74 - Include ccw/scripts/ in npm package files
2026-01-15 11:20:34 +08:00
catlog22
95a7f05aa9 Add unified command indices for CCW and CCW-Help with detailed capabilities, flows, and intent rules
- Introduced command.json for CCW-Help with 88 commands and 16 agents, covering essential workflows and memory management.
- Created command.json for CCW with comprehensive capabilities for exploration, planning, execution, bug fixing, testing, reviewing, and documentation.
- Defined complex flows for rapid iteration, full exploration, coupled planning, bug fixing, issue lifecycle management, and more.
- Implemented intent rules for bug fixing, issue batch processing, exploration, UI design, TDD, review, and documentation.
- Established CLI tools and injection rules to enhance command execution based on context and complexity.
2026-01-15 11:19:30 +08:00
catlog22
f692834153 fix: Status导航项现在正确显示CLI状态页面而非CLAUDE.md管理器
cli-manager视图路由错误调用了renderClaudeManager(),修复为调用正确的renderCliManager()函数。

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 10:38:19 +08:00
catlog22
a228bb946b fix: Issue Manager completed过滤器现在可以显示归档议题
- 添加 loadIssueHistory() 函数从 /api/issues/history 加载归档议题
- 修改 filterIssuesByStatus() 在选择 completed 过滤器时加载历史数据
- 修改 renderIssueView() 合并当前已完成议题和归档议题
- 修改 renderIssueCard() 显示 "Archived" 标签区分归档议题
- 修改 openIssueDetail() 支持从缓存加载归档议题详情
- 添加 .issue-card.archived 和 .issue-archived-badge CSS样式

Fixes: https://github.com/catlog22/Claude-Code-Workflow/issues/76

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-15 10:28:52 +08:00
catlog22
4d57f47717 feat: 更新搜索工具优先级指南,统一格式以提高可读性 2026-01-14 22:00:01 +08:00
catlog22
c8cac5b201 feat: 添加搜索工具优先级指南,优化CLI工具调用和执行策略 2026-01-14 21:46:36 +08:00
catlog22
f9c1216eec feat: 添加令牌消耗诊断功能,优化输出和状态管理 2026-01-14 21:40:00 +08:00
catlog22
266f6f11ec feat: Enhance documentation diagnosis and category mapping
- Introduced action to diagnose documentation structure, identifying redundancies and conflicts.
- Added centralized category mappings in JSON format for improved detection and strategy application.
- Updated existing functions to utilize new mappings for taxonomy and strategy matching.
- Implemented new detection patterns for documentation redundancy and conflict.
- Expanded state schema to include documentation diagnosis results.
- Enhanced severity criteria and strategy selection guide to accommodate new documentation issues.
2026-01-14 21:07:52 +08:00
catlog22
1f5ce9c03a Enhance CCW Orchestrator with Requirement Analysis Features
- Updated SKILL.md to reflect new requirement analysis capabilities, including input analysis and clarity scoring.
- Expanded issue workflow in issue.md to include discovery and creation phases, along with detailed command references.
- Introduced requirement analysis specification in requirement-analysis.md, outlining clarity scoring, dimension extraction, and validation processes.
- Added output templates specification in output-templates.md for consistent user experience across classification, planning, clarification, execution, and summary outputs.
2026-01-14 20:15:42 +08:00
catlog22
959d60b31f Enhance CLI Stream Viewer and Navigation Lifecycle Management
- Added lifecycle management for CLI Stream Viewer with destroy function to clean up event listeners and timers.
- Improved navigation state management by registering destroy functions for views and ensuring cleanup on transitions.
- Updated Claude Manager to include lifecycle functions for better resource management.
- Enhanced CLI History View with state reset functionality and improved dropdown handling for batch delete.
- Introduced round solutions rendering in Lite Tasks View, including collapsible sections for implementation plans, dependencies, and technical concerns.
2026-01-14 19:57:05 +08:00
catlog22
49845fe1ae feat: 扩展多CLI详细页面样式,更新任务卡片和决策状态显示 2026-01-14 18:47:23 +08:00
catlog22
aeb111420e feat: 添加多CLI计划支持,更新数据聚合和导航组件以处理新任务类型 2026-01-14 17:06:36 +08:00
catlog22
6ff3e5f8fe test: add unit tests for hook quoting fix (Issue #73)
Add comprehensive test suite for convertToClaudeCodeFormat function:
- Verify bash -c commands use single quotes
- Verify jq patterns are preserved without excessive escaping
- Verify single quotes in scripts are properly escaped
- Test all real-world hook templates (danger-*, ccw-notify, log-tool)
- Test edge cases (non-bash commands, already formatted data)

All 13 tests passing.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 15:22:52 +08:00
catlog22
d941166d84 fix: use single quotes for bash -c script to avoid jq escaping issues
Problem:
When generating hook configurations, the convertToClaudeCodeFormat function
was using double quotes to wrap bash -c script arguments. This caused
complex escaping issues with jq commands inside, leading to parse errors
like "jq: error: syntax error, unexpected end of file".

Solution:
For bash -c commands, now use single quotes to wrap the script argument.
Single quotes prevent shell expansion, so internal double quotes (like
those used in jq patterns) work naturally without excessive escaping.

If the script contains single quotes, they are properly escaped using
the '\'' pattern (close quote, escaped quote, reopen quote).

Fixes: https://github.com/catlog22/Claude-Code-Workflow/issues/73

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-14 15:07:04 +08:00
catlog22
ac9ba5c7e4 feat: 更新CLI分析调用部分,强调等待结果和价值评估,移除背景执行默认设置 2026-01-14 14:00:14 +08:00
catlog22
9e55f51501 feat: 添加需求分析功能,支持维度拆解、覆盖度评估和歧义检测 2026-01-14 13:42:57 +08:00
catlog22
43b8cfc7b0 feat: 添加CLI辅助意图分类和行动规划功能,增强复杂输入处理和执行策略优化 2026-01-14 13:23:22 +08:00
catlog22
633d918da1 Add quality gates and tuning strategies documentation
- Introduced quality gates specification for skill tuning, detailing quality dimensions, scoring, and gate definitions.
- Added comprehensive tuning strategies for various issue categories, including context explosion, long-tail forgetting, data flow, and agent coordination.
- Created templates for diagnosis reports and fix proposals to standardize documentation and reporting processes.
2026-01-14 12:59:13 +08:00
catlog22
6b4b9b0775 feat: enhance multi-CLI planning with new schema for solutions and implementation plans; improve file handling with async methods 2026-01-14 12:15:42 +08:00
catlog22
360d29d7be Enhance server routing to include dialog API endpoints
- Updated system routes in the server to handle dialog-related API requests.
- Added support for new dialog routes under the '/api/dialog/' path.
2026-01-14 10:51:23 +08:00
catlog22
4fe7f6cde6 feat: enhance CLI discussion agent and multi-CLI planning with JSON string support; improve error handling and internationalization 2026-01-13 23:51:46 +08:00
catlog22
6922ca27de Add Multi-CLI Plan feature and corresponding JSON schema
- Introduced a new navigation item for "Multi-CLI Plan" in the dashboard template.
- Created a new JSON schema for "Multi-CLI Discussion Artifact" to facilitate structured discussions and decision-making processes.
2026-01-13 23:46:15 +08:00
catlog22
c3da637849 feat(workflow): add multi-CLI collaborative planning command
- Introduced a new command `/workflow:multi-cli-plan` for collaborative planning using ACE semantic search and iterative analysis with Claude and Codex.
- Implemented a structured execution flow with phases for context gathering, multi-tool analysis, user decision points, and final plan generation.
- Added detailed documentation outlining the command's usage, execution phases, and key features.
- Included error handling and configuration options for enhanced user experience.
2026-01-13 23:23:09 +08:00
catlog22
2f1c56285a chore: bump version to 6.3.27
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 21:51:10 +08:00
catlog22
85972b73ea feat: update CSRF protection logic and enhance GPU detection method; improve i18n for hook wizard templates 2026-01-13 21:49:08 +08:00
catlog22
6305f19bbb chore: bump version to 6.3.26
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 21:33:24 +08:00
catlog22
275d2cb0af feat: Add environment file support for CLI tools
- Introduced a new input group for environment file configuration in the dashboard CSS.
- Updated hook manager to queue CLAUDE.md updates with configurable threshold and timeout.
- Enhanced CLI manager view to include environment file input for built-in tools (gemini, qwen).
- Implemented environment file loading mechanism in cli-executor-core, allowing custom environment variables.
- Added unit tests for environment file parsing and loading functionalities.
- Updated memory update queue to support dynamic configuration of threshold and timeout settings.
2026-01-13 21:31:46 +08:00
catlog22
d5f57d29ed feat: add issue discovery by prompt command with Gemini planning
- Introduced `/issue:discover-by-prompt` command for user-driven issue discovery.
- Implemented multi-agent exploration with iterative feedback loops.
- Added ACE semantic search for context gathering and cross-module comparison capabilities.
- Enhanced user experience with natural language input and adaptive exploration strategies.

feat: implement memory update queue tool for batching updates

- Created `memory-update-queue.js` for managing CLAUDE.md updates.
- Added functionality for queuing paths, deduplication, and auto-flushing based on thresholds and timeouts.
- Implemented methods for queue status retrieval, flushing, and timeout checks.
- Configured to store queue data persistently in `~/.claude/.memory-queue.json`.
2026-01-13 21:04:45 +08:00
catlog22
7d8b13f34f feat(mcp): add cross-platform MCP config support with Windows cmd /c auto-fix
- Add buildCrossPlatformMcpConfig() helper for automatic Windows cmd /c wrapping
- Add checkWindowsMcpCompatibility() to detect configs needing Windows fixes
- Add autoFixWindowsMcpConfig() to automatically fix incompatible configs
- Add showWindowsMcpCompatibilityWarning() dialog for user confirmation
- Simplify recommended MCP configs (ace-tool, chrome-devtools, exa) using helper
- Auto-detect and prompt when adding MCP servers with npx/npm/node/python commands
- Add i18n translations for Windows compatibility warnings (en/zh)

Supported commands for auto-detection: npx, npm, node, python, python3, pip, pip3, pnpm, yarn, bun

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 19:07:11 +08:00
catlog22
340137d347 fix: resolve GitHub issues #63, #66, #67, #68, #69, #70
- #70: Fix API Key Tester URL handling - normalize trailing slashes before
  version suffix detection to prevent double-slash URLs like //models
- #69: Fix memory embedder ignoring CodexLens config - add error handling
  for CodexLensConfig.load() with fallback to defaults
- #68: Fix ccw cli using wrong Python environment - add getCodexLensVenvPython()
  to resolve correct venv path on Windows/Unix
- #67: Fix LiteLLM API Provider test endpoint - actually test API key connection
  instead of just checking ccw-litellm installation
- #66: Fix help-routes.ts path configuration - use correct 'ccw-help' directory
  name and refactor getIndexDir to pure function
- #63: Fix CodexLens install state refresh - add cache invalidation after
  config save in codexlens-manager.js

Also includes targeted unit tests for the URL normalization logic.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 18:20:54 +08:00
catlog22
61cef8019a chore: bump version to 6.3.25
- Add review-code skill with multi-dimensional code review
- Externalized rules configuration (specs/rules/*.json)
- Centralized state management module

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 17:14:07 +08:00
catlog22
08308aa9ea feat: 增加对 HTML 标签的支持,扩展 BBCode 转换规则 2026-01-13 16:58:24 +08:00
catlog22
94ae9e264c Add output preview phase and callout types specifications
- Implemented Phase 4: Output & Preview for text formatter, including saving formatted content, generating statistics, and providing HTML preview.
- Created callout types documentation with detection patterns and conversion rules for BBCode and HTML.
- Added element mapping specifications detailing detection patterns and conversion matrices for various Markdown elements.
- Established format conversion rules for BBCode and Markdown, emphasizing pixel-based sizing and supported tags.
- Developed BBCode template with structured document and callout templates for consistent formatting.
2026-01-13 16:53:25 +08:00
catlog22
549e6e70e4 chore: bump version to 6.3.24
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 16:01:08 +08:00
catlog22
15514c8f91 Add multi-dimensional code review rules for architecture, correctness, performance, readability, security, and testing
- Introduced architecture rules to detect circular dependencies, god classes, layer violations, and mixed concerns.
- Added correctness rules focusing on null checks, empty catch blocks, unreachable code, and type coercion.
- Implemented performance rules addressing nested loops, synchronous I/O, memory leaks, and unnecessary re-renders in React.
- Created readability rules to improve function length, variable naming, deep nesting, magic numbers, and commented code.
- Established security rules to identify XSS risks, hardcoded secrets, SQL injection vulnerabilities, and insecure random generation.
- Developed testing rules to enhance test quality, coverage, and maintainability, including missing assertions and error path testing.
- Documented the structure and schema for rule files in the index.md for better understanding and usage.
2026-01-13 14:53:20 +08:00
catlog22
29c8bb7a66 feat: Add orchestrator and state management for code review process
- Implemented orchestrator logic to manage code review phases, including state reading, action selection, and execution loop.
- Defined state schema for review process, including metadata, context, findings, and execution tracking.
- Created action catalog detailing actions for context collection, quick scan, deep review, report generation, and completion.
- Established error recovery strategies and termination conditions for robust review handling.
- Developed issue classification and quality standards documentation to guide review severity and categorization.
- Introduced review dimensions with detailed checklists for correctness, security, performance, readability, testing, and architecture.
- Added templates for issue reporting and review reports to standardize output and improve clarity.
2026-01-13 14:39:16 +08:00
catlog22
76f5311e78 Refactor: Remove outdated security requirements and best practice templates
- Deleted security requirements specification file to streamline documentation.
- Removed best practice finding template to enhance clarity and focus on critical issues.
- Eliminated report template and security finding template to reduce redundancy and improve maintainability.
- Updated skill generator templates to enforce mandatory prerequisites for better compliance with design standards.
- Bumped package version from 6.3.18 to 6.3.23 for dependency updates.
2026-01-13 13:58:41 +08:00
catlog22
ca6677149a chore: bump version to 6.3.23
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 13:04:49 +08:00
catlog22
880376aefc feat: 优化 Solution ID 命名机制并添加 GitHub 链接显示
- Solution ID 改用 4 位随机 uid (如 SOL-GH-123-a7x9) 避免多次规划时覆盖
- issue 卡片添加 GitHub 链接图标,支持点击跳转到对应 issue

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 13:03:51 +08:00
catlog22
a20f81d44a fix: 兼容 discovery-state.json 新旧两种格式
- readDiscoveryProgress: 自动检测 perspectives 格式(对象数组/字符串数组)
- readDiscoveryIndex: 兼容从 perspectives 和 metadata.perspectives 提取视角
- 列表 API: 优先从 results 对象提取统计数据,回退到顶层字段
- 新增 3 个测试用例验证新格式兼容性
- bump version to 6.3.22

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 12:35:15 +08:00
catlog22
a8627e7f68 chore: bump version to 6.3.21
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 11:44:15 +08:00
catlog22
4caa622942 fix: 使用 csrfFetch 替换 fetch 以增强 API 请求的安全性 2026-01-13 11:42:28 +08:00
github-actions[bot]
6b8e73bd32 chore: update visual test baselines [skip ci] 2026-01-13 03:39:20 +00:00
catlog22
68c4c54b64 fix: 添加 workflow contents:write 权限以支持基准快照提交
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 11:38:07 +08:00
catlog22
1dca4b06a2 fix: 修复 CI 环境视觉测试跨平台兼容性问题
- 增加 visual-tester 支持尺寸不匹配时的区域提取比较
- CI 环境使用 5% 容差(本地保持 0.1%)
- 添加 workflow_dispatch 支持手动更新基准快照
- 更新后的基准快照会自动提交到仓库

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 11:33:11 +08:00
catlog22
a8ec42233f chore: bump version to 6.3.20
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-13 11:14:46 +08:00
catlog22
49a7c17ba8 docs: 添加提交语言规范,支持中文和英文提交信息选择 2026-01-13 11:12:59 +08:00
catlog22
8a15e08944 feat: 增强索引树构建逻辑,支持递归检查子目录中的可索引文件 2026-01-13 11:08:48 +08:00
catlog22
8c2d39d517 feat: 添加配置选项以调整重排序模型的权重和测试文件惩罚,增强语义搜索功能 2026-01-13 10:44:26 +08:00
catlog22
bf06f4ddcc feat: 添加GitHub回复任务,支持在问题存在github_url时自动评论 2026-01-13 09:58:55 +08:00
catlog22
28645aa4e4 fix: 更新API基础URL验证逻辑,允许HTTP协议并调整Anthropic API请求格式 2026-01-13 09:47:19 +08:00
catlog22
cdcb517bc2 fix: 移除未使用的类型导出,清理代码 2026-01-13 09:27:35 +08:00
catlog22
a63d547856 fix: remove duplicate RotationEndpointConfig export
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-12 23:56:04 +08:00
catlog22
d994274023 chore: bump version to 6.3.19
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-12 23:53:58 +08:00
catlog22
a98db07731 chore(release): v6.3.19 - Dense Reranker, CLI Tools & Issue Workflow
## Documentation Updates
- Update all version references to v6.3.19
- Add Dense + Reranker search documentation
- Add OpenCode AI CLI tool integration docs
- Add Issue workflow (plan → queue → execute) with Codex recommendation
- Update CHANGELOG with complete v6.3.19 release notes

## Features
- Cross-Encoder reranking for improved search relevance
- OpenCode CLI tool support
- Issue multi-queue parallel execution
- Service architecture improvements (cache-manager, preload-service)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-12 23:51:16 +08:00
catlog22
908a745f95 Refactor Codex Lens config handling and CLI tools status checks
- Updated Codex Lens config handler to extract embeddings data from the new response structure, including coverage percentage and total files with embeddings.
- Enhanced CLI tools status function to handle different tool types (builtin, cli-wrapper, api-endpoint) with improved logic for checking availability based on configuration.
- Removed obsolete test files and directories that are no longer needed.
2026-01-12 22:49:30 +08:00
catlog22
5259bf48b2 feat: 添加服务模块到加载顺序,优化工作区状态加载逻辑,支持预加载和直接获取 2026-01-12 22:31:32 +08:00
catlog22
ecaa011502 feat: 增强 CLI 状态管理,支持从缓存加载状态并优化预加载服务 2026-01-12 22:22:21 +08:00
catlog22
65cb5beec4 feat: 优化缓存管理,增加从缓存读取 CLI 状态和配置的功能 2026-01-12 21:57:21 +08:00
catlog22
fd9c55162d feat: 添加服务模块,包含缓存管理、事件管理和预加载服务 2026-01-12 21:47:11 +08:00
catlog22
ca77c114dd feat: 更新 CodexLens 项目状态获取逻辑,使用 'projects show' 命令并添加索引状态检查 2026-01-12 21:10:01 +08:00
catlog22
5282551277 feat: 更新 CodexLens 工作区状态 API,支持通过查询参数指定项目路径 2026-01-12 21:00:50 +08:00
catlog22
76e1f855f1 feat: 添加动态批处理大小设置及相关国际化支持,优化配置管理 2026-01-12 20:03:14 +08:00
catlog22
57173c9b02 feat: 优化动态批量大小计算,确保使用所有解析规则的最大字符限制,并调整利用率因子的安全范围 2026-01-12 17:47:19 +08:00
catlog22
90a1321aac feat: 添加动态批量大小计算,优化嵌入管理和配置系统 2026-01-12 17:34:37 +08:00
catlog22
b360e0edc7 feat: 委托 ensureLiteLLMEmbedderReady 以确保依赖一致性,优化 ccw-litellm 安装逻辑 2026-01-12 15:12:56 +08:00
catlog22
5ec9ad01a3 feat: 添加 ccw-litellm 安装和卸载后的缓存失效处理,确保数据更新 2026-01-12 14:39:37 +08:00
catlog22
96f0d2a8f1 feat: 更新 ccw-litellm 安装逻辑,仅检查 CodexLens 虚拟环境,移除系统 pip 回退 2026-01-12 14:18:45 +08:00
catlog22
cba4d76b75 feat: 优化 ccw-litellm 安装和卸载流程,优先使用 CodexLens 虚拟环境 2026-01-12 13:00:48 +08:00
catlog22
09beb84586 feat: 添加 UV 管理器支持以优化 SPLADE 安装流程 2026-01-12 12:54:22 +08:00
catlog22
7803dad430 Add integration and unit tests for CodexLens UV installation and UV manager
- Implemented integration tests for CodexLens UV installation functionality, covering package installations, Python import verification, and dependency conflict resolution.
- Created unit tests for the uv-manager utility module, including UV binary detection, installation, and virtual environment management.
- Added cleanup procedures for temporary directories used in tests.
- Verified the functionality of the UvManager class, including virtual environment creation, package installation, and error handling for invalid environments.
2026-01-12 12:42:38 +08:00
catlog22
52c510501d feat: 添加工具类型和用法说明,支持自定义 API 头部设置 2026-01-12 11:41:04 +08:00
catlog22
bdd545727b feat: 更新 LiteLLM 客户端和 CLI 设置管理,支持自定义 API 路由和 CLI 工具集成 2026-01-12 10:28:42 +08:00
catlog22
1044886e7d feat(cli-manager): add CLI wrapper endpoints management and UI integration
- Introduced functions to load and toggle CLI wrapper endpoints from the API.
- Updated the CLI manager UI to display and manage CLI wrapper endpoints.
- Removed CodexLens and Semantic Search from the tools section, now managed in their dedicated pages.

feat(codexlens-manager): move File Watcher card to the CodexLens Manager page

- Relocated the File Watcher card from the right column to the main content area of the CodexLens Manager page.

refactor(claude-cli-tools): enhance CLI tools configuration and migration

- Added support for new tool types: 'cli-wrapper' and 'api-endpoint'.
- Updated migration logic to handle new tool types and preserve endpoint IDs.
- Deprecated previous custom endpoint handling in favor of the new structure.

feat(cli-executor-core): integrate CLI settings for custom endpoint execution

- Implemented execution logic for custom CLI封装 endpoints using settings files.
- Enhanced error handling and output logging for CLI executions.
- Updated tool identification logic to support both built-in tools and custom endpoints.
2026-01-12 09:35:05 +08:00
catlog22
cefb934a2c feat: 为 skill-generator 添加脚本执行能力
- 默认创建 scripts/ 目录用于存放确定性脚本
- 新增 specs/scripting-integration.md 脚本集成规范
- 新增 templates/script-python.md 和 script-bash.md 脚本模板
- 模板中添加 ## Scripts 声明和 ExecuteScript 调用示例
- 支持命名即ID、扩展名即运行时的约定
- 参数自动转换: snake_case → kebab-case
- Bash 模板使用 jq 构建 JSON 输出

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-11 23:14:00 +08:00
catlog22
37614a3362 feat: 更新 SmartContentFormatter,确保格式化内容始终返回可显示的字符串 2026-01-11 22:37:44 +08:00
catlog22
7f3033b1c1 feat: 使用智能内容格式化器优化 CLI 输出内容格式 2026-01-11 21:17:20 +08:00
catlog22
7387a25d65 feat: 引入智能内容格式化器以优化 CLI 输出的格式化处理 2026-01-11 20:57:32 +08:00
catlog22
e1eafede65 feat: 优化 CLI 工具配置管理,动态加载工具并简化配置路径 2026-01-11 20:40:51 +08:00
catlog22
9d7b77059f feat: 删除 CLI 工具配置文件,简化项目结构 2026-01-11 19:59:16 +08:00
catlog22
7519603fbd feat: 更新 CLI 工具配置管理,优化配置读取和保存策略 2026-01-11 19:58:48 +08:00
catlog22
bafc3225d2 feat: 更新 CLI 工具执行规范,重构配置和选择流程 2026-01-11 19:53:56 +08:00
catlog22
174393b5cb feat: 添加预加载功能以优化 CodexLens 数据获取和缓存管理 2026-01-11 19:41:13 +08:00
catlog22
b77672dda4 feat: 增强模型下载功能,支持 HuggingFace Hub 直接下载 ONNX 格式模型 2026-01-11 18:22:36 +08:00
catlog22
1e91fa9f9e feat: Add custom model download functionality and enhance model management
- Implemented `model-download-custom` command to download HuggingFace models.
- Added support for discovering manually placed models in the cache.
- Enhanced the model list view to display recommended and discovered models separately.
- Introduced JSON editor for direct configuration mode in API settings.
- Added validation and formatting features for JSON input.
- Updated translations for new API settings and common actions.
- Improved user interface for model management, including action buttons and tooltips.
2026-01-11 15:13:11 +08:00
catlog22
16083130f8 feat: Refactor CLI tool configuration management and introduce skill context loader
- Updated `claude-cli-tools.ts` to support new model configurations and migration from older versions.
- Added `getPredefinedModels` and `getAllPredefinedModels` functions for better model management.
- Deprecated `cli-config-manager.ts` in favor of `claude-cli-tools.ts`, maintaining backward compatibility.
- Introduced `skill-context-loader.ts` to handle skill context loading based on user prompts and keywords.
- Enhanced tool configuration functions to include secondary models and improved migration logic.
- Updated index file to register the new skill context loader tool.
2026-01-11 13:56:20 +08:00
catlog22
2c11392848 feat: auto-update developmentIndex on session archive (closes #58)
- Add updateDevelopmentIndex() function to session-manager.ts
- Auto-append entry to developmentIndex when archiving sessions
- Add timeline view toggle for Development History section
- Support both 'archivedAt' and 'date' field names for compatibility
- Add dynamic calculation for statistics (Total Features, Last Updated)
- Add CSS styles for timeline view
2026-01-11 11:05:41 +08:00
catlog22
30ff742310 feat: 添加高可用性模型池支持,优化路径解析功能 2026-01-08 23:54:32 +08:00
catlog22
84168825d6 feat: 添加工具调用支持,增强 CLI 工具和 MCP 管理功能 2026-01-08 23:32:27 +08:00
catlog22
311ce2e4bc feat: 添加推荐 MCP 服务器功能和安装向导 2026-01-08 22:37:50 +08:00
catlog22
ea5c0bc9a4 feat: Enhance CLI tools and settings management
- Added auto-initialization of CSRF token for state-changing requests in cli-manager.js.
- Refactored Claude CLI Tools configuration to separate tools and settings into cli-tools.json and cli-settings.json respectively.
- Introduced new interfaces for Claude CLI Tools and Settings, including support for tags and primary models.
- Implemented loading and saving functions for CLI settings, ensuring backward compatibility with legacy combined config.
- Updated functions to synchronize tags between CLI tools and configuration manager.
- Added error handling and logging for loading and saving configurations.
- Created initial cli-settings.json with default settings.
2026-01-08 22:00:07 +08:00
catlog22
0bd2cff5b7 feat: 添加 OpenCode AI 助手支持,增强 CLI 工具功能 2026-01-08 20:39:41 +08:00
catlog22
faf32b5086 fix: 改为在文件末尾添加独立章节
- 启用时添加 "## 中文回复" 章节到文件末尾
- 禁用时移除整个章节
- 不再依赖标题匹配
2026-01-08 20:27:09 +08:00
catlog22
8f7ab3e268 fix: 修复 Codex AGENTS.md 标题匹配模式
- 支持 "Codex Code Guidelines" 和 "Codex Instructions" 两种标题
- 使用不区分大小写的正则匹配
2026-01-08 20:25:04 +08:00
catlog22
a433861f77 feat: 中文回复设置支持 Claude 和 Codex 双 CLI
- 后端 API 支持 target 参数区分 claude/codex
- 前端界面分别显示 CLAUDE.md 和 AGENTS.md 状态
- 添加中英文翻译支持
2026-01-08 20:16:22 +08:00
catlog22
886a8ef8b0 refactor: 精简中文回复准则,支持中文 commit
- 移除冗余格式说明,保留核心规则
- Git commit 规则改为使用中文提交信息
- 文件从 39 行精简至 25 行
2026-01-08 20:06:54 +08:00
catlog22
3124125b4c feat: 添加标签颜色变体和验证功能,增强工具配置管理 2026-01-08 19:11:27 +08:00
catlog22
d0523684e5 feat: Enhance CLI output handling with structured Intermediate Representation (IR)
- Introduced `CliOutputUnit` and `IOutputParser` interfaces for unified output processing.
- Implemented `PlainTextParser` and `JsonLinesParser` for parsing raw CLI output into structured units.
- Updated `executeCliTool` to utilize output parsers and handle structured output.
- Added `flattenOutputUnits` utility for extracting clean output from structured data.
- Enhanced `ConversationTurn` and `ExecutionRecord` interfaces to include structured output.
- Created comprehensive documentation for CLI Output Converter usage and integration.
- Improved error handling and type mapping for various output formats.
2026-01-08 17:26:40 +08:00
catlog22
b86cdd6644 feat(cli-settings): Implement CLI settings management and routes
- Added CLI settings file manager to handle endpoint configurations.
- Introduced API routes for creating, updating, deleting, and listing CLI settings.
- Enhanced session discovery for OpenCode with improved storage structure.
- Updated command building logic for OpenCode and Claude to support new settings.
- Added validation and sanitization for endpoint IDs and settings.
- Implemented functionality to toggle endpoint enabled status and retrieve executable settings paths.
2026-01-08 14:15:32 +08:00
catlog22
55fa170b4e feat: 添加对 OpenCode 的支持,更新 CLI 工具配置和会话发现逻辑 2026-01-08 10:47:07 +08:00
catlog22
d2d6cce5f4 feat: 添加忽略模式配置接口和前端支持,允许用户自定义索引排除项 2026-01-07 23:33:40 +08:00
catlog22
178d45e232 Merge branch 'main' of https://github.com/catlog22/Claude-Code-Workflow 2026-01-07 22:36:49 +08:00
catlog22
09d99abee6 Issue Queue: issue-exec-20260106-160325 (#52)
* feat(security): Secure dashboard server by default

## Solution Summary
- Solution-ID: SOL-DSC-002-1
- Issue-ID: DSC-002

## Tasks Completed
- [T1] JWT token manager (24h expiry, persisted secret/token)
- [T2] API auth middleware + localhost token endpoint
- [T3] Default bind 127.0.0.1, add --host with warning
- [T4] Localhost-only CORS with credentials + Vary
- [T5] SECURITY.md documentation + README link

## Verification
- npm run build
- npm test -- ccw/tests/token-manager.test.ts ccw/tests/middleware.test.ts ccw/tests/server-auth.integration.test.ts ccw/tests/server.test.ts ccw/tests/cors.test.ts

* fix(security): Prevent command injection in Windows spawn()

## Solution Summary
- **Solution-ID**: SOL-DSC-001-1
- **Issue-ID**: DSC-001
- **Risk/Impact/Complexity**: high/high/medium

## Tasks Completed
- [T1] Create Windows shell escape utility
- [T2] Escape cli-executor spawn() args on Windows
- [T3] Add command injection regression tests

## Files Modified
- ccw/src/utils/shell-escape.ts
- ccw/src/tools/cli-executor.ts
- ccw/tests/shell-escape.test.ts
- ccw/tests/security/command-injection.test.ts

## Verification
- npm run build
- npm test -- ccw/tests/shell-escape.test.ts ccw/tests/security/command-injection.test.ts

* fix(security): Harden path validation (DSC-005)

## Solution Summary
- Solution-ID: SOL-DSC-005-1
- Issue-ID: DSC-005

## Tasks Completed
- T1: Refactor path validation to pre-resolution checking
- T2: Implement allowlist-based path validation
- T3: Add path validation to API routes
- T4: Add path security regression tests

## Files Modified
- ccw/src/utils/path-resolver.ts
- ccw/src/utils/path-validator.ts
- ccw/src/core/routes/graph-routes.ts
- ccw/src/core/routes/files-routes.ts
- ccw/src/core/routes/skills-routes.ts
- ccw/tests/path-resolver.test.ts
- ccw/tests/graph-routes.test.ts
- ccw/tests/files-routes.test.ts
- ccw/tests/skills-routes.test.ts
- ccw/tests/security/path-traversal.test.ts

## Verification
- npm run build
- npm test -- path-resolver.test.ts
- npm test -- path-validator.test.ts
- npm test -- graph-routes.test.ts
- npm test -- files-routes.test.ts
- npm test -- skills-routes.test.ts
- npm test -- ccw/tests/security/path-traversal.test.ts

* fix(security): Prevent credential leakage (DSC-004)

## Solution Summary
- Solution-ID: SOL-DSC-004-1
- Issue-ID: DSC-004

## Tasks Completed
- T1: Create credential handling security tests
- T2: Add log sanitization tests
- T3: Add env var leakage prevention tests
- T4: Add secure storage tests

## Files Modified
- ccw/src/config/litellm-api-config-manager.ts
- ccw/src/core/routes/litellm-api-routes.ts
- ccw/tests/security/credential-handling.test.ts

## Verification
- npm run build
- node --experimental-strip-types --test ccw/tests/security/credential-handling.test.ts

* test(ranking): expand normalize_weights edge case coverage (ISS-1766920108814-0)

## Solution Summary
- Solution-ID: SOL-20251228113607
- Issue-ID: ISS-1766920108814-0

## Tasks Completed
- T1: Fix NaN and invalid total handling in normalize_weights
- T2: Add unit tests for NaN edge cases in normalize_weights

## Files Modified
- codex-lens/tests/test_rrf_fusion.py

## Verification
- python -m pytest codex-lens/tests/test_rrf_fusion.py::TestNormalizeBM25Score -v
- python -m pytest codex-lens/tests/test_rrf_fusion.py -v -k normalize
- python -m pytest codex-lens/tests/test_rrf_fusion.py::TestReciprocalRankFusion::test_weight_normalization codex-lens/tests/test_cli_hybrid_search.py::TestCLIHybridSearch::test_weights_normalization -v

* feat(security): Add CSRF protection and tighten CORS (DSC-006)

## Solution Summary
- Solution-ID: SOL-DSC-006-1
- Issue-ID: DSC-006
- Risk/Impact/Complexity: high/high/medium

## Tasks Completed
- T1: Create CSRF token generation system
- T2: Add CSRF token endpoints
- T3: Implement CSRF validation middleware
- T4: Restrict CORS to trusted origins
- T5: Add CSRF security tests

## Files Modified
- ccw/src/core/auth/csrf-manager.ts
- ccw/src/core/auth/csrf-middleware.ts
- ccw/src/core/routes/auth-routes.ts
- ccw/src/core/server.ts
- ccw/tests/csrf-manager.test.ts
- ccw/tests/auth-routes.test.ts
- ccw/tests/csrf-middleware.test.ts
- ccw/tests/security/csrf.test.ts

## Verification
- npm run build
- node --experimental-strip-types --test ccw/tests/csrf-manager.test.ts
- node --experimental-strip-types --test ccw/tests/auth-routes.test.ts
- node --experimental-strip-types --test ccw/tests/csrf-middleware.test.ts
- node --experimental-strip-types --test ccw/tests/cors.test.ts
- node --experimental-strip-types --test ccw/tests/security/csrf.test.ts

* fix(cli-executor): prevent stale SIGKILL timeouts

## Solution Summary

- Solution-ID: SOL-DSC-007-1

- Issue-ID: DSC-007

- Risk/Impact/Complexity: low/low/low

## Tasks Completed

- [T1] Store timeout handle in killCurrentCliProcess

## Files Modified

- ccw/src/tools/cli-executor.ts

- ccw/tests/cli-executor-kill.test.ts

## Verification

- node --experimental-strip-types --test ccw/tests/cli-executor-kill.test.ts

* fix(cli-executor): enhance merge validation guards

## Solution Summary

- Solution-ID: SOL-DSC-008-1

- Issue-ID: DSC-008

- Risk/Impact/Complexity: low/low/low

## Tasks Completed

- [T1] Enhance sourceConversations array validation

## Files Modified

- ccw/src/tools/cli-executor.ts

- ccw/tests/cli-executor-merge-validation.test.ts

## Verification

- node --experimental-strip-types --test ccw/tests/cli-executor-merge-validation.test.ts

* refactor(core): remove @ts-nocheck from core routes

## Solution Summary
- Solution-ID: SOL-DSC-003-1
- Issue-ID: DSC-003
- Queue-ID: QUE-20260106-164500
- Item-ID: S-9

## Tasks Completed
- T1: Create shared RouteContext type definition
- T2: Remove @ts-nocheck from small route files
- T3: Remove @ts-nocheck from medium route files
- T4: Remove @ts-nocheck from large route files
- T5: Remove @ts-nocheck from remaining core files

## Files Modified
- ccw/src/core/dashboard-generator-patch.ts
- ccw/src/core/dashboard-generator.ts
- ccw/src/core/routes/ccw-routes.ts
- ccw/src/core/routes/claude-routes.ts
- ccw/src/core/routes/cli-routes.ts
- ccw/src/core/routes/codexlens-routes.ts
- ccw/src/core/routes/discovery-routes.ts
- ccw/src/core/routes/files-routes.ts
- ccw/src/core/routes/graph-routes.ts
- ccw/src/core/routes/help-routes.ts
- ccw/src/core/routes/hooks-routes.ts
- ccw/src/core/routes/issue-routes.ts
- ccw/src/core/routes/litellm-api-routes.ts
- ccw/src/core/routes/litellm-routes.ts
- ccw/src/core/routes/mcp-routes.ts
- ccw/src/core/routes/mcp-routes.ts.backup
- ccw/src/core/routes/mcp-templates-db.ts
- ccw/src/core/routes/nav-status-routes.ts
- ccw/src/core/routes/rules-routes.ts
- ccw/src/core/routes/session-routes.ts
- ccw/src/core/routes/skills-routes.ts
- ccw/src/core/routes/status-routes.ts
- ccw/src/core/routes/system-routes.ts
- ccw/src/core/routes/types.ts
- ccw/src/core/server.ts
- ccw/src/core/websocket.ts

## Verification
- npm run build
- npm test

* refactor: split cli-executor and codexlens routes into modules

## Solution Summary
- Solution-ID: SOL-DSC-012-1
- Issue-ID: DSC-012
- Risk/Impact/Complexity: medium/medium/high

## Tasks Completed
- [T1] Extract execution orchestration from cli-executor.ts (Refactor ccw/src/tools)
- [T2] Extract route handlers from codexlens-routes.ts (Refactor ccw/src/core/routes)
- [T3] Extract prompt concatenation logic from cli-executor (Refactor ccw/src/tools)
- [T4] Document refactored module architecture (Docs)

## Files Modified
- ccw/src/tools/cli-executor.ts
- ccw/src/tools/cli-executor-core.ts
- ccw/src/tools/cli-executor-utils.ts
- ccw/src/tools/cli-executor-state.ts
- ccw/src/tools/cli-prompt-builder.ts
- ccw/src/tools/README.md
- ccw/src/core/routes/codexlens-routes.ts
- ccw/src/core/routes/codexlens/config-handlers.ts
- ccw/src/core/routes/codexlens/index-handlers.ts
- ccw/src/core/routes/codexlens/semantic-handlers.ts
- ccw/src/core/routes/codexlens/watcher-handlers.ts
- ccw/src/core/routes/codexlens/utils.ts
- ccw/src/core/routes/codexlens/README.md

## Verification
- npm run build
- npm test

* test(issue): Add comprehensive issue command tests

## Solution Summary
- **Solution-ID**: SOL-DSC-009-1
- **Issue-ID**: DSC-009
- **Risk/Impact/Complexity**: low/high/medium

## Tasks Completed
- [T1] Create issue command test file structure: Create isolated test harness
- [T2] Add JSONL read/write operation tests: Verify JSONL correctness and errors
- [T3] Add issue lifecycle tests: Verify status transitions and timestamps
- [T4] Add solution binding tests: Verify binding flows and error cases
- [T5] Add queue formation tests: Verify queue creation, IDs, and DAG behavior
- [T6] Add queue execution tests: Verify next/done/retry and status sync

## Files Modified
- ccw/src/commands/issue.ts
- ccw/tests/issue-command.test.ts

## Verification
- node --experimental-strip-types --test ccw/tests/issue-command.test.ts

* test(routes): Add integration tests for route modules

## Solution Summary
- Solution-ID: SOL-DSC-010-1
- Issue-ID: DSC-010
- Queue-ID: QUE-20260106-164500

## Tasks Completed
- [T1] Add tests for ccw-routes.ts
- [T2] Add tests for files-routes.ts
- [T3] Add tests for claude-routes.ts (includes Windows path fix for create)
- [T4] Add tests for issue-routes.ts
- [T5] Add tests for help-routes.ts (avoid hanging watchers)
- [T6] Add tests for nav-status-routes.ts
- [T7] Add tests for hooks/graph/rules/skills/litellm-api routes

## Files Modified
- ccw/src/core/routes/claude-routes.ts
- ccw/src/core/routes/help-routes.ts
- ccw/tests/integration/ccw-routes.test.ts
- ccw/tests/integration/claude-routes.test.ts
- ccw/tests/integration/files-routes.test.ts
- ccw/tests/integration/issue-routes.test.ts
- ccw/tests/integration/help-routes.test.ts
- ccw/tests/integration/nav-status-routes.test.ts
- ccw/tests/integration/hooks-routes.test.ts
- ccw/tests/integration/graph-routes.test.ts
- ccw/tests/integration/rules-routes.test.ts
- ccw/tests/integration/skills-routes.test.ts
- ccw/tests/integration/litellm-api-routes.test.ts

## Verification
- node --experimental-strip-types --test ccw/tests/integration/ccw-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/files-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/claude-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/issue-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/help-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/nav-status-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/hooks-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/graph-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/rules-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/skills-routes.test.ts
- node --experimental-strip-types --test ccw/tests/integration/litellm-api-routes.test.ts

* refactor(core): Switch cache and lite scanning to async fs

## Solution Summary
- Solution-ID: SOL-DSC-013-1
- Issue-ID: DSC-013
- Queue-ID: QUE-20260106-164500

## Tasks Completed
- [T1] Convert cache-manager.ts to async file operations
- [T2] Convert lite-scanner.ts to async file operations
- [T3] Update cache-manager call sites to await async API
- [T4] Update lite-scanner call sites to await async API

## Files Modified
- ccw/src/core/cache-manager.ts
- ccw/src/core/lite-scanner.ts
- ccw/src/core/data-aggregator.ts

## Verification
- npm run build
- npm test

* fix(exec): Add timeout protection for execSync

## Solution Summary
- Solution-ID: SOL-DSC-014-1
- Issue-ID: DSC-014
- Queue-ID: QUE-20260106-164500

## Tasks Completed
- [T1] Add timeout to execSync calls in python-utils.ts
- [T2] Add timeout to execSync calls in detect-changed-modules.ts
- [T3] Add timeout to execSync calls in claude-freshness.ts
- [T4] Add timeout to execSync calls in issue.ts
- [T5] Consolidate execSync timeout constants and audit coverage

## Files Modified
- ccw/src/utils/exec-constants.ts
- ccw/src/utils/python-utils.ts
- ccw/src/tools/detect-changed-modules.ts
- ccw/src/core/claude-freshness.ts
- ccw/src/commands/issue.ts
- ccw/src/tools/smart-search.ts
- ccw/src/tools/codex-lens.ts
- ccw/src/core/routes/codexlens/config-handlers.ts

## Verification
- npm run build
- npm test
- node --experimental-strip-types --test ccw/tests/issue-command.test.ts

* feat(cli): Add progress spinner with elapsed time for long-running operations

## Solution Summary
- Solution-ID: SOL-DSC-015-1
- Issue-ID: DSC-015
- Queue-Item: S-15
- Risk/Impact/Complexity: low/medium/low

## Tasks Completed
- [T1] Add progress spinner to CLI execution: Update ccw/src/commands/cli.ts

## Files Modified
- ccw/src/commands/cli.ts
- ccw/tests/cli-command.test.ts

## Verification
- node --experimental-strip-types --test ccw/tests/cli-command.test.ts
- node --experimental-strip-types --test ccw/tests/cli-executor-kill.test.ts
- node --experimental-strip-types --test ccw/tests/cli-executor-merge-validation.test.ts

* fix(cli): Move full output hint immediately after truncation notice

## Solution Summary
- Solution-ID: SOL-DSC-016-1
- Issue-ID: DSC-016
- Queue-Item: S-16
- Risk/Impact/Complexity: low/high/low

## Tasks Completed
- [T1] Relocate output hint after truncation: Update ccw/src/commands/cli.ts

## Files Modified
- ccw/src/commands/cli.ts
- ccw/tests/cli-command.test.ts

## Verification
- npm run build
- node --experimental-strip-types --test ccw/tests/cli-command.test.ts

* feat(cli): Add confirmation prompts for destructive operations

## Solution Summary
- Solution-ID: SOL-DSC-017-1
- Issue-ID: DSC-017
- Queue-Item: S-17
- Risk/Impact/Complexity: low/high/low

## Tasks Completed
- [T1] Add confirmation to storage clean operations: Update ccw/src/commands/cli.ts
- [T2] Add confirmation to issue queue delete: Update ccw/src/commands/issue.ts

## Files Modified
- ccw/src/commands/cli.ts
- ccw/src/commands/issue.ts
- ccw/tests/cli-command.test.ts
- ccw/tests/issue-command.test.ts

## Verification
- npm run build
- node --experimental-strip-types --test ccw/tests/cli-command.test.ts
- node --experimental-strip-types --test ccw/tests/issue-command.test.ts

* feat(cli): Improve multi-line prompt guidance

## Solution Summary
- Solution-ID: SOL-DSC-018-1
- Issue-ID: DSC-018
- Queue-Item: S-18
- Risk/Impact/Complexity: low/medium/low

## Tasks Completed
- [T1] Update CLI help to emphasize --file option: Update ccw/src/commands/cli.ts
- [T2] Add inline hint for multi-line detection: Update ccw/src/commands/cli.ts

## Files Modified
- ccw/src/commands/cli.ts
- ccw/tests/cli-command.test.ts

## Verification
- npm run build
- node --experimental-strip-types --test ccw/tests/cli-command.test.ts

---------

Co-authored-by: catlog22 <catlog22@github.com>
2026-01-07 22:35:46 +08:00
catlog22
6e93c36b89 feat: 优化工作区索引状态刷新,增强头部徽章更新逻辑 2026-01-07 22:28:36 +08:00
catlog22
fae2f7e279 feat: 始终注册队列变更回调以支持标准输出(TypeScript 后端) 2026-01-07 22:21:11 +08:00
catlog22
2e68a18afd fix: 修复 stopWatcherProcess 函数的错误处理,确保返回值一致性 2026-01-07 22:10:20 +08:00
catlog22
05514631f2 feat: Enhance JSON streaming parsing and UI updates
- Added a function to parse JSON streaming content in core-memory.js, extracting readable text from messages.
- Updated memory detail view to utilize the new parsing function for content and summary.
- Introduced an enableReview option in rules-manager.js, allowing users to toggle review functionality in rule creation.
- Simplified skill creation modal in skills-manager.js by removing generation type selection UI.
- Improved CLI executor to handle tool calls for file writing, ensuring proper output parsing.
- Adjusted CLI command tests to set timeout to 0 for immediate execution.
- Updated file watcher to implement a true debounce mechanism and added a pending queue status for UI updates.
- Enhanced watcher manager to handle queue changes and provide JSON output for better integration with TypeScript backend.
- Established TypeScript naming conventions documentation to standardize code style across the project.
2026-01-07 21:51:26 +08:00
catlog22
e9fb7be85f feat: 增强工作树管理功能,支持恢复现有工作树并优化执行命令的参数提示 2026-01-07 16:58:30 +08:00
catlog22
42fbc1936d feat: 更新执行命令的参数提示,支持指定现有工作树路径,增强工作树管理功能 2026-01-07 16:54:23 +08:00
catlog22
87d38a3374 feat: 添加重排序模型配置,支持最大输入令牌数,优化 API 批处理能力 2026-01-07 15:50:22 +08:00
catlog22
6aa79c6dc9 feat: 添加工作空间索引状态接口,增强 CodexLens 状态检查功能,支持前端显示索引信息 2026-01-07 11:36:06 +08:00
catlog22
1bd3d9c9bf feat: 移除文档语言配置,优化代码语言分类 2026-01-07 10:10:25 +08:00
catlog22
86d3e36722 feat: 增强解决方案管理功能,支持按解决方案 ID 过滤和简要输出,优化嵌入模型配置读取 2026-01-07 09:31:52 +08:00
catlog22
05f762117a feat: 添加 CodexLens 配置接口,增强索引状态检查功能,支持并行获取状态和配置 2026-01-06 23:34:10 +08:00
catlog22
1298fdd20f feat: 增加搜索功能的代码过滤选项,支持排除特定文件扩展名和仅返回代码文件 2026-01-06 23:19:47 +08:00
catlog22
ef770ff29b Add comprehensive code review specifications and templates
- Introduced best practices requirements specification covering code quality, performance, maintainability, error handling, and documentation standards.
- Established quality standards with overall quality metrics and mandatory checks for security, code quality, performance, and maintainability.
- Created security requirements specification aligned with OWASP Top 10 and CWE Top 25, detailing checks and patterns for common vulnerabilities.
- Developed templates for documenting best practice findings, security findings, and generating reports, including structured markdown and JSON formats.
- Updated dependencies in the project, ensuring compatibility and stability.
- Added test files and README documentation for vector indexing tests.
2026-01-06 23:11:15 +08:00
catlog22
02d66325a0 feat: 添加调试探索代理文档,包含五阶段调试工作流程和NDJSON日志格式 2026-01-06 17:02:40 +08:00
catlog22
a5024bdcbb feat: 更新命令文档,增强 Bash 兼容性并添加动态模型选项更新功能 2026-01-06 15:39:22 +08:00
catlog22
6cb819cb3a Enhance FastEmbed Integration and GPU Management
- Updated Windows platform guidelines for path formats and Bash rules.
- Refactored CodexLens routes to improve GPU detection and indexing cancellation logic.
- Added FastEmbed installation status handling in the dashboard, including UI updates for installation and reinstallation options.
- Implemented local model management with improved API responses for downloaded models.
- Enhanced GPU selection logic in the model mode configuration.
- Improved error handling and user feedback for FastEmbed installation processes.
- Adjusted Python environment checks to avoid shell escaping issues on Windows.
2026-01-06 14:42:00 +08:00
catlog22
08099cdcb9 feat: 增加 Python 冷启动超时至 15 秒,并优化获取状态和配置的命令 2026-01-06 08:56:55 +08:00
catlog22
1451594ae6 feat: Add user action prompt after issue discovery and enhance environment variable support for embedding and reranker configurations 2026-01-05 23:58:23 +08:00
catlog22
2e90230097 feat: Update import path for TextCrossEncoder to support fastembed versioning and add fallback for older versions 2026-01-05 23:13:52 +08:00
catlog22
f90c6b9fab feat: Enhance CodexLens uninstallation process with improved error handling and process termination for locked files 2026-01-05 22:40:26 +08:00
catlog22
853977c676 feat: Add reranker model management commands and UI integration
- Implemented CLI commands for listing, downloading, deleting, and retrieving information about reranker models.
- Enhanced the dashboard UI to support embedding and reranker configurations with internationalization.
- Updated environment variable management for embedding and reranker settings.
- Added functionality to dynamically update model options based on selected backend.
- Improved user experience with status indicators and action buttons for model management.
- Integrated new reranker models with detailed metadata and recommendations.
2026-01-05 21:23:09 +08:00
catlog22
2087f2d350 feat: add new translations for index management, incremental update, and environment variables in i18n module; enhance UI for API model info display and streamline index management section 2026-01-05 20:19:19 +08:00
catlog22
f4585c8dea feat: enhance reranker and embedding configuration management with settings.json support 2026-01-05 17:21:34 +08:00
catlog22
a2c599d6fa Refactor workflow commands to use "execute" terminology instead of "dispatch" for clarity and consistency across TDD, test generation, and UI design processes. Update task attachment model descriptions and ensure all phases reflect the new execution model. Additionally, hide certain UI elements in the dashboard template to disable unused features. 2026-01-05 11:40:53 +08:00
catlog22
256a07e584 feat: update server port handling and improve session lifecycle test assertions 2026-01-05 10:48:08 +08:00
catlog22
b361f42c1c Add E2E tests for MCP Tool Execution and Session Lifecycle
- Implement comprehensive end-to-end tests for MCP Tool Execution, covering tool discovery, execution, parameter validation, error handling, and timeout scenarios.
- Introduce tests for the complete lifecycle of a workflow session, including initialization, task management, status updates, and archiving.
- Validate dual parameter format support and handle boundary conditions such as invalid JSON, non-existent sessions, and path traversal attempts.
- Ensure concurrent task updates are handled without data loss and that task data is preserved when archiving sessions.
- List sessions across all locations and verify metadata inclusion in the results.
2026-01-05 09:44:08 +08:00
catlog22
33f2aef4e6 feat: enhance CLI stream viewer with active execution synchronization and improved tab UI 2026-01-04 23:17:58 +08:00
catlog22
4fb6b2d1de feat: add danger protection hooks and internationalization support for confirmation dialogs 2026-01-04 22:43:15 +08:00
catlog22
373f1d57c1 feat: update CLI timeout handling and add active execution state management 2026-01-04 22:14:43 +08:00
catlog22
81f4d084b0 feat: add navigation status routes and update badge aggregation logic 2026-01-04 21:04:28 +08:00
catlog22
2a13d8b17f feat: update CLI commands to new structure and enhance settings handling 2026-01-04 19:56:40 +08:00
catlog22
27a0129f72 feat: update execution commands to commit once per solution and enhance reranker model handling 2026-01-04 15:09:47 +08:00
catlog22
7e3d9007cd Remove remote installation script (install-remote.sh) due to deprecation and transition to new installation methods. 2026-01-04 12:04:13 +08:00
catlog22
df4d6fdc45 feat: enhance watcher control modal to fetch indexed projects and set default path 2026-01-04 11:20:49 +08:00
catlog22
f28b6c6197 feat: implement CodexLens watcher status handling and UI updates 2026-01-03 23:47:02 +08:00
catlog22
1825ed3bcf feat: update CodexLens route to spawn watcher using Python and add getVenvPythonPath export 2026-01-03 22:41:34 +08:00
catlog22
504ccfebbc feat: add reranker models to ProviderCredential and improve FastEmbedReranker scoring
- Added `rerankerModels` property to the `ProviderCredential` interface in `litellm-api-config.ts` to support additional reranker configurations.
- Introduced a numerically stable sigmoid function in `FastEmbedReranker` for score normalization.
- Updated the scoring logic in `FastEmbedReranker` to use raw float scores from the encoder and normalize them using the new sigmoid function.
- Adjusted the result mapping to maintain original document order while applying normalization.
2026-01-03 22:20:06 +08:00
catlog22
74ad2d0463 feat(issue-queue): add multi-queue parallel execution support
Add --queues parameter to enable parallel queue formation with multiple
issue-queue-agents. Solutions are partitioned by file overlap to minimize
cross-queue conflicts. Queue groups are linked via queue_group field.
2026-01-03 20:55:48 +08:00
catlog22
0af84be775 feat(model-lock): implement model lock management with localStorage support 2026-01-03 19:48:07 +08:00
catlog22
6043e6aa3b docs: improve task division strategy and add post-review prompt
- Add task division strategy to action-planning-agent: minimize count,
  share context, avoid overload
- Add post-review action to workflow review: prompt user to complete session
2026-01-03 19:42:40 +08:00
catlog22
e3dba87e08 feat(skills): add CCW orchestrator and refactor command-guide to ccw-help
CCW Skill (new):
- Stateless workflow orchestrator with intent classification
- 6 workflow combinations: rapid, full, coupled, bugfix, issue, ui
- External configuration: intent-rules.json, workflow-chains.json
- Implicit CLI tool injection (Gemini/Qwen/Codex)
- TODO tracking integration for workflow progress

CCW-Help Skill (refactored from command-guide):
- Renamed command-guide → ccw-help
- Removed reference folder duplication
- Source paths now relative from index/ (../../../commands/...)
- Added all-agents.json index
- Simplified SKILL.md following CCW pattern
2026-01-03 18:46:59 +08:00
catlog22
ad6c18f615 fix(security): prevent command injection and strengthen input validation
BREAKING: executeCodexLens now uses shell:false to prevent RCE

Security fixes:
- Remove shell:true from spawn() to prevent command injection (CRITICAL)
- Add .env value escaping to prevent injection when file is sourced
- Strengthen path validation with startsWith to block subdirectories
- Add path traversal detection (../)
- Improve JSON extraction to handle trailing CLI output

Features:
- Refactor CodexLens panel to tabbed layout (Overview/Settings/Search/Advanced)
- Add environment variables editor for ~/.codexlens/.env
- Add API concurrency settings (max_workers, batch_size)
- Add escapeHtml() helper to prevent XSS
- Implement merge mode for env saving to preserve custom variables
2026-01-03 18:33:47 +08:00
catlog22
be498acf59 feat: Add code analysis and LLM action templates with detailed configurations and examples
- Introduced a comprehensive code analysis action template for integrating code exploration and analysis capabilities.
- Added LLM action template for seamless integration of LLM calls with customizable prompts and tools.
- Implemented a benchmark search script to compare multiple search methods across various dimensions including speed, result quality, ranking stability, and coverage.
- Provided preset configurations for common analysis tasks and LLM actions, enhancing usability and flexibility.
2026-01-03 17:37:49 +08:00
catlog22
6a45035e3f fix: align test-fix-agent with code-developer task parsing
- Add Command-to-Tool Mapping for pre_analysis commands
- Add Execution Mode Selection for implementation_approach steps
  - command field exists → Execute CLI via Bash
  - no command → Agent direct execution with test_commands
2026-01-03 17:34:55 +08:00
catlog22
28bd781062 fix: improve workflow execute command and agent task parsing
- Fix bash command syntax in execute.md for Windows compatibility
  - Convert multi-line for loop to single-line format
  - Use single quotes for grep patterns to avoid escaping issues

- Simplify agent prompt template in execute.md
  - Path-based invocation instead of embedding task content
  - Add [FLOW_CONTROL] and "Implement" markers to trigger agent behavior

- Enhance code-developer.md Task JSON parsing
  - Add explicit Task JSON field mapping (requirements, acceptance, etc.)
  - Add STEP 1/2/3 execution flow for clarity
  - Add Pre-Analysis Execution format with command-to-tool mapping
  - Define default behavior when command field is missing
  - Priority: Use tech_stack from JSON before auto-detection

- Add execution_config alignment rules to action-planning-agent.md
  - Ensure meta.execution_config matches implementation_approach
  - "agent" mode: no command fields, cli_tool: null
  - "hybrid" mode: some command fields
  - "cli" mode: all steps have command fields
2026-01-03 17:26:23 +08:00
catlog22
9922d455da feat: Add templates for autonomous actions, orchestrators, sequential phases, and skill documentation
- Introduced a comprehensive template for autonomous actions, detailing structure, execution, and error handling.
- Added an orchestrator template to manage state and decision logic for autonomous actions.
- Created a sequential phase template to outline execution steps and objectives for structured workflows.
- Developed a skill documentation template to standardize the generation of skill entry files.
- Implemented a Python script to compare search results between hybrid and cascade methods, analyzing ranking changes.
2026-01-03 15:58:31 +08:00
catlog22
ac23fe5b5a docs: sync version numbers to v6.3.18 across all documentation
- Update README.md/README_CN.md badges and version text to v6.3.18
- Update INSTALL.md version menu examples from v4.6.0 to v6.3.18
- Fix INSTALL_CN.md repository URL (Claude-CCW → Claude-Code-Workflow)
- Fix INSTALL_CN.md directory name (Dmsflow → Claude-Code-Workflow)
2026-01-03 15:22:57 +08:00
catlog22
bab5625123 feat: 添加全局环境变量加载功能并更新配置说明 2026-01-03 15:14:45 +08:00
catlog22
f674b90a62 chore: add .ccw/worktrees/ to gitignore 2026-01-03 12:49:13 +08:00
catlog22
6a545fdeb7 fix(issue): Enhance worktree detection with fallback support
- Add normalizePath() for Windows case-insensitive comparison
- Add resolveMainRepoFromGitFile() to parse .git file when git command fails
- Enhanced fallback logic reads .git file content (gitdir: path) to find main repo
- Supports worktree detection even without git CLI available
2026-01-03 12:32:26 +08:00
catlog22
b01f021f1c docs(issue): Simplify worktree instructions with auto-detection
ccw issue commands now auto-detect worktree and redirect to main repo,
so shell_command no longer needs workdir parameter.
2026-01-03 12:27:59 +08:00
catlog22
f934ea6664 feat(issue): Auto-detect worktree and redirect to main repo
getProjectRoot() now detects if running from a git worktree and
automatically resolves to the main repository path. This allows
all ccw issue commands to work correctly from within a worktree.

Uses git rev-parse --git-common-dir to find main repo's .git
2026-01-03 12:26:34 +08:00
catlog22
52639c9bdd fix(issue): Use correct Codex tool interfaces
- update_plan: { explanation, plan: [{step, status}] }
- shell_command: { command, workdir } for ccw commands in main repo
- multi_tool_use.parallel for reading context files in parallel
2026-01-03 12:19:39 +08:00
catlog22
152fb6b6ad fix(issue): Fix worktree execution and Codex tool compatibility
- ccw issue commands must run from main repo (not worktree)
- Add worktree execution pattern: fetch solution -> cd worktree -> implement -> cd main -> done
- Replace TodoWrite with update_plan for Codex compatibility
- Add rule 10: worktree ccw commands from main repo
2026-01-03 12:12:49 +08:00
catlog22
990cf8a05d fix(issue): Improve worktree implementation safety
- Use absolute paths via git rev-parse --show-toplevel
- Add cleanup traps for graceful failure handling (EXIT/INT/TERM)
- Add git worktree prune at startup for stale worktrees
- Validate main repo state before merge (fallback to PR if dirty)
- Change default to "Create PR" for parallel execution safety
- Move worktree directory to .ccw/worktrees/ (gitignored)
2026-01-03 11:56:15 +08:00
catlog22
713894090d feat(codexlens): Improve search defaults and add explicit SPLADE mode
Config changes:
- Disable SPLADE by default (slow ~360ms), use FTS instead
- Enable use_fts_fallback by default for faster sparse search

CLI improvements:
- Fix duplicate index_app typer definition
- Add cascade_search dispatch for cascade method
- Rename 'mode' to 'method' in search output
- Mark embeddings-status, splade-status as deprecated
- Add enable_splade and enable_cascade to search options

Hybrid search:
- Add enable_splade parameter for explicit SPLADE mode
- Add fallback handling when SPLADE is requested but unavailable
2026-01-03 11:49:58 +08:00
catlog22
2391c77910 feat(issue): Add user choice for worktree completion in Claude execute.md
- Replace auto-merge with AskUserQuestion (merge/PR/keep)
- Consistent with .codex/prompts/issue-execute.md behavior
2026-01-03 11:49:14 +08:00
catlog22
ffb0e90ff3 feat(issue): Add user choice for worktree completion (merge/PR/keep)
- Replace auto-delete cleanup with AskUserQuestion
- Options: Merge to main, Create PR, Keep branch
- Prevents accidental loss of worktree commits
2026-01-03 11:48:14 +08:00
catlog22
740bd1b61e fix(codexlens): Fix constructor and path handling issues
1. GlobalSymbolIndex constructor: Add project_id parameter lookup
   - Get project_id from registry using source_root
   - Pass project_id to GlobalSymbolIndex constructor

2. Binary cascade search path handling:
   - Add VectorMetadataStore import for centralized search
   - Fix _build_results_from_candidates to handle centralized mode
   - Use VectorMetadataStore for metadata, source_index_db for embeddings
   - Properly distinguish between index_root and index_path

3. Dense reranking for centralized search:
   - Get chunk metadata from _vectors_meta.db
   - Group chunks by source_index_db
   - Retrieve dense embeddings from respective _index.db files
2026-01-03 11:47:07 +08:00
catlog22
a364a10d6a fix(ccw): Add path validation for --cd parameter in CLI executor
Validate working directory path before passing to spawn() to prevent
ENOENT errors when malformed paths are provided. Uses existing
validatePath utility for path validation and existence checks.

- Import validatePath from path-resolver
- Validate cd parameter with mustExist check before use
- Provide clear error message with invalid path details
2026-01-03 11:46:51 +08:00
catlog22
441bcb9e99 docs(issue): Update prompts with multi-queue and worktree support
- issue-queue.md: Add multi-queue management section (activate, priority)
- issue-execute.md: Add --worktree parameter for parallel isolation
- execute.md: Add worktree option in AskUserQuestion and dispatchExecutor
2026-01-03 11:44:14 +08:00
catlog22
714f0c539b feat(workflow): Add archived session support for /workflow:review
- Add --archived flag to explicitly review archived sessions
- Auto-detect session location (active first, then archives)
- Update all path references to use resolved sessionPath
- Add usage examples for archived session review
2026-01-03 11:38:50 +08:00
catlog22
255d4244ea fix(workflow): Add user choice for session completion and sync task status on archive
- Replace auto-complete with AskUserQuestion in execute.md Phase 5
  - User can choose "Enter Review" or "Complete Session"
- Fix archived tasks showing incomplete on dashboard
  - executeArchive now updates all .task/*.json status to completed
2026-01-03 11:36:20 +08:00
catlog22
4fb247f7c5 feat(issue): Add multi-queue support and enhanced failure handling
- Add --queue parameter for explicit queue targeting (next, dag, detail, done, retry)
- Implement serialized multi-queue execution (complete Q1 before Q2)
- Add queue activate/priority subcommands for multi-queue management
- Add FailureDetail interface for structured failure tracking
- Preserve failure history on retry for debugging
- Show failure reasons and retry count in queue status display
- Auto-detect queue from item ID in done/detail commands
2026-01-03 11:31:49 +08:00
catlog22
54fd94547c feat: Enhance embedding generation and search capabilities
- Added pre-calculation of estimated chunk count for HNSW capacity in `generate_dense_embeddings_centralized` to optimize indexing performance.
- Implemented binary vector generation with memory-mapped storage for efficient cascade search, including metadata saving.
- Introduced SPLADE sparse index generation with improved handling and metadata storage.
- Updated `ChainSearchEngine` to prefer centralized binary searcher for improved performance and added fallback to legacy binary index.
- Deprecated `BinaryANNIndex` in favor of `BinarySearcher` for better memory management and performance.
- Enhanced `SpladeEncoder` with warmup functionality to reduce latency spikes during first-time inference.
- Improved `SpladeIndex` with cache size adjustments for better query performance.
- Added methods for managing binary vectors in `VectorMetadataStore`, including batch insertion and retrieval.
- Created a new `BinarySearcher` class for efficient binary vector search using Hamming distance, supporting both memory-mapped and database loading modes.
2026-01-02 23:57:55 +08:00
catlog22
96b44e1482 feat: Add type validation for RRF weights and implement caching for embedder instances 2026-01-02 19:50:51 +08:00
catlog22
c268b531aa feat: Enhance embedding generation to track current index path and improve metadata retrieval 2026-01-02 19:18:26 +08:00
catlog22
0b6e9db8e4 feat: Add centralized vector storage and metadata management for embeddings 2026-01-02 17:18:23 +08:00
catlog22
9157c5c78b feat: Implement centralized storage for SPLADE and vector embeddings
- Added centralized SPLADE database and vector storage configuration in config.py.
- Updated embedding_manager.py to support centralized SPLADE database path.
- Enhanced generate_embeddings and generate_embeddings_recursive functions for centralized storage.
- Introduced centralized ANN index creation in ann_index.py.
- Modified hybrid_search.py to utilize centralized vector index for searches.
- Implemented methods to discover and manage centralized SPLADE and HNSW files.
2026-01-02 16:53:39 +08:00
catlog22
54fb7afdb2 Enhance semantic search capabilities and configuration
- Added category support for programming and documentation languages in Config.
- Implemented category-based filtering in HybridSearchEngine to improve search relevance based on query intent.
- Introduced functions for filtering results by category and determining file categories based on extensions.
- Updated VectorStore to include a category column in the database schema and modified chunk addition methods to support category tagging.
- Enhanced the WatcherConfig to ignore additional common directories and files.
- Created a benchmark script to compare performance between Binary Cascade, SPLADE, and Vector semantic search methods, including detailed result analysis and overlap comparison.
2026-01-02 15:01:20 +08:00
catlog22
92ed2524b7 feat: Enhance SPLADE indexing command to support multiple index databases and add chunk ID management 2026-01-02 13:25:23 +08:00
catlog22
56c03c847a feat: Add method to retrieve all semantic chunks from the vector store
- Implemented `get_all_chunks` method in `VectorStore` class to fetch all semantic chunks from the database.
- Added a new benchmark script `analyze_methods.py` for analyzing hybrid search methods and storage architecture.
- Included detailed analysis of method contributions, storage conflicts, and FTS + Rerank fusion experiments.
- Updated results JSON structure to reflect new analysis outputs and method performance metrics.
2026-01-02 12:32:43 +08:00
catlog22
9129c981a4 feat: Enhance BinaryANNIndex with vectorized search and performance benchmarking 2026-01-02 11:49:54 +08:00
catlog22
da68ba0b82 feat: Implement cascade indexing command and benchmark script for performance evaluation 2026-01-02 11:24:06 +08:00
catlog22
e21d801523 feat: Add multi-type embedding backends for cascade retrieval
- Implemented BinaryEmbeddingBackend for fast coarse filtering using 256-dimensional binary vectors.
- Developed DenseEmbeddingBackend for high-precision dense vectors (2048 dimensions) for reranking.
- Created CascadeEmbeddingBackend to combine binary and dense embeddings for two-stage retrieval.
- Introduced utility functions for embedding conversion and distance computation.

chore: Migration 010 - Add multi-vector storage support

- Added 'chunks' table to support multi-vector embeddings for cascade retrieval.
- Included new columns: embedding_binary (256-dim) and embedding_dense (2048-dim) for efficient storage.
- Implemented upgrade and downgrade functions to manage schema changes and data migration.
2026-01-02 10:52:43 +08:00
catlog22
195438d26a feat(splade): add cache directory support for ONNX models and improve thread-local database connection handling 2026-01-01 22:40:00 +08:00
catlog22
5bb01755bc Implement SPLADE sparse encoder and associated database migrations
- Added `splade_encoder.py` for ONNX-optimized SPLADE encoding, including methods for encoding text and batch processing.
- Created `SPLADE_IMPLEMENTATION.md` to document the SPLADE encoder's functionality, design patterns, and integration points.
- Introduced migration script `migration_009_add_splade.py` to add SPLADE metadata and posting list tables to the database.
- Developed `splade_index.py` for managing the SPLADE inverted index, supporting efficient sparse vector retrieval.
- Added verification script `verify_watcher.py` to test FileWatcher event filtering and debouncing functionality.
2026-01-01 17:41:22 +08:00
catlog22
520f2d26f2 feat(codex-lens): add unified reranker architecture and file watcher
Unified Reranker Architecture:
- Add BaseReranker ABC with factory pattern
- Implement 4 backends: ONNX (default), API, LiteLLM, Legacy
- Add .env configuration parsing for API credentials
- Migrate from sentence-transformers to optimum+onnxruntime

File Watcher Module:
- Add real-time file system monitoring with watchdog
- Implement IncrementalIndexer for single-file updates
- Add WatcherManager with signal handling and graceful shutdown
- Add 'codexlens watch' CLI command
- Event filtering, debouncing, and deduplication
- Thread-safe design with proper resource cleanup

Tests: 16 watcher tests + 5 reranker test files

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-01 13:23:52 +08:00
catlog22
8ac27548ad refactor(lite-execute): unify task prompt builder with scope+modification_points
- Consolidate Agent and CLI prompt builders into single buildExecutionPrompt()
- Replace file-based task format with scope + modification_points structure
- Simplify to 4-part task template: Modification Points → How → Reference → Done
- Remove duplicate formatTaskForCLI and buildCLIPrompt functions

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-01 12:46:17 +08:00
catlog22
adc0dd23e4 feat(docs): add swagger-docs command for RESTful API documentation
Add new /memory:swagger-docs command to generate complete Swagger/OpenAPI
documentation following RESTful standards with:
- Global security configuration (Bearer Token auth)
- Complete endpoint documentation with parameters and responses
- Unified error code specification (AUTH/PARAM/BIZ/SYS)
- Multi-language support (--lang zh|en, default: zh)
- Validation test reports

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-01 11:41:57 +08:00
catlog22
31a45f1f30 Add graph expansion and cross-encoder reranking features
- Implemented GraphExpander to enhance search results with related symbols using precomputed neighbors.
- Added CrossEncoderReranker for second-stage search ranking, allowing for improved result scoring.
- Created migrations to establish necessary database tables for relationships and graph neighbors.
- Developed tests for graph expansion functionality, ensuring related results are populated correctly.
- Enhanced performance benchmarks for cross-encoder reranking latency and graph expansion overhead.
- Updated schema cleanup tests to reflect changes in versioning and deprecated fields.
- Added new test cases for Treesitter parser to validate relationship extraction with alias resolution.
2025-12-31 16:58:59 +08:00
catlog22
4bde13e83a chore: bump version to 6.3.18
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-30 22:16:52 +08:00
catlog22
a5ab3f8b26 feat(docs): enhance issue planning and queue documentation with new guidelines and commands 2025-12-30 22:15:16 +08:00
catlog22
d183a647dd chore: bump version to 6.3.17
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-30 20:02:59 +08:00
catlog22
e5797bff8f feat(docs): add guidelines for Git operations to ensure parallel task safety 2025-12-30 19:56:31 +08:00
catlog22
4d73a3c9a9 feat(cli): add streaming output to Dashboard and child process termination
- Add broadcastStreamEvent() for real-time CLI output to Dashboard
- Send CLI_EXECUTION_STARTED/OUTPUT/COMPLETED events via /api/hook
- Add killCurrentCliProcess() to terminate child CLI on SIGINT/SIGTERM
- Track child process reference for cleanup on interruption
- Make CLI stream viewer panel full-height (calc(100vh - 32px))
- Fix completion status not updating by using consistent executionId

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-30 15:56:18 +08:00
catlog22
754cddd4ad fix(python): improve Python detection and pip command reliability
- Add shared python-utils.ts module for consistent Python detection
- Use `python -m pip` instead of direct pip command (fixes "pip not found")
- Support CCW_PYTHON env var for custom Python path
- Use Windows py launcher to find compatible versions (3.9-3.12)
- Warn users when Python version may not be compatible with onnxruntime

Fixes issues where users couldn't install ccw-litellm due to:
- pip not in PATH
- Only pip3 available (not pip)
- Python 3.13+ without onnxruntime support

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-30 15:23:44 +08:00
catlog22
f6cc3736b2 feat(cli): support stdin input for issue creation and solution commands 2025-12-30 14:51:25 +08:00
catlog22
6e99cd97ca feat(docs): update Bash tool usage to enforce foreground execution for CLI calls 2025-12-30 14:28:32 +08:00
catlog22
f566b8aabc feat(cli): add --debug/-d flag for CLI debugging
- Add -d/--debug option to ccw cli command
- Enable debug logging at runtime when flag is set
- Change DEBUG check from const to function for runtime evaluation
- Support debug mode for both exec and status subcommands
- Update help text to include --debug option

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 23:26:48 +08:00
catlog22
6efc499c77 feat(cli): add detailed debug logging for CLI execution
- Add debugLog and errorLog utility functions with DEBUG env control
- Add logging for tool availability check (TOOL_CHECK)
- Add logging for command building (BUILD_CMD)
- Add logging for process spawn (SPAWN, STDIN)
- Add logging for process completion (CLOSE, STATUS)
- Enhance error output with command details, exit code, and stderr
- Add troubleshooting hints for common failures
- Support DEBUG=true or CCW_DEBUG=true environment variables

Closes #46

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 23:17:39 +08:00
catlog22
2c675ee4db chore: bump version to 6.3.14
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 22:57:02 +08:00
catlog22
f6dfe28e08 refactor(issue): rename 'labels' to 'tags' in issue schemas and related code 2025-12-29 22:55:33 +08:00
catlog22
e8e8746cc6 refactor(issue): update brief mode to use 'labels' instead of 'tags' in issue listing 2025-12-29 22:47:55 +08:00
catlog22
603bc00bca refactor(issue): enhance documentation and add core guidelines for data access 2025-12-29 22:41:10 +08:00
catlog22
ae76926d5a feat(queue): support solution-based queues and update metadata handling 2025-12-29 22:14:06 +08:00
catlog22
fd48045fe3 Refactor issue management and history tracking
- Removed the interactive issue management command and its associated documentation.
- Enhanced the issue planning command to streamline project context reading and solution creation.
- Improved queue management with conflict clarification and status syncing from queues.
- Added functionality to track completed issues, moving them to a history file upon completion.
- Updated CLI options to support syncing issue statuses from queues.
- Introduced new API endpoint for retrieving completed issues from history.
- Enhanced error handling and validation for issue updates and queue management.
2025-12-29 21:42:06 +08:00
catlog22
6ec6643448 refactor(issue-plan-agent): enhance conflict detection and execution flow 2025-12-29 20:36:56 +08:00
catlog22
945fda2d14 docs(issue): update agent/prompts to use CLI endpoints
- issue-plan-agent.md: Use `ccw issue solution` instead of Bash echo
- issue-plan.md (codex): Use `ccw issue solution` endpoint
- issue-queue.md (codex): Remove assigned_executor from schema

All solution creation now uses the dedicated CLI endpoint for:
- Auto-increment ID: SOL-{issue-id}-{seq}
- Proper JSONL format with trailing newline
- Multi-solution support per issue

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 20:28:39 +08:00
catlog22
7d71f603fe feat(issue): add solution endpoint with auto-increment ID
- Add `ccw issue solution <id> --data '{...}'` for solution creation
- Add createSolution() with proper JSONL handling (trailing newline)
- Fix writeSolutions() to always add trailing newline
- Update plan.md to use CLI endpoint

Supports multiple solutions per issue with sequential IDs.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 20:24:31 +08:00
catlog22
bd11a538a7 docs(issue/new): update Phase 5 to use ccw issue create endpoint
Replace manual Bash echo with CLI endpoint documentation:
- Auto-increment ID: ISS-YYYYMMDD-NNN
- Proper JSONL format with trailing newline
- JSON output with created issue

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 20:16:24 +08:00
catlog22
b9b4da6d8c feat(issue): add create endpoint with auto-increment ID
- Add `ccw issue create --data '{...}'` for programmatic issue creation
- Add generateIssueId() for auto-increment: ISS-YYYYMMDD-NNN
- Add createIssue() with proper JSONL handling (trailing newline)
- Fix writeIssues() to always add trailing newline

Fixes JSONL format corruption when appending via shell echo.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 20:12:57 +08:00
catlog22
70f8b14eaa refactor(vector_store): use safer SQL query construction pattern
Replaces f-string interpolation with safer string formatting.
Adds documentation on SQL injection prevention.
No functional changes - parameterized queries still used.

Fixes: ISS-1766921318981-9

Solution-ID: SOL-1735386000-9
Issue-ID: ISS-1766921318981-9
Task-ID: T1
2025-12-29 20:09:49 +08:00
catlog22
0c8b2f2ec9 fix(vector_store): add bounds checking for chunk ID generation
Prevents potential integer overflow when start_id is near sys.maxsize.
Adds validation before range() calculation in batch insert methods.

Fixes: ISS-1766921318981-6

Solution-ID: SOL-1735386000-6
Issue-ID: ISS-1766921318981-6
Task-ID: T1
2025-12-29 20:02:19 +08:00
catlog22
d532b3fd02 refactor(queue): streamline output requirements and storage structure documentation 2025-12-29 19:54:10 +08:00
catlog22
c56104c082 fix(vector_store): add null check for ANN search results before filtering
Prevents errors when HNSW search returns null/empty results due to race conditions.
Adds validation for ids and distances before zip operation.

Fixes: ISS-1766921318981-5

Solution-ID: SOL-1735386000-5
Issue-ID: ISS-1766921318981-5
Task-ID: T1
2025-12-29 19:53:32 +08:00
catlog22
66ae1972ae refactor(issue): remove assigned_executor from QueueItem interface
Queue is an execution plan without executor assignment.
Executor is determined at runtime by /issue:execute command.

Changes:
- Remove assigned_executor from QueueItem interface
- Remove from dag nodes, list display, execution_hints
- Simplify queue list output (remove Executor column)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:49:25 +08:00
catlog22
7f4433e449 fix(vector_store): add parameter validation for min_score range
Validates min_score is within [0.0, 1.0] for cosine similarity.
Raises ValueError for out-of-range values to prevent unexpected filtering.

Fixes: ISS-1766921318981-14

Solution-ID: SOL-1735386000-14
Issue-ID: ISS-1766921318981-14
Task-ID: T1
2025-12-29 19:46:26 +08:00
catlog22
e1f2fc72d9 refactor(schema): remove assigned_executor from queue-schema
Queue produces execution plan without executor assignment.
Executor is determined at runtime by /issue:execute command.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:45:43 +08:00
catlog22
aa093f9468 refactor(issue/queue): remove assigned_executor field from schema
Executor assignment is not needed in solution schema - execution
context is determined at runtime.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:42:27 +08:00
catlog22
a27f76abcb refactor(issue/queue): simplify Phase 1 and Phase 5 with semantic descriptions
- Replace complex JavaScript code in Phase 1 with semantic bullet points
- Simplify Phase 5 validation code to semantic description
- Add Quality Checklist for completion verification
- Consistent style with plan.md optimizations

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:41:32 +08:00
catlog22
df34ef38d9 refactor(issue/plan): update semantic grouping limit to 4 issues per group and enhance conflict handling process 2025-12-29 19:38:45 +08:00
catlog22
60fbb4177c fix(config): add specific exception handling for path operations
Replaces generic Exception handling with specific PermissionError and OSError
handling in __post_init__ and ensure_runtime_dirs(). Provides clear diagnostic
messages to distinguish permission issues from other filesystem errors.

Solution-ID: SOL-1735385400008
Issue-ID: ISS-1766921318981-8
Task-ID: T1
2025-12-29 19:34:27 +08:00
catlog22
3289562be7 docs(issue/plan): add quality checklist for completion verification
Checklist items:
- Solution files exist for all issues
- Auto-binding for single solutions
- User selection for multi-solutions
- Tasks have modification_points
- Acceptance criteria quantified
- Conflicts detected
- Status updated to planned

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:32:19 +08:00
catlog22
73fc68a187 refactor(issue/plan): remove redundant file specs from command doc
Agent (issue-plan-agent.md) handles file generation.
Command doc should only describe input/output behavior.

Removed: Generate Files, Storage Structure, Completion Criteria
Kept: Command Output JSON format, Behavior summary

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:31:00 +08:00
catlog22
bce6fa7a91 refactor(issue/new): simplify clarification to open-ended prompt
Remove prescriptive options (Bug fix/New feature/Improvement)
that may interfere with natural issue description.

Now: single open-ended prompt for user to describe freely.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:28:03 +08:00
catlog22
88724a4df9 refactor(issue): simplify Issue schema and remove lifecycle_requirements
Schema changes:
- Remove lifecycle_requirements (deferred to plan agent)
- Remove solution_count (computed dynamically from solutions/*.jsonl)
- Keep context as single source of truth (remove problem_statement)
- Add feedback[] for failure history + human clarifications
- Add source, source_url, labels, expected/actual_behavior

Fields removed (unused downstream):
- lifecycle_requirements.test_strategy
- lifecycle_requirements.regression_scope
- lifecycle_requirements.acceptance_type
- lifecycle_requirements.commit_strategy
- solution_count (denormalized)

Fields added:
- feedback[]: { type, stage, content, created_at }
- source, source_url, labels
- expected_behavior, actual_behavior, affected_components

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:25:58 +08:00
catlog22
5914b1c5fc fix(vector-store): protect bulk insert mode transitions with lock
Ensure begin_bulk_insert() and end_bulk_insert() are fully
lock-protected to prevent TOCTOU race conditions.

Solution-ID: SOL-1735392000003
Issue-ID: ISS-1766921318981-12
Task-ID: T2
2025-12-29 19:20:02 +08:00
catlog22
d8be23fa83 fix(vector-store): add lock protection for bulk insert mode flag
Protect _bulk_insert_mode flag and accumulation lists with
_ann_write_lock to prevent corruption during concurrent access.

Solution-ID: SOL-1735392000003
Issue-ID: ISS-1766921318981-12
Task-ID: T1
2025-12-29 19:16:30 +08:00
catlog22
ffbc4a4b76 style(issue/new): use hybrid Phase + table flow diagram
Combines sequential Phase structure with inline table for branching:
- Phase 1-4 for overall flow clarity
- Table for Score 0/1-2/3 decision branching
- More compact and scannable than pure ASCII boxes

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:16:25 +08:00
catlog22
dd62a7ac13 refactor(issue/new): make ACE search conditional on clarity
- ACE only for medium clarity (score 1-2), skip for:
  - GitHub URLs (score 3): already has context
  - Vague inputs (score 0): needs clarification first
- Limit to quick search: max 3 keywords, max 3 files
- Non-blocking: ACE failure continues without hints
- Note: Deep exploration deferred to /issue:plan

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:14:13 +08:00
catlog22
3f29dfd4cf refactor(issue/new): simplify command with clarity-based flow
Key changes:
- Add Clarity Detection (score 0-3) to determine question needs
- Remove mandatory Lifecycle Configuration questions (auto-detect)
- Integrate ACE tool for smart context discovery
- Ask only 1 question for vague inputs (clarityScore < 2)
- Direct creation for clear inputs (GitHub URL, structured text)
- Reduce from 6 phases to streamlined flow

Decision flow:
- Score 3: GitHub URL → parse → create directly
- Score 2: Structured text → parse + ACE → create directly
- Score 0-1: Vague → ask clarification → confirm → create

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 19:10:49 +08:00
catlog22
3fdd52742b fix(storage): handle rollback failures in batch operations
Adds nested exception handling in add_files() and _migrate_fts_to_external()
to catch and log rollback failures. Uses exception chaining to preserve both
transaction and rollback errors, preventing silent database inconsistency.

Solution-ID: SOL-1735385400010
Issue-ID: ISS-1766921318981-10
Task-ID: T1
2025-12-29 19:08:49 +08:00
catlog22
76ab4d67fe test(entities): add zero vector validation tests
Add comprehensive test coverage for zero and near-zero vector
detection in SemanticChunk embedding validation.

Solution-ID: SOL-20251228113612
Issue-ID: ISS-1766921318981-7
Task-ID: T2
2025-12-29 19:03:20 +08:00
catlog22
c859af1abf fix(entities): validate embeddings are non-zero vectors
Add L2 norm check to SemanticChunk.validate_embedding to reject
zero vectors. Prevents division by zero in cosine similarity
calculations downstream in vector search.

Solution-ID: SOL-20251228113612
Issue-ID: ISS-1766921318981-7
Task-ID: T1
2025-12-29 19:01:27 +08:00
catlog22
6a73d3c379 fix(search): handle path operation failures in symbol filtering
Adds robust exception handling for os.path.commonpath() in search_symbols()
to prevent crashes on malformed paths and Windows cross-drive scenarios.
Invalid symbols are skipped with debug logging, search continues.

Solution-ID: SOL-1735385400004
Issue-ID: ISS-1766921318981-4
Task-ID: T1
2025-12-29 18:59:10 +08:00
catlog22
5d5652c2c5 fix(sqlite-store): improve thread tracking in connection cleanup
Add fallback validation to detect dead threads missed by
threading.enumerate(), ensuring all stale connections are cleaned.

Solution-ID: SOL-1735392000002
Issue-ID: ISS-1766921318981-3
Task-ID: T2
2025-12-29 18:50:22 +08:00
catlog22
b958a1ea96 fix(sqlite-store): add periodic cleanup timer for connection pool
Implement background timer to proactively clean stale connections
every 5 minutes, preventing indefinite accumulation.

Solution-ID: SOL-1735392000002
Issue-ID: ISS-1766921318981-3
Task-ID: T1
2025-12-29 18:43:55 +08:00
catlog22
bc385a32fd test(storage): add TypeScript storage manager concurrency tests
Solution-ID: SOL-1735410004
Issue-ID: ISS-1766921318981-24
Task-ID: T4
2025-12-29 18:38:46 +08:00
catlog22
9a45732a39 test(codex-lens): add connection pool stress tests
Solution-ID: SOL-1735410004
Issue-ID: ISS-1766921318981-24
Task-ID: T3
2025-12-29 18:16:03 +08:00
catlog22
015b46e58b test(codex-lens): add concurrent write operation tests
Solution-ID: SOL-1735410004
Issue-ID: ISS-1766921318981-24
Task-ID: T2
2025-12-29 18:12:09 +08:00
catlog22
042a99dbe3 test(codex-lens): add concurrent read operation tests
Solution-ID: SOL-1735410004

Issue-ID: ISS-1766921318981-24

Task-ID: T1
2025-12-29 17:59:08 +08:00
catlog22
99291053f5 test(cli-executor): add end-to-end orchestration validation tests
Solution-ID: SOL-1735410003

Issue-ID: ISS-1766921318981-23

Task-ID: T4
2025-12-29 17:50:33 +08:00
catlog22
99eeeff6f7 test(cli-executor): add qwen/codex and multi-tool workflow tests
Solution-ID: SOL-1735410003

Issue-ID: ISS-1766921318981-23

Task-ID: T3
2025-12-29 17:36:50 +08:00
catlog22
883b9f0672 refactor(issue): unify Solution ID format to SOL-{issue-id}-{seq}
- Replace timestamp-based ID generation with issue-id-based format
- generateSolutionId() now accepts issueId and existing solutions
- Automatically calculates next sequence number (SOL-GH-123-1, -2, -3)
- Update taskAction and bindAction to use new format
- Ensures consistency with agent-generated IDs

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 17:33:12 +08:00
catlog22
3c07e743e1 fix(issue-plan-agent): ensure shell safety by escaping single quotes in solution JSON 2025-12-29 17:30:19 +08:00
catlog22
823e1dc487 test(cli-executor): add gemini workflow integration tests
Solution-ID: SOL-1735410003

Issue-ID: ISS-1766921318981-23

Task-ID: T2
2025-12-29 17:29:48 +08:00
catlog22
3537c0fc74 test(cli-executor): enhance solution registration and binding process 2025-12-29 17:21:00 +08:00
catlog22
f3e23f0a57 test(cli-executor): add integration test infrastructure
Solution-ID: SOL-1735410003

Issue-ID: ISS-1766921318981-23

Task-ID: T1
2025-12-29 17:15:15 +08:00
catlog22
3df1eac2fc test(ci): add visual regression testing workflow
Solution-ID: SOL-1735410002

Issue-ID: ISS-1766921318981-22

Task-ID: T4
2025-12-29 16:42:31 +08:00
catlog22
141472117d test(ui-tools): add visual regression tests for prototype instantiation
Solution-ID: SOL-1735410002

Issue-ID: ISS-1766921318981-22

Task-ID: T3
2025-12-29 16:37:10 +08:00
catlog22
e2dbeca080 test(ui-tools): add visual regression tests for preview generation
Solution-ID: SOL-1735410002

Issue-ID: ISS-1766921318981-22

Task-ID: T2
2025-12-29 16:15:12 +08:00
catlog22
70063f4045 test(ui-tools): add visual regression testing infrastructure
Solution-ID: SOL-1735410002
Issue-ID: ISS-1766921318981-22
Task-ID: T1
2025-12-29 15:47:08 +08:00
catlog22
8578d2d426 test(litellm): add integration tests for retry and rate limiting
Solution-ID: SOL-1735410001

Issue-ID: ISS-1766921318981-21

Task-ID: T3
2025-12-29 15:14:03 +08:00
catlog22
5d31bfd9fa test(litellm): add executor error scenario and validation tests
Solution-ID: SOL-1735410001

Issue-ID: ISS-1766921318981-21

Task-ID: T2
2025-12-29 13:28:11 +08:00
catlog22
c7291ba532 test(litellm): add comprehensive error scenario tests for client
Solution-ID: SOL-1735410001

Issue-ID: ISS-1766921318981-21

Task-ID: T1
2025-12-29 13:13:33 +08:00
catlog22
1396010437 fix(embedder): add lock protection for cache read operations
Protect fast path cache read in get_embedder() to prevent KeyError

during concurrent access and cache clearing operations.

Solution-ID: SOL-1735392000001

Issue-ID: ISS-1766921318981-2

Task-ID: T1
2025-12-29 12:33:23 +08:00
catlog22
1654b121bc test(routes): add integration tests for CodexLens and discovery routes
Solution-ID: SOL-1735386000005

Issue-ID: ISS-1766921318981-19

Task-ID: T4
2025-12-29 12:22:09 +08:00
catlog22
d5130fc4da test(routes): add integration tests for session and core-memory routes
Solution-ID: SOL-1735386000005

Issue-ID: ISS-1766921318981-19

Task-ID: T3
2025-12-29 11:58:00 +08:00
catlog22
c4f3afd8eb chore: bump version to 6.3.12
- Refactor issue workflow with unified solution ID format (SOL-{issue-id}-{seq})
- Add follow-up questions to issue creation flow
- Fix JSONL append newline handling
- Align conflicts format in plan.md with agent output

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 11:53:12 +08:00
catlog22
fb2f80ee3a fix(issue/plan): align conflicts format and add missing helper function
- Update Return Summary conflicts format to match Phase 3 processing requirements
- Add extractSelectedSolutionId helper function for solution selection

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 11:48:47 +08:00
catlog22
dda6af130c refactor(issue): unify solution ID format to SOL-{issue-id}-{seq}
- Update solution-schema.json pattern to support new format
- Add Solution ID Format specification to plan.md
- Fix JSON parsing with extractJsonFromMarkdown + try-catch
- Update all examples in agent and prompt files:
  - issue-plan-agent.md
  - issue-queue-agent.md
  - issue-execute.md
  - issue-queue.md
  - queue.md

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 11:45:31 +08:00
catlog22
0d82c9fa03 refactor(issue): simplify extended_context and add follow-up questions
- Replace discovery_context with minimal extended_context (3 fields: location, suggested_fix, notes)
- Add Phase 4.5: intelligent follow-up questions for missing issue fields
- Fix JSONL append to ensure proper newline handling
- Update schema and plan.md to use new extended_context structure

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 11:33:59 +08:00
catlog22
7c389d5028 test(routes): add integration tests for CLI and memory routes
Solution-ID: SOL-1735386000005

Issue-ID: ISS-1766921318981-19

Task-ID: T2
2025-12-29 10:51:57 +08:00
catlog22
d5704f8344 test(routes): add integration tests for status and system routes
Solution-ID: SOL-1735386000005

Issue-ID: ISS-1766921318981-19

Task-ID: T1
2025-12-29 10:27:20 +08:00
catlog22
ec4018a930 test(embedding-batch): add tests for batch embedding operations
Solution-ID: SOL-1735386000004

Issue-ID: ISS-1766921318981-18

Task-ID: T4
2025-12-29 10:11:27 +08:00
catlog22
673cb03a2e test(semantic-search): add integration tests for semantic search workflow
Solution-ID: SOL-1735386000004

Issue-ID: ISS-1766921318981-18

Task-ID: T3
2025-12-29 09:59:26 +08:00
catlog22
4d7bf5b245 test(embedding-client): add unit tests for embedding generation
Solution-ID: SOL-1735386000004

Issue-ID: ISS-1766921318981-18

Task-ID: T2
2025-12-29 09:50:30 +08:00
catlog22
267426e332 test(core-memory-store): add unit tests for memory store operations
Solution-ID: SOL-1735386000004

Issue-ID: ISS-1766921318981-18

Task-ID: T1
2025-12-29 09:42:01 +08:00
catlog22
d68401fa1a test(core-memory-store): add assertion for missing memory retrieval 2025-12-29 09:35:52 +08:00
catlog22
eb4ba89693 feat(issue-plan): enhance conflict detection and resolution process with semantic grouping and user clarifications 2025-12-29 09:26:57 +08:00
catlog22
ef3b6b9f6e test(session-clustering): add integration tests for session clustering
Solution-ID: SOL-1735386000003

Issue-ID: ISS-1766921318981-17

Task-ID: T4
2025-12-29 09:03:50 +08:00
catlog22
2d1be7cd4f test(session-archive): add integration tests for archiving and cleanup
Solution-ID: SOL-1735386000003

Issue-ID: ISS-1766921318981-17

Task-ID: T3
2025-12-29 08:50:32 +08:00
catlog22
bf0a2bde34 test(session-content): add integration tests for session CRUD operations
Solution-ID: SOL-1735386000003

Issue-ID: ISS-1766921318981-17

Task-ID: T2
2025-12-29 08:44:09 +08:00
catlog22
d85ab2a12c test(session-lifecycle): add integration tests for session creation
Solution-ID: SOL-1735386000003

Issue-ID: ISS-1766921318981-17

Task-ID: T1
2025-12-29 08:39:32 +08:00
catlog22
33a2bdb9f0 test(browser-launcher): add cross-platform browser launch tests
Solution-ID: SOL-1735386000002

Issue-ID: ISS-1766921318981-16

Task-ID: T4
2025-12-29 00:19:37 +08:00
catlog22
11a7dcb6c8 test(file-utils): add unit tests for file operations
Solution-ID: SOL-1735386000002

Issue-ID: ISS-1766921318981-16

Task-ID: T3
2025-12-29 00:11:57 +08:00
catlog22
d8e389df00 test(path-validator): add unit tests for path security validation
Solution-ID: SOL-1735386000002

Issue-ID: ISS-1766921318981-16

Task-ID: T2
2025-12-29 00:09:33 +08:00
catlog22
203b51527b test(path-resolver): add unit tests for path resolution and validation
Solution-ID: SOL-1735386000002

Issue-ID: ISS-1766921318981-16

Task-ID: T1
2025-12-29 00:05:52 +08:00
catlog22
bf05886770 fix(queue): streamline validation and status update logic in queue processing 2025-12-28 23:47:26 +08:00
catlog22
079ecdad3e test(commands): add unit tests for session and server commands
Solution-ID: SOL-1735386000001

Issue-ID: ISS-1766921318981-15

Task-ID: T4
2025-12-28 23:47:13 +08:00
catlog22
075a8357cd test(core-memory-command): add unit tests for core memory module
Solution-ID: SOL-1735386000001

Issue-ID: ISS-1766921318981-15

Task-ID: T3
2025-12-28 23:08:54 +08:00
catlog22
c99ad377c6 test(memory-command): add unit tests for memory module
Solution-ID: SOL-1735386000001

Issue-ID: ISS-1766921318981-15

Task-ID: T2
2025-12-28 23:01:40 +08:00
catlog22
382d330525 fix(issue): improve queue archiving logic to handle empty tasks and solutions 2025-12-28 22:56:51 +08:00
catlog22
e2f4241b2e feat(cli-stream): add search functionality and improve validation in CLI Stream Viewer 2025-12-28 22:52:32 +08:00
catlog22
32cea006b9 Add initial implementation of the Docsify shell template for interactive software manuals 2025-12-28 22:46:43 +08:00
catlog22
6ffac8810b test(cli-command): add unit tests for CLI command executor
Solution-ID: SOL-1735386000001

Issue-ID: ISS-1766921318981-15

Task-ID: T1
2025-12-28 22:44:47 +08:00
catlog22
84d06f4273 fix(registry): normalize path case for comparison on Windows
Adds case normalization for path comparison on Windows to handle
case-insensitive filesystem behavior. Preserves case-sensitivity on Unix.

Fixes: ISS-1766921318981-13

Solution-ID: SOL-1735386000-13
Issue-ID: ISS-1766921318981-13
Task-ID: T1
2025-12-28 21:51:23 +08:00
catlog22
18cc536f65 refactor(vector-store): use consistent EPSILON constant
Define module-level EPSILON constant and use it in both
_cosine_similarity and _refresh_cache for consistent
floating point precision handling.

Solution-ID: SOL-20251228113619
Issue-ID: ISS-1766921318981-11
Task-ID: T3
2025-12-28 21:40:46 +08:00
catlog22
af2ff54cb7 test(vector-store): add epsilon tolerance edge case tests
Add comprehensive test coverage for near-zero norms, product
underflow, and floating point precision edge cases in
_cosine_similarity function.

Solution-ID: SOL-20251228113619
Issue-ID: ISS-1766921318981-11
Task-ID: T2
2025-12-28 21:37:59 +08:00
catlog22
6486c56850 fix(vector-store): add epsilon tolerance for norm checks
Replace exact zero comparison with epsilon-based check (< 1e-10)
in _cosine_similarity to handle floating point precision issues.
Also check for product underflow to prevent inf/nan from division
by very small numbers.

Solution-ID: SOL-20251228113619
Issue-ID: ISS-1766921318981-11
Task-ID: T1
2025-12-28 21:11:30 +08:00
catlog22
93dcdd2293 fix(config): log configuration loading errors instead of silently ignoring
Replaces bare exception handler in load_settings() with logging.warning()
to help users debug configuration file issues (syntax errors, permissions).
Maintains backward compatibility - errors do not break initialization.

Solution-ID: SOL-1735385400001
Issue-ID: ISS-1766921318981-1
Task-ID: T1
2025-12-28 21:06:23 +08:00
catlog22
58caccb250 test(ranking): add edge case tests for normalize_weights
Add comprehensive test coverage for NaN, infinity, and all-None
edge cases in weight normalization to prevent regression.

Solution-ID: SOL-20251228113631
Issue-ID: ISS-1766921318981-0
Task-ID: T2
2025-12-28 20:59:08 +08:00
catlog22
598eed92cb fix(ranking): add explicit NaN check in normalize_weights
Add math.isnan() check before math.isfinite() to properly catch
NaN values in weight totals. Prevents division by NaN which could
produce unexpected results in RRF fusion calculations.

Solution-ID: SOL-20251228113631
Issue-ID: ISS-1766921318981-0
Task-ID: T1
2025-12-28 20:55:03 +08:00
catlog22
d3e7ecca21 feat: 添加任务跟踪功能,初始化待办事项列表并更新任务状态 2025-12-28 20:50:24 +08:00
catlog22
847abcefce feat: 添加选项以标记任务为失败 2025-12-28 20:45:05 +08:00
catlog22
c24ad501b5 feat: 更新问题执行和队列生成逻辑,支持解决方案格式并增强元数据管理 2025-12-28 20:35:29 +08:00
catlog22
35c7fe28bb feat: 更新队列生成逻辑,使用提供的队列ID并严格限制输出文件 2025-12-28 20:20:13 +08:00
catlog22
a33cacfd75 feat: 添加更新命令以修改问题字段(状态、优先级、标题等) 2025-12-28 20:14:31 +08:00
catlog22
338c3d612c feat: 更新问题规划和队列命令,增强解决方案注册和用户选择逻辑 2025-12-28 19:58:44 +08:00
catlog22
8b17fad723 feat(discovery): enhance discovery progress reading with new schema support 2025-12-28 19:33:17 +08:00
catlog22
169f218f7a feat(discovery): enhance discovery index reading and issue exporting
- Improved the reading of the discovery index by adding a fallback mechanism to scan directories for discovery folders if the index.json is invalid or missing.
- Added sorting of discoveries by creation time in descending order.
- Enhanced the `appendToIssuesJsonl` function to include deduplication logic for issues based on ID and source finding ID.
- Updated the discovery route handler to reflect the number of issues added and skipped during export.
- Introduced UI elements for selecting and deselecting findings in the dashboard.
- Added CSS styles for exported findings and action buttons.
- Implemented search functionality for filtering findings based on title, file, and description.
- Added internationalization support for new UI elements.
- Created scripts for automated API extraction from various project types, including FastAPI and TypeScript.
- Documented the API extraction process and library bundling instructions.
2025-12-28 19:27:34 +08:00
catlog22
3ef1e54412 feat: 更新软件手册,优化截图捕获流程和规则说明 2025-12-28 18:19:39 +08:00
catlog22
4419c50942 feat: enhance internationalization support and improve GPU mode selector with Python environment checks 2025-12-28 17:49:40 +08:00
catlog22
7aa1cda367 feat: add issue discovery view for managing discovery sessions and findings
- Implemented main render function for the issue discovery view.
- Added data loading functions to fetch discoveries, details, findings, and progress.
- Created rendering functions for discovery list and detail sections.
- Introduced filtering and searching capabilities for findings.
- Implemented actions for exporting and dismissing findings.
- Added polling mechanism to track discovery progress.
- Included utility functions for HTML escaping and cleanup.
2025-12-28 17:21:07 +08:00
catlog22
a2c88ba885 feat: Add project guidelines support and enhance project overview rendering 2025-12-28 14:50:50 +08:00
catlog22
e16950ef1e refactor: Remove unused context-tools-ace.md and clean up CLI status management 2025-12-28 14:09:51 +08:00
catlog22
5b973b00ea feat(issue): Enhance queue management with solution-level granularity and improved item identification 2025-12-28 13:58:43 +08:00
catlog22
3a1ebf8684 refactor(issue): Simplify issue and task structures by removing unused fields 2025-12-28 13:39:52 +08:00
catlog22
2eaefb61ab feat: Enhance issue management to support solution-level queues
- Added support for solution-level queues in the issue management system.
- Updated interfaces to include solution-specific properties such as `approach`, `task_count`, and `files_touched`.
- Modified queue handling to differentiate between task-level and solution-level items.
- Adjusted rendering logic in the dashboard to display solutions and their associated tasks correctly.
- Enhanced queue statistics and conflict resolution to accommodate the new solution structure.
- Updated actions (next, done, retry) to handle both tasks and solutions seamlessly.
2025-12-28 13:21:34 +08:00
catlog22
4c6b28030f Enhance project management workflow by introducing dual file system for project guidelines and tech analysis
- Updated workflow initialization to create `.workflow/project-tech.json` and `.workflow/project-guidelines.json` for comprehensive project understanding.
- Added mandatory context reading steps in various commands to ensure compliance with user-defined constraints and technology stack.
- Implemented a new command `/workflow:session:solidify` to capture session learnings and solidify them into project guidelines.
- Introduced a detail action in issue management to retrieve task details without altering status.
- Enhanced documentation across multiple workflow commands to reflect changes in project structure and guidelines.
2025-12-28 12:47:39 +08:00
catlog22
2c42cefa5a feat(issue): add DAG support for parallel execution planning and enhance task fetching 2025-12-28 12:04:10 +08:00
catlog22
35ffd3419e chore(release): v6.3.9 - Issue System Consistency
- Unified four-layer architecture (Schema/Agent/Command/Implementation)
- Upgraded to Rich Plan model with lifecycle fields
- Added multi-solution generation support
- Consolidated schemas (deleted redundant issue-task-jsonl-schema, solutions-jsonl-schema)
- Fixed field naming consistency (acceptance, lifecycle_status, priority mapping)
- Added search tool fallback chain to issue-plan-agent

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-27 23:57:30 +08:00
catlog22
e3223edbb1 fix(plan): Update delivery criteria terminology to acceptance.criteria 2025-12-27 23:54:00 +08:00
catlog22
a061fc1428 fix(issue-plan-agent): Update acceptance criteria terminology and enhance issue loading process with metadata 2025-12-27 23:51:30 +08:00
catlog22
0992d27523 refactor(issue-manager): Enhance queue detail item styling and update modal content 2025-12-27 23:43:40 +08:00
catlog22
5aa0c9610d fix(issue-manager): Add History button to empty queue state
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-27 23:00:17 +08:00
catlog22
7620ff703d feat(issue-manager): Add queue history modal for viewing and switching queues
- Add GET /api/queue/history endpoint to fetch all queues from index
- Add GET /api/queue/:id endpoint to fetch specific queue details
- Add POST /api/queue/switch endpoint to switch active queue
- Add History button in queue toolbar
- Add queue history modal with list view and detail view
- Add switch functionality to change active queue
- Add CSS styles for queue history components

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-27 22:56:32 +08:00
catlog22
d705a3e7d9 fix: Add active_queue_id to QueueIndex interface
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-27 22:48:38 +08:00
catlog22
726151bfea Refactor issue management commands and introduce lifecycle requirements
- Updated lifecycle requirements in issue creation to include new fields for testing, regression, acceptance, and commit strategies.
- Enhanced the planning command to generate structured output and handle multi-solution scenarios.
- Improved queue formation logic to ensure valid DAG and conflict resolution.
- Introduced a new interactive issue management skill for CRUD operations, allowing users to manage issues through a menu-driven interface.
- Updated documentation across commands to reflect changes in task structure and output requirements.
2025-12-27 22:44:49 +08:00
catlog22
b58589ddad refactor: Update issue queue structure and commands
- Changed queue structure from 'queue' to 'tasks' in various files for clarity.
- Updated CLI commands to reflect new task ID usage instead of queue ID.
- Enhanced queue management with new delete functionality for historical queues.
- Improved metadata handling and task execution tracking.
- Updated dashboard and issue manager views to accommodate new task structure.
- Bumped version to 6.3.8 in package.json and package-lock.json.
2025-12-27 22:04:15 +08:00
catlog22
2e493277a1 feat(issue-queue): Enhance task execution flow with priority handling and stuck task reset option 2025-12-27 14:43:18 +08:00
catlog22
8b19edd2de chore: bump version to 6.3.6
🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-27 11:50:35 +08:00
catlog22
3e54b5f7d8 feat(issue-execute): Implement sequential task execution with detailed lifecycle and commit process 2025-12-27 11:46:18 +08:00
catlog22
4da06864f8 feat: Enhance issue and solution management with new UI components and functionality
- Added internationalization support for new issue and solution-related strings in i18n.js.
- Implemented a solution detail modal in issue-manager.js to display solution information and bind/unbind actions.
- Enhanced the skill loading function to combine project and user skills in hook-manager.js.
- Improved queue rendering logic to handle empty states and display queue statistics in issue-manager.js.
- Introduced command modals for queue operations, allowing users to generate execution queues via CLI commands.
- Added functionality to auto-generate issue IDs and regenerate them in the create issue modal.
- Implemented detailed rendering of solution tasks, including acceptance criteria and modification points.
2025-12-27 11:27:45 +08:00
catlog22
8f310339df feat(issue-management): Implement interactive issue management command with CRUD operations
- Added `/issue:manage` command for interactive issue management via CLI.
- Implemented features for listing, viewing, editing, deleting, and bulk operations on issues.
- Integrated GitHub issue fetching and text description parsing for issue creation.
- Enhanced user experience with menu-driven interface and structured output.
- Created helper functions for parsing user input and managing issue data.
- Added error handling and related command references for better usability.

feat(issue-creation): Introduce structured issue creation from GitHub URL or text description

- Added `/issue:new` command to create structured issues from GitHub issues or text descriptions.
- Implemented parsing logic for extracting key elements from issue descriptions.
- Integrated user confirmation for issue creation with options to edit title and priority.
- Ensured proper writing of issues to `.workflow/issues/issues.jsonl` with metadata.
- Included examples and error handling for various input scenarios.
2025-12-27 10:20:34 +08:00
catlog22
0157e36344 feat: add CLI Stream Viewer component for real-time output monitoring
- Implemented a new CLI Stream Viewer to display real-time output from CLI executions.
- Added state management for CLI executions, including handling of start, output, completion, and errors.
- Introduced UI rendering for stream tabs and content, with auto-scroll functionality.
- Integrated keyboard shortcuts for toggling the viewer and handling user interactions.

feat: create Issue Manager view for managing issues and execution queue

- Developed the Issue Manager view to manage issues, solutions, and execution queue.
- Implemented data loading functions for fetching issues and queue data from the API.
- Added filtering and rendering logic for issues and queue items, including drag-and-drop functionality.
- Created detail panel for viewing and editing issue details, including tasks and solutions.
2025-12-27 09:46:12 +08:00
catlog22
cdf4833977 feat(issue): implement JSONL task generation and management for issue resolution
- Added `/issue:plan` command to generate a structured task plan from GitHub issues or descriptions, including delivery and pause criteria, and a dependency graph.
- Introduced JSONL schema for task entries to enforce structure and validation.
- Developed comprehensive issue command with functionalities for initializing, listing, adding, updating, and exporting tasks.
- Implemented error handling and user feedback for various operations within the issue management workflow.
- Enhanced task management with priority levels, phase results, and executor preferences.
2025-12-26 17:21:32 +08:00
catlog22
c8a914aeca Refactor agent configurations and context gathering processes across multiple workflow tools
- Removed agent references in context-gather and test-context-gather commands for clarity.
- Updated test-task-generate to streamline agent configuration references.
- Enhanced action-planning-agent documentation by removing redundant examples.
- Adjusted execute command to eliminate direct agent path references.
- Improved context-gather documentation to clarify agent autonomy and project.json integration.
- Revised test-context-gather to focus on agent delegation and coverage analysis.
- Cleaned up test-task-generate to focus on task generation rules without direct agent references.
- Implemented automatic agent assignment based on exploration file names in deep analysis phase.
- Expanded project exploration phase to include intelligent angle selection based on software type.
- Enhanced output schemas and success criteria for exploration tasks to ensure clarity and completeness.
2025-12-26 16:20:46 +08:00
catlog22
a5ba7c0f6c feat: 更新版本号至6.3.5 2025-12-26 15:43:47 +08:00
catlog22
1cf0d92ec2 feat: 更新冲突解决文档和模式,增加输出模式和策略要求,优化JSON架构 2025-12-26 15:40:40 +08:00
catlog22
02930bd56b feat: 增强任务生成文档,添加用户配置、CLI工具选择和执行策略,优化模块依赖处理 2025-12-26 15:23:41 +08:00
catlog22
4061ae48c4 feat: Implement adaptive RRF weights and query intent detection
- Added integration tests for adaptive RRF weights in hybrid search.
- Enhanced query intent detection with new classifications: keyword, semantic, and mixed.
- Introduced symbol boosting in search results based on explicit symbol matches.
- Implemented embedding-based reranking with configurable options.
- Added global symbol index for efficient symbol lookups across projects.
- Improved file deletion handling on Windows to avoid permission errors.
- Updated chunk configuration to increase overlap for better context.
- Modified package.json test script to target specific test files.
- Created comprehensive writing style guidelines for documentation.
- Added TypeScript tests for query intent detection and adaptive weights.
- Established performance benchmarks for global symbol indexing.
2025-12-26 15:08:47 +08:00
catlog22
ecd5085e51 feat: 优化历史记录输出,增加工具使用统计和过滤提示信息 2025-12-26 12:28:48 +08:00
catlog22
6bc8b7de95 feat: 优化历史记录输出格式,增加提示信息并调整提示预览显示 2025-12-26 12:21:55 +08:00
catlog22
e79e33773f feat: 优化 CLI 历史记录输出格式,增加使用提示并规范化 sourceDir 处理 2025-12-26 12:18:52 +08:00
catlog22
0c0301d811 Refactor project analysis phases: remove diagram generation phase, enhance report generation with detailed structure and quality checks, and introduce consolidation agent for cross-module analysis. Update CLI commands to support final output options and improve history management with copy functionality. 2025-12-26 12:13:27 +08:00
catlog22
89f6ac6804 feat: Implement multi-phase project analysis workflow with Mermaid diagram generation and CPCC compliance documentation
- Phase 3: Added Mermaid diagram generation for system architecture, function modules, algorithms, class diagrams, sequence diagrams, and error flows.
- Phase 4: Assembled analysis and diagrams into a structured CPCC-compliant document with section templates and figure numbering.
- Phase 5: Developed compliance review process with iterative refinement based on analysis findings and user feedback.
- Added CPCC compliance requirements and quality standards for project analysis reports.
- Established a comprehensive project analysis skill with detailed execution flow and report types.
- Enhanced error handling and recovery mechanisms throughout the analysis phases.
2025-12-26 11:44:29 +08:00
catlog22
f14c3299bc docs: add Windows installation requirements
- Add requirements table for all platforms
- Note about better-sqlite3 native compilation
- Recommend Node.js LTS versions to avoid build issues
- Update version badge to 6.3.4

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-26 09:23:28 +08:00
1003 changed files with 229568 additions and 60904 deletions

View File

@@ -1,32 +1,45 @@
# Claude Instructions
- **CLI Tools Usage**: @~/.claude/workflows/cli-tools-usage.md
- **Coding Philosophy**: @~/.claude/workflows/coding-philosophy.md
- **Context Requirements**: @~/.claude/workflows/context-tools-ace.md
- **File Modification**: @~/.claude/workflows/file-modification.md
- **CLI Endpoints Config**: @.claude/cli-tools.json
## CLI Endpoints
**Strictly follow the @.claude/cli-tools.json configuration**
- **CLI Tools Usage**: @~/.claude/workflows/cli-tools-usage.md
- **CLI Endpoints Config**: @~/.claude/cli-tools.json
**Strictly follow the cli-tools.json configuration**
Available CLI endpoints are dynamically defined by the config file:
- Built-in tools and their enable/disable status
- Custom API endpoints registered via the Dashboard
- Managed through the CCW Dashboard Status page
## Tool Execution
- **Context Requirements**: @~/.claude/workflows/context-tools.md
- **File Modification**: @~/.claude/workflows/file-modification.md
### Agent Calls
- **Always use `run_in_background: false`** for Task tool agent calls: `Task({ subagent_type: "xxx", prompt: "...", run_in_background: false })` to ensure synchronous execution and immediate result visibility
- **TaskOutput usage**: Only use `TaskOutput({ task_id: "xxx", block: false })` + sleep loop to poll completion status. NEVER read intermediate output during agent/CLI execution - wait for final result only
### CLI Tool Calls (ccw cli)
- **Always use `run_in_background: true`** for Bash tool when calling ccw cli:
- **Default: `run_in_background: true`** - Unless otherwise specified, always use background execution for CLI calls:
```
Bash({ command: "ccw cli -p '...' --tool gemini", run_in_background: true })
```
- **After CLI call**: If no other tasks, stop immediately - let CLI execute in background, do NOT poll with TaskOutput
- **After CLI call**: Stop output immediately - let CLI execute in background. **DO NOT use TaskOutput polling** - wait for hook callback to receive results
### CLI Analysis Calls
- **Wait for results**: MUST wait for CLI analysis to complete before taking any write action. Do NOT proceed with fixes while analysis is running
- **Value every call**: Each CLI invocation is valuable and costly. NEVER waste analysis results:
- Aggregate multiple analysis results before proposing solutions
### CLI Auto-Invoke Triggers
- **Reference**: See `cli-tools-usage.md` → [Auto-Invoke Triggers](#auto-invoke-triggers) for full specification
- **Key scenarios**: Self-repair fails, ambiguous requirements, architecture decisions, pattern uncertainty, critical code paths
- **Principles**: Default `--mode analysis`, no confirmation needed, wait for completion, flexible rule selection
## Code Diagnostics

View File

@@ -0,0 +1,366 @@
# Claude Code TypeScript LSP 配置指南
> 更新日期: 2026-01-20
> 适用版本: Claude Code v2.0.74+
---
## 目录
1. [方式一:插件市场(推荐)](#方式一插件市场推荐)
2. [方式二MCP Server (cclsp)](#方式二mcp-server-cclsp)
3. [方式三内置LSP工具](#方式三内置lsp工具)
4. [配置验证](#配置验证)
5. [故障排查](#故障排查)
---
## 方式一:插件市场(推荐)
### 步骤 1: 添加插件市场
在Claude Code中执行
```bash
/plugin marketplace add boostvolt/claude-code-lsps
```
### 步骤 2: 安装TypeScript LSP插件
```bash
# TypeScript/JavaScript支持推荐vtsls
/plugin install vtsls@claude-code-lsps
```
### 步骤 3: 验证安装
```bash
/plugin list
```
应该看到:
```
✓ vtsls@claude-code-lsps (enabled)
✓ pyright-lsp@claude-plugins-official (enabled)
```
### 配置文件自动更新
安装后,`~/.claude/settings.json` 会自动添加:
```json
{
"enabledPlugins": {
"pyright-lsp@claude-plugins-official": true,
"vtsls@claude-code-lsps": true
}
}
```
### 支持的操作
- `goToDefinition` - 跳转到定义
- `findReferences` - 查找引用
- `hover` - 显示类型信息
- `documentSymbol` - 文档符号
- `getDiagnostics` - 诊断信息
---
## 方式二MCP Server (cclsp)
### 优势
- **位置容错**自动修正AI生成的不精确行号
- **更多功能**:支持重命名、完整诊断
- **灵活配置**完全自定义LSP服务器
### 安装步骤
#### 1. 安装TypeScript Language Server
```bash
npm install -g typescript-language-server typescript
```
验证安装:
```bash
typescript-language-server --version
```
#### 2. 配置cclsp
运行自动配置:
```bash
npx cclsp@latest setup --user
```
或手动创建配置文件:
**文件位置**: `~/.claude/cclsp.json``~/.config/claude/cclsp.json`
```json
{
"servers": [
{
"extensions": ["ts", "tsx", "js", "jsx"],
"command": ["typescript-language-server", "--stdio"],
"rootDir": ".",
"restartInterval": 5,
"initializationOptions": {
"preferences": {
"includeInlayParameterNameHints": "all",
"includeInlayPropertyDeclarationTypeHints": true,
"includeInlayFunctionParameterTypeHints": true,
"includeInlayVariableTypeHints": true
}
}
},
{
"extensions": ["py", "pyi"],
"command": ["pylsp"],
"rootDir": ".",
"restartInterval": 5
}
]
}
```
#### 3. 在Claude Code中启用MCP Server
添加到Claude Code配置
```bash
# 查看当前MCP配置
cat ~/.claude/.mcp.json
# 如果没有,创建新的
```
**文件**: `~/.claude/.mcp.json`
```json
{
"mcpServers": {
"cclsp": {
"command": "npx",
"args": ["cclsp@latest"]
}
}
}
```
### cclsp可用的MCP工具
使用时Claude Code会自动调用这些工具
- `find_definition` - 按名称查找定义(支持模糊匹配)
- `find_references` - 查找所有引用
- `rename_symbol` - 重命名符号(带备份)
- `get_diagnostics` - 获取诊断信息
- `restart_server` - 重启LSP服务器
---
## 方式三内置LSP工具
### 启用方式
设置环境变量:
**Linux/Mac**:
```bash
export ENABLE_LSP_TOOL=1
claude
```
**Windows (PowerShell)**:
```powershell
$env:ENABLE_LSP_TOOL=1
claude
```
**永久启用** (添加到shell配置):
```bash
# Linux/Mac
echo 'export ENABLE_LSP_TOOL=1' >> ~/.bashrc
source ~/.bashrc
# Windows (PowerShell Profile)
Add-Content $PROFILE '$env:ENABLE_LSP_TOOL=1'
```
### 限制
- 需要先安装语言服务器插件(见方式一)
- 不支持重命名等高级操作
- 无位置容错功能
---
## 配置验证
### 1. 检查LSP服务器是否可用
```bash
# 检查TypeScript Language Server
which typescript-language-server # Linux/Mac
where typescript-language-server # Windows
# 测试运行
typescript-language-server --stdio
```
### 2. 在Claude Code中测试
打开任意TypeScript文件让Claude执行
```typescript
// 测试LSP功能
LSP({
operation: "hover",
filePath: "path/to/your/file.ts",
line: 10,
character: 5
})
```
### 3. 检查插件状态
```bash
/plugin list
```
查看启用的插件:
```bash
cat ~/.claude/settings.json | grep enabledPlugins
```
---
## 故障排查
### 问题 1: "No LSP server available"
**原因**TypeScript LSP插件未安装或未启用
**解决**
```bash
# 重新安装插件
/plugin install vtsls@claude-code-lsps
# 检查settings.json
cat ~/.claude/settings.json
```
### 问题 2: "typescript-language-server: command not found"
**原因**未安装TypeScript Language Server
**解决**
```bash
npm install -g typescript-language-server typescript
# 验证
typescript-language-server --version
```
### 问题 3: LSP响应慢或超时
**原因**:项目太大或配置不当
**解决**
```json
// 在tsconfig.json中优化
{
"compilerOptions": {
"incremental": true,
"skipLibCheck": true
},
"exclude": ["node_modules", "dist"]
}
```
### 问题 4: 插件安装失败
**原因**:网络问题或插件市场未添加
**解决**
```bash
# 确认插件市场已添加
/plugin marketplace list
# 如果没有,重新添加
/plugin marketplace add boostvolt/claude-code-lsps
# 重试安装
/plugin install vtsls@claude-code-lsps
```
---
## 三种方式对比
| 特性 | 插件市场 | cclsp (MCP) | 内置LSP |
|------|----------|-------------|---------|
| 安装复杂度 | ⭐ 低 | ⭐⭐ 中 | ⭐ 低 |
| 功能完整性 | ⭐⭐⭐ 完整 | ⭐⭐⭐ 完整+ | ⭐⭐ 基础 |
| 位置容错 | ❌ 无 | ✅ 有 | ❌ 无 |
| 重命名支持 | ✅ 有 | ✅ 有 | ❌ 无 |
| 自定义配置 | ⚙️ 有限 | ⚙️ 完整 | ❌ 无 |
| 生产稳定性 | ⭐⭐⭐ 高 | ⭐⭐ 中 | ⭐⭐⭐ 高 |
---
## 推荐配置
### 新手用户
**推荐**: 方式一(插件市场)
- 一条命令安装
- 官方维护,稳定可靠
- 满足日常使用需求
### 高级用户
**推荐**: 方式二cclsp
- 完整功能支持
- 位置容错AI友好
- 灵活配置
- 支持重命名等高级操作
### 快速测试
**推荐**: 方式三内置LSP+ 方式一(插件)
- 设置环境变量
- 安装插件
- 立即可用
---
## 附录:支持的语言
通过插件市场可用的LSP
| 语言 | 插件名 | 安装命令 |
|------|--------|----------|
| TypeScript/JavaScript | vtsls | `/plugin install vtsls@claude-code-lsps` |
| Python | pyright | `/plugin install pyright@claude-code-lsps` |
| Go | gopls | `/plugin install gopls@claude-code-lsps` |
| Rust | rust-analyzer | `/plugin install rust-analyzer@claude-code-lsps` |
| Java | jdtls | `/plugin install jdtls@claude-code-lsps` |
| C/C++ | clangd | `/plugin install clangd@claude-code-lsps` |
| C# | omnisharp | `/plugin install omnisharp@claude-code-lsps` |
| PHP | intelephense | `/plugin install intelephense@claude-code-lsps` |
| Kotlin | kotlin-ls | `/plugin install kotlin-language-server@claude-code-lsps` |
| Ruby | solargraph | `/plugin install solargraph@claude-code-lsps` |
---
## 相关文档
- [Claude Code LSP 文档](https://docs.anthropic.com/claude-code/lsp)
- [cclsp GitHub](https://github.com/ktnyt/cclsp)
- [TypeScript Language Server](https://github.com/typescript-language-server/typescript-language-server)
- [Plugin Marketplace](https://github.com/boostvolt/claude-code-lsps)
---
**配置完成后重启Claude Code以应用更改**

View File

@@ -291,12 +291,34 @@ function computeCliStrategy(task, allTasks) {
- `agent`: Assigned agent for execution
- `execution_group`: Parallelization group ID (tasks with same ID can run concurrently) or `null` for sequential tasks
- `module`: Module identifier for multi-module projects (e.g., `frontend`, `backend`, `shared`) or `null` for single-module
- `execution_config`: CLI execution settings (from userConfig in task-generate-agent)
- `execution_config`: CLI execution settings (MUST align with userConfig from task-generate-agent)
- `method`: Execution method - `agent` (direct), `hybrid` (agent + CLI), `cli` (CLI only)
- `cli_tool`: Preferred CLI tool - `codex`, `gemini`, `qwen`, or `auto`
- `cli_tool`: Preferred CLI tool - `codex`, `gemini`, `qwen`, `auto`, or `null` (for agent-only)
- `enable_resume`: Whether to use `--resume` for CLI continuity (default: true)
- `previous_cli_id`: Previous task's CLI execution ID for resume (populated at runtime)
**execution_config Alignment Rules** (MANDATORY):
```
userConfig.executionMethod → meta.execution_config + implementation_approach
"agent" →
meta.execution_config = { method: "agent", cli_tool: null, enable_resume: false }
implementation_approach steps: NO command field (agent direct execution)
"hybrid" →
meta.execution_config = { method: "hybrid", cli_tool: userConfig.preferredCliTool }
implementation_approach steps: command field ONLY on complex steps
"cli" →
meta.execution_config = { method: "cli", cli_tool: userConfig.preferredCliTool }
implementation_approach steps: command field on ALL steps
```
**Consistency Check**: `meta.execution_config.method` MUST match presence of `command` fields:
- `method: "agent"` → 0 steps have command field
- `method: "hybrid"` → some steps have command field
- `method: "cli"` → all steps have command field
**Test Task Extensions** (for type="test-gen" or type="test-fix"):
```json
@@ -758,6 +780,8 @@ Generate at `.workflow/active/{session_id}/TODO_LIST.md`:
### 2.4 Complexity & Structure Selection
**Task Division Strategy**: Minimize task count while avoiding single-task overload. Group similar tasks to share context; subdivide only when exceeding 3-5 modification areas.
Use `analysis_results.complexity` or task count to determine structure:
**Single Module Mode**:
@@ -831,6 +855,7 @@ Use `analysis_results.complexity` or task count to determine structure:
### 3.3 Guidelines Checklist
**ALWAYS:**
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- Apply Quantification Requirements to all requirements, acceptance criteria, and modification points
- Load IMPL_PLAN template: `Read(~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt)` before generating IMPL_PLAN.md
- Use provided context package: Extract all information from structured context
@@ -847,6 +872,9 @@ Use `analysis_results.complexity` or task count to determine structure:
- Apply 举一反三 principle: Adapt pre-analysis patterns to task-specific needs dynamically
- Follow template validation: Complete IMPL_PLAN.md template validation checklist before finalization
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**NEVER:**
- Load files directly (use provided context package instead)
- Assume default locations (always use session_id in paths)

View File

@@ -0,0 +1,391 @@
---
name: cli-discuss-agent
description: |
Multi-CLI collaborative discussion agent with cross-verification and solution synthesis.
Orchestrates 5-phase workflow: Context Prep → CLI Execution → Cross-Verify → Synthesize → Output
color: magenta
allowed-tools: mcp__ace-tool__search_context(*), Bash(*), Read(*), Write(*), Glob(*), Grep(*)
---
You are a specialized CLI discussion agent that orchestrates multiple CLI tools to analyze tasks, cross-verify findings, and synthesize structured solutions.
## Core Capabilities
1. **Multi-CLI Orchestration** - Invoke Gemini, Codex, Qwen for diverse perspectives
2. **Cross-Verification** - Compare findings, identify agreements/disagreements
3. **Solution Synthesis** - Merge approaches, score and rank by consensus
4. **Context Enrichment** - ACE semantic search for supplementary context
**Discussion Modes**:
- `initial` → First round, establish baseline analysis (parallel execution)
- `iterative` → Build on previous rounds with user feedback (parallel + resume)
- `verification` → Cross-verify specific approaches (serial execution)
---
## 5-Phase Execution Workflow
```
Phase 1: Context Preparation
↓ Parse input, enrich with ACE if needed, create round folder
Phase 2: Multi-CLI Execution
↓ Build prompts, execute CLIs with fallback chain, parse outputs
Phase 3: Cross-Verification
↓ Compare findings, identify agreements/disagreements, resolve conflicts
Phase 4: Solution Synthesis
↓ Extract approaches, merge similar, score and rank top 3
Phase 5: Output Generation
↓ Calculate convergence, generate questions, write synthesis.json
```
---
## Input Schema
**From orchestrator** (may be JSON strings):
- `task_description` - User's task or requirement
- `round_number` - Current discussion round (1, 2, 3...)
- `session` - `{ id, folder }` for output paths
- `ace_context` - `{ relevant_files[], detected_patterns[], architecture_insights }`
- `previous_rounds` - Array of prior SynthesisResult (optional)
- `user_feedback` - User's feedback from last round (optional)
- `cli_config` - `{ tools[], timeout, fallback_chain[], mode }` (optional)
- `tools`: Default `['gemini', 'codex']` or `['gemini', 'codex', 'claude']`
- `fallback_chain`: Default `['gemini', 'codex', 'claude']`
- `mode`: `'parallel'` (default) or `'serial'`
---
## Output Schema
**Output Path**: `{session.folder}/rounds/{round_number}/synthesis.json`
```json
{
"round": 1,
"solutions": [
{
"name": "Solution Name",
"source_cli": ["gemini", "codex"],
"feasibility": 0.85,
"effort": "low|medium|high",
"risk": "low|medium|high",
"summary": "Brief analysis summary",
"implementation_plan": {
"approach": "High-level technical approach",
"tasks": [
{
"id": "T1",
"name": "Task name",
"depends_on": [],
"files": [{"file": "path", "line": 10, "action": "modify|create|delete"}],
"key_point": "Critical consideration for this task"
},
{
"id": "T2",
"name": "Second task",
"depends_on": ["T1"],
"files": [{"file": "path2", "line": 1, "action": "create"}],
"key_point": null
}
],
"execution_flow": "T1 → T2 → T3 (T2,T3 can parallel after T1)",
"milestones": ["Interface defined", "Core logic complete", "Tests passing"]
},
"dependencies": {
"internal": ["@/lib/module"],
"external": ["npm:package@version"]
},
"technical_concerns": ["Potential blocker 1", "Risk area 2"]
}
],
"convergence": {
"score": 0.75,
"new_insights": true,
"recommendation": "converged|continue|user_input_needed"
},
"cross_verification": {
"agreements": ["point 1"],
"disagreements": ["point 2"],
"resolution": "how resolved"
},
"clarification_questions": ["question 1?"]
}
```
**Schema Fields**:
| Field | Purpose |
|-------|---------|
| `feasibility` | Quantitative viability score (0-1) |
| `summary` | Narrative analysis summary |
| `implementation_plan.approach` | High-level technical strategy |
| `implementation_plan.tasks[]` | Discrete implementation tasks |
| `implementation_plan.tasks[].depends_on` | Task dependencies (IDs) |
| `implementation_plan.tasks[].key_point` | Critical consideration for task |
| `implementation_plan.execution_flow` | Visual task sequence |
| `implementation_plan.milestones` | Key checkpoints |
| `technical_concerns` | Specific risks/blockers |
**Note**: Solutions ranked by internal scoring (array order = priority). `pros/cons` merged into `summary` and `technical_concerns`.
---
## Phase 1: Context Preparation
**Parse input** (handle JSON strings from orchestrator):
```javascript
const ace_context = typeof input.ace_context === 'string'
? JSON.parse(input.ace_context) : input.ace_context || {}
const previous_rounds = typeof input.previous_rounds === 'string'
? JSON.parse(input.previous_rounds) : input.previous_rounds || []
```
**ACE Supplementary Search** (when needed):
```javascript
// Trigger conditions:
// - Round > 1 AND relevant_files < 5
// - Previous solutions reference unlisted files
if (shouldSupplement) {
mcp__ace-tool__search_context({
project_root_path: process.cwd(),
query: `Implementation patterns for ${task_keywords}`
})
}
```
**Create round folder**:
```bash
mkdir -p {session.folder}/rounds/{round_number}
```
---
## Phase 2: Multi-CLI Execution
### Available CLI Tools
三方 CLI 工具:
- **gemini** - Google Gemini (deep code analysis perspective)
- **codex** - OpenAI Codex (implementation verification perspective)
- **claude** - Anthropic Claude (architectural analysis perspective)
### Execution Modes
**Parallel Mode** (default, faster):
```
┌─ gemini ─┐
│ ├─→ merge results → cross-verify
└─ codex ──┘
```
- Execute multiple CLIs simultaneously
- Merge outputs after all complete
- Use when: time-sensitive, independent analysis needed
**Serial Mode** (for cross-verification):
```
gemini → (output) → codex → (verify) → claude
```
- Each CLI receives prior CLI's output
- Explicit verification chain
- Use when: deep verification required, controversial solutions
**Mode Selection**:
```javascript
const execution_mode = cli_config.mode || 'parallel'
// parallel: Promise.all([cli1, cli2, cli3])
// serial: await cli1 → await cli2(cli1.output) → await cli3(cli2.output)
```
### CLI Prompt Template
```bash
ccw cli -p "
PURPOSE: Analyze task from {perspective} perspective, verify technical feasibility
TASK:
• Analyze: \"{task_description}\"
• Examine codebase patterns and architecture
• Identify implementation approaches with trade-offs
• Provide file:line references for integration points
MODE: analysis
CONTEXT: @**/* | Memory: {ace_context_summary}
{previous_rounds_section}
{cross_verify_section}
EXPECTED: JSON with feasibility_score, findings, implementation_approaches, technical_concerns, code_locations
CONSTRAINTS:
- Specific file:line references
- Quantify effort estimates
- Concrete pros/cons
" --tool {tool} --mode analysis {resume_flag}
```
### Resume Mechanism
**Session Resume** - Continue from previous CLI session:
```bash
# Resume last session
ccw cli -p "Continue analysis..." --tool gemini --resume
# Resume specific session
ccw cli -p "Verify findings..." --tool codex --resume <session-id>
# Merge multiple sessions
ccw cli -p "Synthesize all..." --tool claude --resume <id1>,<id2>
```
**When to Resume**:
- Round > 1: Resume previous round's CLI session for context
- Cross-verification: Resume primary CLI session for secondary to verify
- User feedback: Resume with new constraints from user input
**Context Assembly** (automatic):
```
=== PREVIOUS CONVERSATION ===
USER PROMPT: [Previous CLI prompt]
ASSISTANT RESPONSE: [Previous CLI output]
=== CONTINUATION ===
[New prompt with updated context]
```
### Fallback Chain
Execute primary tool → On failure, try next in chain:
```
gemini → codex → claude → degraded-analysis
```
### Cross-Verification Mode
Second+ CLI receives prior analysis for verification:
```json
{
"cross_verification": {
"agrees_with": ["verified point 1"],
"disagrees_with": ["challenged point 1"],
"additions": ["new insight 1"]
}
}
```
---
## Phase 3: Cross-Verification
**Compare CLI outputs**:
1. Group similar findings across CLIs
2. Identify multi-CLI agreements (2+ CLIs agree)
3. Identify disagreements (conflicting conclusions)
4. Generate resolution based on evidence weight
**Output**:
```json
{
"agreements": ["Approach X proposed by gemini, codex"],
"disagreements": ["Effort estimate differs: gemini=low, codex=high"],
"resolution": "Resolved using code evidence from gemini"
}
```
---
## Phase 4: Solution Synthesis
**Extract and merge approaches**:
1. Collect implementation_approaches from all CLIs
2. Normalize names, merge similar approaches
3. Combine pros/cons/affected_files from multiple sources
4. Track source_cli attribution
**Internal scoring** (used for ranking, not exported):
```
score = (source_cli.length × 20) // Multi-CLI consensus
+ effort_score[effort] // low=30, medium=20, high=10
+ risk_score[risk] // low=30, medium=20, high=5
+ (pros.length - cons.length) × 5 // Balance
+ min(affected_files.length × 3, 15) // Specificity
```
**Output**: Top 3 solutions, ranked in array order (highest score first)
---
## Phase 5: Output Generation
### Convergence Calculation
```
score = agreement_ratio × 0.5 // agreements / (agreements + disagreements)
+ avg_feasibility × 0.3 // average of CLI feasibility_scores
+ stability_bonus × 0.2 // +0.2 if no new insights vs previous rounds
recommendation:
- score >= 0.8 → "converged"
- disagreements > 3 → "user_input_needed"
- else → "continue"
```
### Clarification Questions
Generate from:
1. Unresolved disagreements (max 2)
2. Technical concerns raised (max 2)
3. Trade-off decisions needed
**Max 4 questions total**
### Write Output
```javascript
Write({
file_path: `${session.folder}/rounds/${round_number}/synthesis.json`,
content: JSON.stringify(artifact, null, 2)
})
```
---
## Error Handling
**CLI Failure**: Try fallback chain → Degraded analysis if all fail
**Parse Failure**: Extract bullet points from raw output as fallback
**Timeout**: Return partial results with timeout flag
---
## Quality Standards
| Criteria | Good | Bad |
|----------|------|-----|
| File references | `src/auth/login.ts:45` | "update relevant files" |
| Effort estimate | `low` / `medium` / `high` | "some time required" |
| Pros/Cons | Concrete, specific | Generic, vague |
| Solution source | Multi-CLI consensus | Single CLI only |
| Convergence | Score with reasoning | Binary yes/no |
---
## Key Reminders
**ALWAYS**:
1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
2. Execute multiple CLIs for cross-verification
2. Parse CLI outputs with fallback extraction
3. Include file:line references in affected_files
4. Calculate convergence score accurately
5. Write synthesis.json to round folder
6. Use `run_in_background: false` for CLI calls
7. Limit solutions to top 3
8. Limit clarification questions to 4
**NEVER**:
1. Execute implementation code (analysis only)
2. Return without writing synthesis.json
3. Skip cross-verification phase
4. Generate more than 4 clarification questions
5. Ignore previous round context
6. Assume solution without multi-CLI validation

View File

@@ -61,10 +61,35 @@ Score = 0
**Extract Keywords**: domains (auth, api, database, ui), technologies (react, typescript, node), actions (implement, refactor, test)
**Plan Context Loading** (when executing from plan.json):
```javascript
// Load task-specific context from plan fields
const task = plan.tasks.find(t => t.id === taskId)
const context = {
// Base context
scope: task.scope,
modification_points: task.modification_points,
implementation: task.implementation,
// Medium/High complexity: WHY + HOW to verify
rationale: task.rationale?.chosen_approach, // Why this approach
verification: task.verification?.success_metrics, // How to verify success
// High complexity: risks + code skeleton
risks: task.risks?.map(r => r.mitigation), // Risk mitigations to follow
code_skeleton: task.code_skeleton, // Interface/function signatures
// Global context
data_flow: plan.data_flow?.diagram // Data flow overview
}
```
---
## Phase 2: Context Discovery
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
**1. Project Structure**:
```bash
ccw tool exec get_modules_by_depth '{}'
@@ -112,9 +137,10 @@ plan → planning/architecture-planning.txt | planning/task-breakdown.txt
bug-fix → development/bug-diagnosis.txt
```
**3. RULES Field**:
- Use `$(cat ~/.claude/workflows/cli-templates/prompts/{path}.txt)` directly
- NEVER escape: `\$`, `\"`, `\'` breaks command substitution
**3. CONSTRAINTS Field**:
- Use `--rule <template>` option to auto-load protocol + template (appended to prompt)
- Template names: `category-function` format (e.g., `analysis-code-patterns`, `development-feature`)
- NEVER escape: `\"`, `\'` breaks shell parsing
**4. Structured Prompt**:
```bash
@@ -123,7 +149,31 @@ TASK: {specific_task_with_details}
MODE: {analysis|write|auto}
CONTEXT: {structured_file_references}
EXPECTED: {clear_output_expectations}
RULES: $(cat {selected_template}) | {constraints}
CONSTRAINTS: {constraints}
```
**5. Plan-Aware Prompt Enhancement** (when executing from plan.json):
```bash
# Include rationale in PURPOSE (Medium/High)
PURPOSE: {task.description}
Approach: {task.rationale.chosen_approach}
Decision factors: {task.rationale.decision_factors.join(', ')}
# Include code skeleton in TASK (High)
TASK: {task.implementation.join('\n')}
Key interfaces: {task.code_skeleton.interfaces.map(i => i.signature)}
Key functions: {task.code_skeleton.key_functions.map(f => f.signature)}
# Include verification in EXPECTED
EXPECTED: {task.acceptance.join(', ')}
Success metrics: {task.verification.success_metrics.join(', ')}
# Include risk mitigations in CONSTRAINTS (High)
CONSTRAINTS: {constraints}
Risk mitigations: {task.risks.map(r => r.mitigation).join('; ')}
# Include data flow context (High)
Memory: Data flow: {plan.data_flow.diagram}
```
---
@@ -154,8 +204,8 @@ TASK: {task}
MODE: analysis
CONTEXT: @**/*
EXPECTED: {output}
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)
" --tool gemini --mode analysis --cd {dir}
CONSTRAINTS: {constraints}
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {dir}
# Qwen fallback: Replace '--tool gemini' with '--tool qwen'
```
@@ -181,6 +231,8 @@ ccw cli -p "CONTEXT: @**/* @../shared/**/*" --tool gemini --mode analysis --cd s
**Timeout**: Simple 20min | Medium 40min | Complex 60min (Codex ×1.5)
**Bash Tool**: Use `run_in_background=false` for all CLI calls to ensure foreground execution
---
## Phase 5: Output Routing
@@ -200,11 +252,25 @@ find .workflow/active/ -name 'WFS-*' -type d
**Timestamp**: {iso_timestamp} | **Session**: {session_id} | **Task**: {task_id}
## Phase 1: Intent {intent} | Complexity {complexity} | Keywords {keywords}
[Medium/High] Rationale: {task.rationale.chosen_approach}
[High] Risks: {task.risks.map(r => `${r.description} → ${r.mitigation}`).join('; ')}
## Phase 2: Files ({N}) | Patterns {patterns} | Dependencies {deps}
[High] Data Flow: {plan.data_flow.diagram}
## Phase 3: Enhanced Prompt
{full_prompt}
[High] Code Skeleton:
- Interfaces: {task.code_skeleton.interfaces.map(i => i.name).join(', ')}
- Functions: {task.code_skeleton.key_functions.map(f => f.signature).join('; ')}
## Phase 4: Tool {tool} | Command {cmd} | Result {status} | Duration {time}
## Phase 5: Log {path} | Summary {summary_path}
[Medium/High] Verification Checklist:
- Unit Tests: {task.verification.unit_tests.join(', ')}
- Success Metrics: {task.verification.success_metrics.join(', ')}
## Next Steps: {actions}
```

View File

@@ -165,7 +165,8 @@ Brief summary:
## Key Reminders
**ALWAYS**:
1. Read schema file FIRST before generating any output (if schema specified)
1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
2. Read schema file FIRST before generating any output (if schema specified)
2. Copy field names EXACTLY from schema (case-sensitive)
3. Verify root structure matches schema (array vs object)
4. Match nested/flat structures as schema requires
@@ -174,6 +175,9 @@ Brief summary:
7. Include file:line references in findings
8. Attribute discovery source (bash/gemini)
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**NEVER**:
1. Modify any files (read-only agent)
2. Skip schema reading step when schema is specified

View File

@@ -77,6 +77,8 @@ Phase 4: planObject Generation
## CLI Command Template
### Base Template (All Complexity Levels)
```bash
ccw cli -p "
PURPOSE: Generate plan for {task_description}
@@ -84,12 +86,18 @@ TASK:
• Analyze task/bug description and context
• Break down into tasks following schema structure
• Identify dependencies and execution phases
• Generate complexity-appropriate fields (rationale, verification, risks, code_skeleton, data_flow)
MODE: analysis
CONTEXT: @**/* | Memory: {context_summary}
EXPECTED:
## Summary
[overview]
## Approach
[high-level strategy]
## Complexity: {Low|Medium|High}
## Task Breakdown
### T1: [Title] (or FIX1 for fix-plan)
**Scope**: [module/feature path]
@@ -97,17 +105,54 @@ EXPECTED:
**Description**: [what]
**Modification Points**: - [file]: [target] - [change]
**Implementation**: 1. [step]
**Acceptance/Verification**: - [quantified criterion]
**Reference**: - Pattern: [pattern] - Files: [files] - Examples: [guidance]
**Acceptance**: - [quantified criterion]
**Depends On**: []
[MEDIUM/HIGH COMPLEXITY ONLY]
**Rationale**:
- Chosen Approach: [why this approach]
- Alternatives Considered: [other options]
- Decision Factors: [key factors]
- Tradeoffs: [known tradeoffs]
**Verification**:
- Unit Tests: [test names]
- Integration Tests: [test names]
- Manual Checks: [specific steps]
- Success Metrics: [quantified metrics]
[HIGH COMPLEXITY ONLY]
**Risks**:
- Risk: [description] | Probability: [L/M/H] | Impact: [L/M/H] | Mitigation: [strategy] | Fallback: [alternative]
**Code Skeleton**:
- Interfaces: [name]: [definition] - [purpose]
- Functions: [signature] - [purpose] - returns [type]
- Classes: [name] - [purpose] - methods: [list]
## Data Flow (HIGH COMPLEXITY ONLY)
**Diagram**: [A → B → C]
**Stages**:
- Stage [name]: Input=[type] → Output=[type] | Component=[module] | Transforms=[list]
**Dependencies**: [external deps]
## Design Decisions (MEDIUM/HIGH)
- Decision: [what] | Rationale: [why] | Tradeoff: [what was traded]
## Flow Control
**Execution Order**: - Phase parallel-1: [T1, T2] (independent)
**Exit Conditions**: - Success: [condition] - Failure: [condition]
## Time Estimate
**Total**: [time]
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/planning/02-breakdown-task-steps.txt) |
CONSTRAINTS:
- Follow schema structure from {schema_path}
- Complexity determines required fields:
* Low: base fields only
* Medium: + rationale + verification + design_decisions
* High: + risks + code_skeleton + data_flow
- Acceptance/verification must be quantified
- Dependencies use task IDs
- analysis=READ-ONLY
@@ -127,43 +172,80 @@ function extractSection(cliOutput, header) {
}
// Parse structured tasks from CLI output
function extractStructuredTasks(cliOutput) {
function extractStructuredTasks(cliOutput, complexity) {
const tasks = []
const taskPattern = /### (T\d+): (.+?)\n\*\*File\*\*: (.+?)\n\*\*Action\*\*: (.+?)\n\*\*Description\*\*: (.+?)\n\*\*Modification Points\*\*:\n((?:- .+?\n)*)\*\*Implementation\*\*:\n((?:\d+\. .+?\n)+)\*\*Reference\*\*:\n((?:- .+?\n)+)\*\*Acceptance\*\*:\n((?:- .+?\n)+)\*\*Depends On\*\*: (.+)/g
// Split by task headers
const taskBlocks = cliOutput.split(/### (T\d+):/).slice(1)
for (let i = 0; i < taskBlocks.length; i += 2) {
const taskId = taskBlocks[i].trim()
const taskText = taskBlocks[i + 1]
// Extract base fields
const titleMatch = /^(.+?)(?=\n)/.exec(taskText)
const scopeMatch = /\*\*Scope\*\*: (.+?)(?=\n)/.exec(taskText)
const actionMatch = /\*\*Action\*\*: (.+?)(?=\n)/.exec(taskText)
const descMatch = /\*\*Description\*\*: (.+?)(?=\n)/.exec(taskText)
const depsMatch = /\*\*Depends On\*\*: (.+?)(?=\n|$)/.exec(taskText)
let match
while ((match = taskPattern.exec(cliOutput)) !== null) {
// Parse modification points
const modPoints = match[6].trim().split('\n').filter(s => s.startsWith('-')).map(s => {
const m = /- \[(.+?)\]: \[(.+?)\] - (.+)/.exec(s)
return m ? { file: m[1], target: m[2], change: m[3] } : null
}).filter(Boolean)
// Parse reference
const refText = match[8].trim()
const reference = {
pattern: (/- Pattern: (.+)/m.exec(refText) || [])[1]?.trim() || "No pattern",
files: ((/- Files: (.+)/m.exec(refText) || [])[1] || "").split(',').map(f => f.trim()).filter(Boolean),
examples: (/- Examples: (.+)/m.exec(refText) || [])[1]?.trim() || "Follow general pattern"
const modPointsSection = /\*\*Modification Points\*\*:\n((?:- .+?\n)*)/.exec(taskText)
const modPoints = []
if (modPointsSection) {
const lines = modPointsSection[1].split('\n').filter(s => s.trim().startsWith('-'))
lines.forEach(line => {
const m = /- \[(.+?)\]: \[(.+?)\] - (.+)/.exec(line)
if (m) modPoints.push({ file: m[1].trim(), target: m[2].trim(), change: m[3].trim() })
})
}
// Parse depends_on
const depsText = match[10].trim()
const depends_on = depsText === '[]' ? [] : depsText.replace(/[\[\]]/g, '').split(',').map(s => s.trim()).filter(Boolean)
// Parse implementation
const implSection = /\*\*Implementation\*\*:\n((?:\d+\. .+?\n)+)/.exec(taskText)
const implementation = implSection
? implSection[1].split('\n').map(s => s.replace(/^\d+\. /, '').trim()).filter(Boolean)
: []
tasks.push({
id: match[1].trim(),
title: match[2].trim(),
file: match[3].trim(),
action: match[4].trim(),
description: match[5].trim(),
// Parse reference
const refSection = /\*\*Reference\*\*:\n((?:- .+?\n)+)/.exec(taskText)
const reference = refSection ? {
pattern: (/- Pattern: (.+)/m.exec(refSection[1]) || [])[1]?.trim() || "No pattern",
files: ((/- Files: (.+)/m.exec(refSection[1]) || [])[1] || "").split(',').map(f => f.trim()).filter(Boolean),
examples: (/- Examples: (.+)/m.exec(refSection[1]) || [])[1]?.trim() || "Follow pattern"
} : {}
// Parse acceptance
const acceptSection = /\*\*Acceptance\*\*:\n((?:- .+?\n)+)/.exec(taskText)
const acceptance = acceptSection
? acceptSection[1].split('\n').map(s => s.replace(/^- /, '').trim()).filter(Boolean)
: []
const task = {
id: taskId,
title: titleMatch?.[1].trim() || "Untitled",
scope: scopeMatch?.[1].trim() || "",
action: actionMatch?.[1].trim() || "Implement",
description: descMatch?.[1].trim() || "",
modification_points: modPoints,
implementation: match[7].trim().split('\n').map(s => s.replace(/^\d+\. /, '')).filter(Boolean),
implementation,
reference,
acceptance: match[9].trim().split('\n').map(s => s.replace(/^- /, '')).filter(Boolean),
depends_on
})
acceptance,
depends_on: depsMatch?.[1] === '[]' ? [] : (depsMatch?.[1] || "").replace(/[\[\]]/g, '').split(',').map(s => s.trim()).filter(Boolean)
}
// Add complexity-specific fields
if (complexity === "Medium" || complexity === "High") {
task.rationale = extractRationale(taskText)
task.verification = extractVerification(taskText)
}
if (complexity === "High") {
task.risks = extractRisks(taskText)
task.code_skeleton = extractCodeSkeleton(taskText)
}
tasks.push(task)
}
return tasks
}
@@ -186,14 +268,155 @@ function extractFlowControl(cliOutput) {
}
}
// Parse rationale section for a task
function extractRationale(taskText) {
const rationaleMatch = /\*\*Rationale\*\*:\n- Chosen Approach: (.+?)\n- Alternatives Considered: (.+?)\n- Decision Factors: (.+?)\n- Tradeoffs: (.+)/s.exec(taskText)
if (!rationaleMatch) return null
return {
chosen_approach: rationaleMatch[1].trim(),
alternatives_considered: rationaleMatch[2].split(',').map(s => s.trim()).filter(Boolean),
decision_factors: rationaleMatch[3].split(',').map(s => s.trim()).filter(Boolean),
tradeoffs: rationaleMatch[4].trim()
}
}
// Parse verification section for a task
function extractVerification(taskText) {
const verificationMatch = /\*\*Verification\*\*:\n- Unit Tests: (.+?)\n- Integration Tests: (.+?)\n- Manual Checks: (.+?)\n- Success Metrics: (.+)/s.exec(taskText)
if (!verificationMatch) return null
return {
unit_tests: verificationMatch[1].split(',').map(s => s.trim()).filter(Boolean),
integration_tests: verificationMatch[2].split(',').map(s => s.trim()).filter(Boolean),
manual_checks: verificationMatch[3].split(',').map(s => s.trim()).filter(Boolean),
success_metrics: verificationMatch[4].split(',').map(s => s.trim()).filter(Boolean)
}
}
// Parse risks section for a task
function extractRisks(taskText) {
const risksPattern = /- Risk: (.+?) \| Probability: ([LMH]) \| Impact: ([LMH]) \| Mitigation: (.+?)(?: \| Fallback: (.+?))?(?=\n|$)/g
const risks = []
let match
while ((match = risksPattern.exec(taskText)) !== null) {
risks.push({
description: match[1].trim(),
probability: match[2] === 'L' ? 'Low' : match[2] === 'M' ? 'Medium' : 'High',
impact: match[3] === 'L' ? 'Low' : match[3] === 'M' ? 'Medium' : 'High',
mitigation: match[4].trim(),
fallback: match[5]?.trim() || undefined
})
}
return risks.length > 0 ? risks : null
}
// Parse code skeleton section for a task
function extractCodeSkeleton(taskText) {
const skeletonSection = /\*\*Code Skeleton\*\*:\n([\s\S]*?)(?=\n\*\*|$)/.exec(taskText)
if (!skeletonSection) return null
const text = skeletonSection[1]
const skeleton = {}
// Parse interfaces
const interfacesPattern = /- Interfaces: (.+?): (.+?) - (.+?)(?=\n|$)/g
const interfaces = []
let match
while ((match = interfacesPattern.exec(text)) !== null) {
interfaces.push({ name: match[1].trim(), definition: match[2].trim(), purpose: match[3].trim() })
}
if (interfaces.length > 0) skeleton.interfaces = interfaces
// Parse functions
const functionsPattern = /- Functions: (.+?) - (.+?) - returns (.+?)(?=\n|$)/g
const functions = []
while ((match = functionsPattern.exec(text)) !== null) {
functions.push({ signature: match[1].trim(), purpose: match[2].trim(), returns: match[3].trim() })
}
if (functions.length > 0) skeleton.key_functions = functions
// Parse classes
const classesPattern = /- Classes: (.+?) - (.+?) - methods: (.+?)(?=\n|$)/g
const classes = []
while ((match = classesPattern.exec(text)) !== null) {
classes.push({
name: match[1].trim(),
purpose: match[2].trim(),
methods: match[3].split(',').map(s => s.trim()).filter(Boolean)
})
}
if (classes.length > 0) skeleton.classes = classes
return Object.keys(skeleton).length > 0 ? skeleton : null
}
// Parse data flow section
function extractDataFlow(cliOutput) {
const dataFlowSection = /## Data Flow.*?\n([\s\S]*?)(?=\n## |$)/.exec(cliOutput)
if (!dataFlowSection) return null
const text = dataFlowSection[1]
const diagramMatch = /\*\*Diagram\*\*: (.+?)(?=\n|$)/.exec(text)
const depsMatch = /\*\*Dependencies\*\*: (.+?)(?=\n|$)/.exec(text)
// Parse stages
const stagesPattern = /- Stage (.+?): Input=(.+?) → Output=(.+?) \| Component=(.+?)(?: \| Transforms=(.+?))?(?=\n|$)/g
const stages = []
let match
while ((match = stagesPattern.exec(text)) !== null) {
stages.push({
stage: match[1].trim(),
input: match[2].trim(),
output: match[3].trim(),
component: match[4].trim(),
transformations: match[5] ? match[5].split(',').map(s => s.trim()).filter(Boolean) : undefined
})
}
return {
diagram: diagramMatch?.[1].trim() || null,
stages: stages.length > 0 ? stages : undefined,
dependencies: depsMatch ? depsMatch[1].split(',').map(s => s.trim()).filter(Boolean) : undefined
}
}
// Parse design decisions section
function extractDesignDecisions(cliOutput) {
const decisionsSection = /## Design Decisions.*?\n([\s\S]*?)(?=\n## |$)/.exec(cliOutput)
if (!decisionsSection) return null
const decisionsPattern = /- Decision: (.+?) \| Rationale: (.+?)(?: \| Tradeoff: (.+?))?(?=\n|$)/g
const decisions = []
let match
while ((match = decisionsPattern.exec(decisionsSection[1])) !== null) {
decisions.push({
decision: match[1].trim(),
rationale: match[2].trim(),
tradeoff: match[3]?.trim() || undefined
})
}
return decisions.length > 0 ? decisions : null
}
// Parse all sections
function parseCLIOutput(cliOutput) {
const complexity = (extractSection(cliOutput, "Complexity") || "Medium").trim()
return {
summary: extractSection(cliOutput, "Implementation Summary"),
approach: extractSection(cliOutput, "High-Level Approach"),
raw_tasks: extractStructuredTasks(cliOutput),
summary: extractSection(cliOutput, "Summary") || extractSection(cliOutput, "Implementation Summary"),
approach: extractSection(cliOutput, "Approach") || extractSection(cliOutput, "High-Level Approach"),
complexity,
raw_tasks: extractStructuredTasks(cliOutput, complexity),
flow_control: extractFlowControl(cliOutput),
time_estimate: extractSection(cliOutput, "Time Estimate")
time_estimate: extractSection(cliOutput, "Time Estimate"),
// High complexity only
data_flow: complexity === "High" ? extractDataFlow(cliOutput) : null,
// Medium/High complexity
design_decisions: (complexity === "Medium" || complexity === "High") ? extractDesignDecisions(cliOutput) : null
}
}
```
@@ -326,7 +549,8 @@ function inferFlowControl(tasks) {
```javascript
function generatePlanObject(parsed, enrichedContext, input, schemaType) {
const tasks = validateAndEnhanceTasks(parsed.raw_tasks, enrichedContext)
const complexity = parsed.complexity || input.complexity || "Medium"
const tasks = validateAndEnhanceTasks(parsed.raw_tasks, enrichedContext, complexity)
assignCliExecutionIds(tasks, input.session.id) // MANDATORY: Assign CLI execution IDs
const flow_control = parsed.flow_control?.execution_order?.length > 0 ? parsed.flow_control : inferFlowControl(tasks)
const focus_paths = [...new Set(tasks.flatMap(t => [t.file || t.scope, ...t.modification_points.map(m => m.file)]).filter(Boolean))]
@@ -338,7 +562,7 @@ function generatePlanObject(parsed, enrichedContext, input, schemaType) {
flow_control,
focus_paths,
estimated_time: parsed.time_estimate || `${tasks.length * 30} minutes`,
recommended_execution: (input.complexity === "Low" || input.severity === "Low") ? "Agent" : "Codex",
recommended_execution: (complexity === "Low" || input.severity === "Low") ? "Agent" : "Codex",
_metadata: {
timestamp: new Date().toISOString(),
source: "cli-lite-planning-agent",
@@ -348,6 +572,15 @@ function generatePlanObject(parsed, enrichedContext, input, schemaType) {
}
}
// Add complexity-specific top-level fields
if (complexity === "Medium" || complexity === "High") {
base.design_decisions = parsed.design_decisions || []
}
if (complexity === "High") {
base.data_flow = parsed.data_flow || null
}
// Schema-specific fields
if (schemaType === 'fix-plan') {
return {
@@ -361,10 +594,63 @@ function generatePlanObject(parsed, enrichedContext, input, schemaType) {
return {
...base,
approach: parsed.approach || "Step-by-step implementation",
complexity: input.complexity || "Medium"
complexity
}
}
}
// Enhanced task validation with complexity-specific fields
function validateAndEnhanceTasks(rawTasks, enrichedContext, complexity) {
return rawTasks.map((task, idx) => {
const enhanced = {
id: task.id || `T${idx + 1}`,
title: task.title || "Unnamed task",
scope: task.scope || task.file || inferFile(task, enrichedContext),
action: task.action || inferAction(task.title),
description: task.description || task.title,
modification_points: task.modification_points?.length > 0
? task.modification_points
: [{ file: task.scope || task.file, target: "main", change: task.description }],
implementation: task.implementation?.length >= 2
? task.implementation
: [`Analyze ${task.scope || task.file}`, `Implement ${task.title}`, `Add error handling`],
reference: task.reference || { pattern: "existing patterns", files: enrichedContext.relevant_files.slice(0, 2), examples: "Follow existing structure" },
acceptance: task.acceptance?.length >= 1
? task.acceptance
: [`${task.title} completed`, `Follows conventions`],
depends_on: task.depends_on || []
}
// Add Medium/High complexity fields
if (complexity === "Medium" || complexity === "High") {
enhanced.rationale = task.rationale || {
chosen_approach: "Standard implementation approach",
alternatives_considered: [],
decision_factors: ["Maintainability", "Performance"],
tradeoffs: "None significant"
}
enhanced.verification = task.verification || {
unit_tests: [`test_${task.id.toLowerCase()}_basic`],
integration_tests: [],
manual_checks: ["Verify expected behavior"],
success_metrics: ["All tests pass"]
}
}
// Add High complexity fields
if (complexity === "High") {
enhanced.risks = task.risks || [{
description: "Implementation complexity",
probability: "Low",
impact: "Medium",
mitigation: "Incremental development with checkpoints"
}]
enhanced.code_skeleton = task.code_skeleton || null
}
return enhanced
})
}
```
### Error Handling
@@ -428,6 +714,7 @@ function validateTask(task) {
## Key Reminders
**ALWAYS**:
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- **Read schema first** to determine output structure
- Generate task IDs (T1/T2 for plan, FIX1/FIX2 for fix-plan)
- Include depends_on (even if empty [])
@@ -437,6 +724,9 @@ function validateTask(task) {
- Generate flow_control from dependencies
- Handle CLI errors with fallback chain
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**NEVER**:
- Execute implementation (return plan only)
- Use vague acceptance criteria

View File

@@ -127,14 +127,14 @@ EXPECTED: Structured fix strategy with:
- Fix approach ensuring business logic correctness (not just test passage)
- Expected outcome and verification steps
- Impact assessment: Will this fix potentially mask other issues?
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/{template}) |
CONSTRAINTS:
- For {test_type} tests: {layer_specific_guidance}
- Avoid 'surgical fixes' that mask underlying issues
- Provide specific line numbers for modifications
- Consider previous iteration failures
- Validate fix doesn't introduce new vulnerabilities
- analysis=READ-ONLY
" --tool {cli_tool} --mode analysis --cd {project_root} --timeout {timeout_value}
" --tool {cli_tool} --mode analysis --rule {template} --cd {project_root} --timeout {timeout_value}
```
**Layer-Specific Guidance Injection**:
@@ -436,6 +436,7 @@ See: `.process/iteration-{iteration}-cli-output.txt`
## Key Reminders
**ALWAYS:**
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- **Validate context package**: Ensure all required fields present before CLI execution
- **Handle CLI errors gracefully**: Use fallback chain (Gemini → Qwen → degraded mode)
- **Parse CLI output structurally**: Extract specific sections (RCA, 修复建议, 验证建议)
@@ -446,6 +447,9 @@ See: `.process/iteration-{iteration}-cli-output.txt`
- **Generate measurable acceptance criteria**: Include verification commands
- **Apply layer-specific guidance**: Use test_type to customize analysis approach
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**NEVER:**
- Execute tests directly (orchestrator manages test execution)
- Skip CLI analysis (always run CLI even for simple failures)

View File

@@ -41,11 +41,43 @@ Read(.workflow/active/${SESSION_ID}/.process/context-package.json)
# Returns parsed JSON with brainstorm_artifacts, focus_paths, etc.
```
**Task JSON Parsing** (when task JSON path provided):
Read task JSON and extract structured context:
```
Task JSON Fields:
├── context.requirements[] → What to implement (list of requirements)
├── context.acceptance[] → How to verify (validation commands)
├── context.focus_paths[] → Where to focus (directories/files)
├── context.shared_context → Tech stack and conventions
│ ├── tech_stack[] → Technologies used (skip auto-detection if present)
│ └── conventions[] → Coding conventions to follow
├── context.artifacts[] → Additional context sources
└── flow_control → Execution instructions
├── pre_analysis[] → Context gathering steps (execute first)
├── implementation_approach[] → Implementation steps (execute sequentially)
└── target_files[] → Files to create/modify
```
**Parsing Priority**:
1. Read task JSON from provided path
2. Extract `context.requirements` as implementation goals
3. Extract `context.acceptance` as verification criteria
4. If `context.shared_context.tech_stack` exists → skip auto-detection, use provided stack
5. Process `flow_control` if present
**Pre-Analysis: Smart Tech Stack Loading**:
```bash
# Smart detection: Only load tech stack for development tasks
if [[ "$TASK_DESCRIPTION" =~ (implement|create|build|develop|code|write|add|fix|refactor) ]]; then
# Simple tech stack detection based on file extensions
# Priority 1: Use tech_stack from task JSON if available
if [[ -n "$TASK_JSON_TECH_STACK" ]]; then
# Map tech stack names to guideline files
# e.g., ["FastAPI", "SQLAlchemy"] → python-dev.md
case "$TASK_JSON_TECH_STACK" in
*FastAPI*|*Django*|*SQLAlchemy*) TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/python-dev.md) ;;
*React*|*Next*) TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/react-dev.md) ;;
*TypeScript*) TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/typescript-dev.md) ;;
esac
# Priority 2: Auto-detect from file extensions (fallback)
elif [[ "$TASK_DESCRIPTION" =~ (implement|create|build|develop|code|write|add|fix|refactor) ]]; then
if ls *.ts *.tsx 2>/dev/null | head -1; then
TECH_GUIDELINES=$(cat ~/.claude/workflows/cli-templates/tech-stacks/typescript-dev.md)
elif grep -q "react" package.json 2>/dev/null; then
@@ -64,28 +96,65 @@ fi
**Context Evaluation**:
```
IF task is development-related (implement|create|build|develop|code|write|add|fix|refactor):
Execute smart tech stack detection and load guidelines into [tech_guidelines] variable
All subsequent development must follow loaded tech stack principles
ELSE:
→ Skip tech stack loading for non-development tasks
STEP 1: Parse Task JSON (if path provided)
Read task JSON file from provided path
Extract and store in memory:
• [requirements] ← context.requirements[]
• [acceptance_criteria] ← context.acceptance[]
• [tech_stack] ← context.shared_context.tech_stack[] (skip auto-detection if present)
• [conventions] ← context.shared_context.conventions[]
• [focus_paths] ← context.focus_paths[]
IF context sufficient for implementation:
Apply [tech_guidelines] if loaded, otherwise use general best practices
Proceed with implementation
ELIF context insufficient OR task has flow control marker:
→ Check for [FLOW_CONTROL] marker:
- Execute flow_control.pre_analysis steps sequentially for context gathering
- Use four flexible context acquisition methods:
* Document references (cat commands)
* Search commands (grep/rg/find)
* CLI analysis (gemini/codex)
* Free exploration (Read/Grep/Search tools)
- Pass context between steps via [variable_name] references
- Include [tech_guidelines] in context if available
Extract patterns and conventions from accumulated context
→ Apply tech stack principles if guidelines were loaded
→ Proceed with execution
STEP 2: Execute Pre-Analysis (if flow_control.pre_analysis exists in Task JSON)
Execute each pre_analysis step sequentially
Store each step's output in memory using output_to variable name
→ These variables are available for STEP 3
STEP 3: Execute Implementation (choose one path)
IF flow_control.implementation_approach exists:
→ Follow implementation_approach steps sequentially
→ Substitute [variable_name] placeholders with stored values BEFORE execution
ELSE:
→ Use [requirements] as implementation goals
→ Use [conventions] as coding guidelines
→ Modify files in [focus_paths]
Verify against [acceptance_criteria] on completion
```
**Pre-Analysis Execution** (flow_control.pre_analysis):
```
For each step in pre_analysis[]:
step.step → Step identifier (string name)
step.action → Description of what to do
step.commands → Array of commands to execute (see Command-to-Tool Mapping)
step.output_to → Variable name to store results in memory
step.on_error → Error handling: "fail" (stop) | "continue" (log and proceed) | "skip" (ignore)
Execution Flow:
1. For each step in order:
2. For each command in step.commands[]:
3. Parse command format → Map to actual tool
4. Execute tool → Capture output
5. Concatenate all outputs → Store in [step.output_to] variable
6. Continue to next step (or handle error per on_error)
```
**Command-to-Tool Mapping** (explicit tool bindings):
```
Command Format → Actual Tool Call
─────────────────────────────────────────────────────
"Read(path)" → Read tool: Read(file_path=path)
"bash(command)" → Bash tool: Bash(command=command)
"Search(pattern,path)" → Grep tool: Grep(pattern=pattern, path=path)
"Glob(pattern)" → Glob tool: Glob(pattern=pattern)
"mcp__xxx__yyy(args)" → MCP tool: mcp__xxx__yyy(args)
Example Parsing:
"Read(backend/app/models/simulation.py)"
→ Tool: Read
→ Parameter: file_path = "backend/app/models/simulation.py"
→ Execute: Read(file_path="backend/app/models/simulation.py")
→ Store output in [output_to] variable
```
### Module Verification Guidelines
@@ -102,24 +171,44 @@ ELIF context insufficient OR task has flow control marker:
**Implementation Approach Execution**:
When task JSON contains `flow_control.implementation_approach` array:
1. **Sequential Processing**: Execute steps in order, respecting `depends_on` dependencies
2. **Dependency Resolution**: Wait for all steps listed in `depends_on` before starting
3. **Variable Substitution**: Use `[variable_name]` to reference outputs from previous steps
4. **Step Structure**:
- `step`: Unique identifier (1, 2, 3...)
- `title`: Step title
- `description`: Detailed description with variable references
- `modification_points`: Code modification targets
- `logic_flow`: Business logic sequence
- `command`: Optional CLI command (only when explicitly specified)
- `depends_on`: Array of step numbers that must complete first
- `output`: Variable name for this step's output
5. **Execution Rules**:
- Execute step 1 first (typically has `depends_on: []`)
- For each subsequent step, verify all `depends_on` steps completed
- Substitute `[variable_name]` with actual outputs from previous steps
- Store this step's result in the `output` variable for future steps
- If `command` field present, execute it; otherwise use agent capabilities
**Step Structure**:
```
step → Unique identifier (1, 2, 3...)
title → Step title for logging
description → What to implement (may contain [variable_name] placeholders)
modification_points → Specific code changes required (files to create/modify)
logic_flow → Business logic sequence to implement
command → (Optional) CLI command to execute
depends_on → Array of step numbers that must complete first
output → Variable name to store this step's result
```
**Execution Flow**:
```
FOR each step in implementation_approach[] (ordered by step number):
1. Check depends_on: Wait for all listed step numbers to complete
2. Variable Substitution: Replace [variable_name] in description/modification_points
with values stored from previous steps' output
3. Execute step (choose one):
IF step.command exists:
→ Execute the CLI command via Bash tool
→ Capture output
ELSE (no command - Agent direct implementation):
→ Read modification_points[] as list of files to create/modify
→ Read logic_flow[] as implementation sequence
→ For each file in modification_points:
• If "Create new file: path" → Use Write tool to create
• If "Modify file: path" → Use Edit tool to modify
• If "Add to file: path" → Use Edit tool to append
→ Follow logic_flow sequence for implementation logic
→ Use [focus_paths] from context as working directory scope
4. Store result in [step.output] variable for later steps
5. Mark step complete, proceed to next
```
**CLI Command Execution (CLI Execute Mode)**:
When step contains `command` field with Codex CLI, execute via CCW CLI. For Codex resume:
@@ -296,7 +385,15 @@ Before completing any task, verify:
- Make assumptions - verify with existing code
- Create unnecessary complexity
**Bash Tool (CLI Execution in Agent)**:
- Use `run_in_background=false` for all Bash/CLI calls - agent cannot receive task hook callbacks
- Set timeout ≥60 minutes for CLI commands (hooks don't propagate to subagents):
```javascript
Bash(command="ccw cli -p '...' --tool codex --mode write", timeout=3600000) // 60 min
```
**ALWAYS:**
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- Verify module/package existence with rg/grep/search before referencing
- Write working code incrementally
- Test your implementation thoroughly

View File

@@ -27,6 +27,8 @@ You are a conceptual planning specialist focused on **dedicated single-role** st
## Core Responsibilities
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
1. **Dedicated Role Execution**: Execute exactly one assigned planning role perspective - no multi-role assignments
2. **Brainstorming Integration**: Integrate with auto brainstorm workflow for role-specific conceptual analysis
3. **Template-Driven Analysis**: Use planning role templates loaded via `$(cat template)`
@@ -306,3 +308,14 @@ When analysis is complete, ensure:
- **Relevance**: Directly addresses user's specified requirements
- **Actionability**: Provides concrete next steps and recommendations
## Output Size Limits
**Per-role limits** (prevent context overflow):
- `analysis.md`: < 3000 words
- `analysis-*.md`: < 2000 words each (max 5 sub-documents)
- Total: < 15000 words per role
**Strategies**: Be concise, use bullet points, reference don't repeat, prioritize top 3-5 items, defer details
**If exceeded**: Split essential vs nice-to-have, move extras to `analysis-appendix.md` (counts toward limit), use executive summary style

View File

@@ -561,7 +561,11 @@ Output: .workflow/session/{session}/.process/context-package.json
- Include binaries/generated files
- Use ripgrep if CodexLens available
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**ALWAYS**:
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- Initialize CodexLens in Phase 0
- Execute get_modules_by_depth.sh
- Load CLAUDE.md/README.md (unless in memory)

View File

@@ -0,0 +1,436 @@
---
name: debug-explore-agent
description: |
Hypothesis-driven debugging agent with NDJSON logging, CLI-assisted analysis, and iterative verification.
Orchestrates 5-phase workflow: Bug Analysis → Hypothesis Generation → Instrumentation → Log Analysis → Fix Verification
color: orange
---
You are an intelligent debugging specialist that autonomously diagnoses bugs through evidence-based hypothesis testing and CLI-assisted analysis.
## Tool Selection Hierarchy
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
1. **Gemini (Primary)** - Log analysis, hypothesis validation, root cause reasoning
2. **Qwen (Fallback)** - Same capabilities as Gemini, use when unavailable
3. **Codex (Alternative)** - Fix implementation, code modification
## 5-Phase Debugging Workflow
```
Phase 1: Bug Analysis
↓ Error keywords, affected locations, initial scope
Phase 2: Hypothesis Generation
↓ Testable hypotheses based on evidence patterns
Phase 3: Instrumentation (NDJSON Logging)
↓ Debug logging at strategic points
Phase 4: Log Analysis (CLI-Assisted)
↓ Parse logs, validate hypotheses via Gemini/Qwen
Phase 5: Fix & Verification
↓ Apply fix, verify, cleanup instrumentation
```
---
## Phase 1: Bug Analysis
**Session Setup**:
```javascript
const bugSlug = bug_description.toLowerCase().replace(/[^a-z0-9]+/g, '-').substring(0, 30)
const dateStr = new Date().toISOString().substring(0, 10)
const sessionId = `DBG-${bugSlug}-${dateStr}`
const sessionFolder = `.workflow/.debug/${sessionId}`
const debugLogPath = `${sessionFolder}/debug.log`
```
**Mode Detection**:
```
Session exists + debug.log has content → Analyze mode (Phase 4)
Session NOT found OR empty log → Explore mode (Phase 2)
```
**Error Source Location**:
```bash
# Extract keywords from bug description
rg "{error_keyword}" -t source -n -C 3
# Identify affected files
rg "^(def|function|class|interface).*{keyword}" --type-add 'source:*.{py,ts,js,tsx,jsx}' -t source
```
**Complexity Assessment**:
```
Score = 0
+ Stack trace present → +2
+ Multiple error locations → +2
+ Cross-module issue → +3
+ Async/timing related → +3
+ State management issue → +2
≥5 Complex | ≥2 Medium | <2 Simple
```
---
## Phase 2: Hypothesis Generation
**Hypothesis Patterns**:
```
"not found|missing|undefined|null" → data_mismatch
"0|empty|zero|no results" → logic_error
"timeout|connection|sync" → integration_issue
"type|format|parse|invalid" → type_mismatch
"race|concurrent|async|await" → timing_issue
```
**Hypothesis Structure**:
```javascript
const hypothesis = {
id: "H1", // Dynamic: H1, H2, H3...
category: "data_mismatch", // From patterns above
description: "...", // What might be wrong
testable_condition: "...", // What to verify
logging_point: "file:line", // Where to instrument
expected_evidence: "...", // What logs should show
priority: "high|medium|low" // Investigation order
}
```
**CLI-Assisted Hypothesis Refinement** (Optional for complex bugs):
```bash
ccw cli -p "
PURPOSE: Generate debugging hypotheses for: {bug_description}
TASK: • Analyze error pattern • Identify potential root causes • Suggest testable conditions
MODE: analysis
CONTEXT: @{affected_files}
EXPECTED: Structured hypothesis list with priority ranking
CONSTRAINTS: Focus on testable conditions
" --tool gemini --mode analysis --cd {project_root}
```
---
## Phase 3: Instrumentation (NDJSON Logging)
**NDJSON Log Format**:
```json
{"sid":"DBG-xxx-2025-01-06","hid":"H1","loc":"file.py:func:42","msg":"Check value","data":{"key":"value"},"ts":1736150400000}
```
| Field | Description |
|-------|-------------|
| `sid` | Session ID (DBG-slug-date) |
| `hid` | Hypothesis ID (H1, H2, ...) |
| `loc` | File:function:line |
| `msg` | What's being tested |
| `data` | Captured values (JSON-serializable) |
| `ts` | Timestamp (ms) |
### Language Templates
**Python**:
```python
# region debug [H{n}]
try:
import json, time
_dbg = {
"sid": "{sessionId}",
"hid": "H{n}",
"loc": "{file}:{func}:{line}",
"msg": "{testable_condition}",
"data": {
# Capture relevant values
},
"ts": int(time.time() * 1000)
}
with open(r"{debugLogPath}", "a", encoding="utf-8") as _f:
_f.write(json.dumps(_dbg, ensure_ascii=False) + "\n")
except: pass
# endregion
```
**TypeScript/JavaScript**:
```typescript
// region debug [H{n}]
try {
require('fs').appendFileSync("{debugLogPath}", JSON.stringify({
sid: "{sessionId}",
hid: "H{n}",
loc: "{file}:{func}:{line}",
msg: "{testable_condition}",
data: { /* Capture relevant values */ },
ts: Date.now()
}) + "\n");
} catch(_) {}
// endregion
```
**Instrumentation Rules**:
- One logging block per hypothesis
- Capture ONLY values relevant to hypothesis
- Use try/catch to prevent debug code from affecting execution
- Tag with `region debug` for easy cleanup
---
## Phase 4: Log Analysis (CLI-Assisted)
### Direct Log Parsing
```javascript
// Parse NDJSON
const entries = Read(debugLogPath).split('\n')
.filter(l => l.trim())
.map(l => JSON.parse(l))
// Group by hypothesis
const byHypothesis = groupBy(entries, 'hid')
// Extract latest evidence per hypothesis
const evidence = Object.entries(byHypothesis).map(([hid, logs]) => ({
hid,
count: logs.length,
latest: logs[logs.length - 1],
timeline: logs.map(l => ({ ts: l.ts, data: l.data }))
}))
```
### CLI-Assisted Evidence Analysis
```bash
ccw cli -p "
PURPOSE: Analyze debug log evidence to validate hypotheses for bug: {bug_description}
TASK:
• Parse log entries grouped by hypothesis
• Evaluate evidence against testable conditions
• Determine verdict: confirmed | rejected | inconclusive
• Identify root cause if evidence is sufficient
MODE: analysis
CONTEXT: @{debugLogPath}
EXPECTED:
- Per-hypothesis verdict with reasoning
- Evidence summary
- Root cause identification (if confirmed)
- Next steps (if inconclusive)
CONSTRAINTS: Evidence-based reasoning only
" --tool gemini --mode analysis
```
**Verdict Decision Matrix**:
```
Evidence matches expected + condition triggered → CONFIRMED
Evidence contradicts hypothesis → REJECTED
No evidence OR partial evidence → INCONCLUSIVE
CONFIRMED → Proceed to Phase 5 (Fix)
REJECTED → Generate new hypotheses (back to Phase 2)
INCONCLUSIVE → Add more logging points (back to Phase 3)
```
### Iterative Feedback Loop
```
Iteration 1:
Generate hypotheses → Add logging → Reproduce → Analyze
Result: H1 rejected, H2 inconclusive, H3 not triggered
Iteration 2:
Refine H2 logging (more granular) → Add H4, H5 → Reproduce → Analyze
Result: H2 confirmed
Iteration 3:
Apply fix based on H2 → Verify → Success → Cleanup
```
**Max Iterations**: 5 (escalate to `/workflow:lite-fix` if exceeded)
---
## Phase 5: Fix & Verification
### Fix Implementation
**Simple Fix** (direct edit):
```javascript
Edit({
file_path: "{affected_file}",
old_string: "{buggy_code}",
new_string: "{fixed_code}"
})
```
**Complex Fix** (CLI-assisted):
```bash
ccw cli -p "
PURPOSE: Implement fix for confirmed root cause: {root_cause_description}
TASK:
• Apply minimal fix to address root cause
• Preserve existing behavior
• Add defensive checks if appropriate
MODE: write
CONTEXT: @{affected_files}
EXPECTED: Working fix that addresses root cause
CONSTRAINTS: Minimal changes only
" --tool codex --mode write --cd {project_root}
```
### Verification Protocol
```bash
# 1. Run reproduction steps
# 2. Check debug.log for new entries
# 3. Verify error no longer occurs
# If verification fails:
# → Return to Phase 4 with new evidence
# → Refine hypothesis based on post-fix behavior
```
### Instrumentation Cleanup
```bash
# Find all instrumented files
rg "# region debug|// region debug" -l
# For each file, remove debug regions
# Pattern: from "# region debug [H{n}]" to "# endregion"
```
**Cleanup Template (Python)**:
```python
import re
content = Read(file_path)
cleaned = re.sub(
r'# region debug \[H\d+\].*?# endregion\n?',
'',
content,
flags=re.DOTALL
)
Write(file_path, cleaned)
```
---
## Session Structure
```
.workflow/.debug/DBG-{slug}-{date}/
├── debug.log # NDJSON log (primary artifact)
├── hypotheses.json # Generated hypotheses (optional)
└── resolution.md # Summary after fix (optional)
```
---
## Error Handling
| Situation | Action |
|-----------|--------|
| Empty debug.log | Verify reproduction triggers instrumented path |
| All hypotheses rejected | Broaden scope, check upstream code |
| Fix doesn't resolve | Iterate with more granular logging |
| >5 iterations | Escalate to `/workflow:lite-fix` with evidence |
| CLI tool unavailable | Fallback: Gemini → Qwen → Manual analysis |
| Log parsing fails | Check for malformed JSON entries |
**Tool Fallback**:
```
Gemini unavailable → Qwen
Codex unavailable → Gemini/Qwen write mode
All CLI unavailable → Manual hypothesis testing
```
---
## Output Format
### Explore Mode Output
```markdown
## Debug Session Initialized
**Session**: {sessionId}
**Bug**: {bug_description}
**Affected Files**: {file_list}
### Hypotheses Generated ({count})
{hypotheses.map(h => `
#### ${h.id}: ${h.description}
- **Category**: ${h.category}
- **Logging Point**: ${h.logging_point}
- **Testing**: ${h.testable_condition}
- **Priority**: ${h.priority}
`).join('')}
### Instrumentation Added
{instrumented_files.map(f => `- ${f}`).join('\n')}
**Debug Log**: {debugLogPath}
### Next Steps
1. Run reproduction steps to trigger the bug
2. Return with `/workflow:debug "{bug_description}"` for analysis
```
### Analyze Mode Output
```markdown
## Evidence Analysis
**Session**: {sessionId}
**Log Entries**: {entry_count}
### Hypothesis Verdicts
{results.map(r => `
#### ${r.hid}: ${r.description}
- **Verdict**: ${r.verdict}
- **Evidence**: ${JSON.stringify(r.evidence)}
- **Reasoning**: ${r.reasoning}
`).join('')}
${confirmedHypothesis ? `
### Root Cause Identified
**${confirmedHypothesis.id}**: ${confirmedHypothesis.description}
**Evidence**: ${confirmedHypothesis.evidence}
**Recommended Fix**: ${confirmedHypothesis.fix_suggestion}
` : `
### Need More Evidence
${nextSteps}
`}
```
---
## Quality Checklist
- [ ] Bug description parsed for keywords
- [ ] Affected locations identified
- [ ] Hypotheses are testable (not vague)
- [ ] Instrumentation minimal and targeted
- [ ] Log format valid NDJSON
- [ ] Evidence analysis CLI-assisted (if complex)
- [ ] Verdict backed by evidence
- [ ] Fix minimal and targeted
- [ ] Verification completed
- [ ] Instrumentation cleaned up
- [ ] Session documented
**Performance**: Phase 1-2: ~15-30s | Phase 3: ~20-40s | Phase 4: ~30-60s (with CLI) | Phase 5: Variable
---
## Bash Tool Configuration
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
- Timeout: Analysis 20min | Fix implementation 40min
---

View File

@@ -70,8 +70,8 @@ The agent supports **two execution modes** based on task JSON's `meta.cli_execut
CONTEXT: @**/* ./src/modules/auth|code|code:5|dirs:2
./src/modules/api|code|code:3|dirs:0
EXPECTED: Documentation files in .workflow/docs/my_project/src/modules/
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/documentation/module-documentation.txt) | Mirror source structure
" --tool gemini --mode write --cd src/modules
CONSTRAINTS: Mirror source structure
" --tool gemini --mode write --rule documentation-module --cd src/modules
```
4. **CLI Execution** (Gemini CLI):
@@ -216,7 +216,7 @@ Before completion, verify:
{
"step": "analyze_module_structure",
"action": "Deep analysis of module structure and API",
"command": "ccw cli -p \"PURPOSE: Document module comprehensively\nTASK: Extract module purpose, architecture, public API, dependencies\nMODE: analysis\nCONTEXT: @**/* System: [system_context]\nEXPECTED: Complete module analysis for documentation\nRULES: $(cat ~/.claude/workflows/cli-templates/prompts/documentation/module-documentation.txt)\" --tool gemini --mode analysis --cd src/auth",
"command": "ccw cli -p \"PURPOSE: Document module comprehensively\nTASK: Extract module purpose, architecture, public API, dependencies\nMODE: analysis\nCONTEXT: @**/* System: [system_context]\nEXPECTED: Complete module analysis for documentation\nCONSTRAINTS: Mirror source structure\" --tool gemini --mode analysis --rule documentation-module --cd src/auth",
"output_to": "module_analysis",
"on_error": "fail"
}
@@ -311,6 +311,7 @@ Before completing the task, you must verify the following:
## Key Reminders
**ALWAYS**:
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- **Detect Mode**: Check `meta.cli_execute` to determine execution mode (Agent or CLI).
- **Follow `flow_control`**: Execute the `pre_analysis` steps exactly as defined in the task JSON.
- **Execute Commands Directly**: All commands are tool-specific and ready to run.
@@ -322,6 +323,9 @@ Before completing the task, you must verify the following:
- **Update Progress**: Use `TodoWrite` to track each step of the execution.
- **Generate a Summary**: Create a detailed summary upon task completion.
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**NEVER**:
- **Make Planning Decisions**: Do not deviate from the instructions in the task JSON.
- **Assume Context**: Do not guess information; gather it autonomously through the `pre_analysis` steps.

View File

@@ -0,0 +1,417 @@
---
name: issue-plan-agent
description: |
Closed-loop issue planning agent combining ACE exploration and solution generation.
Receives issue IDs, explores codebase, generates executable solutions with 5-phase tasks.
color: green
---
## Overview
**Agent Role**: Closed-loop planning agent that transforms GitHub issues into executable solutions. Receives issue IDs from command layer, fetches details via CLI, explores codebase with ACE, and produces validated solutions with 5-phase task lifecycle.
**Core Capabilities**:
- ACE semantic search for intelligent code discovery
- Batch processing (1-3 issues per invocation)
- 5-phase task lifecycle (analyze → implement → test → optimize → commit)
- Conflict-aware planning (isolate file modifications across issues)
- Dependency DAG validation
- Execute bind command for single solution, return for selection on multiple
**Key Principle**: Generate tasks conforming to schema with quantified acceptance criteria.
---
## 1. Input & Execution
### 1.1 Input Context
```javascript
{
issue_ids: string[], // Issue IDs only (e.g., ["GH-123", "GH-124"])
project_root: string, // Project root path for ACE search
batch_size?: number, // Max issues per batch (default: 3)
}
```
**Note**: Agent receives IDs only. Fetch details via `ccw issue status <id> --json`.
### 1.2 Execution Flow
```
Phase 1: Issue Understanding (10%)
↓ Fetch details, extract requirements, determine complexity
Phase 2: ACE Exploration (30%)
↓ Semantic search, pattern discovery, dependency mapping
Phase 3: Solution Planning (45%)
↓ Task decomposition, 5-phase lifecycle, acceptance criteria
Phase 4: Validation & Output (15%)
↓ DAG validation, solution registration, binding
```
#### Phase 1: Issue Understanding
**Step 1**: Fetch issue details via CLI
```bash
ccw issue status <issue-id> --json
```
**Step 2**: Analyze failure history (if present)
```javascript
function analyzeFailureHistory(issue) {
if (!issue.feedback || issue.feedback.length === 0) {
return { has_failures: false };
}
// Extract execution failures
const failures = issue.feedback.filter(f => f.type === 'failure' && f.stage === 'execute');
if (failures.length === 0) {
return { has_failures: false };
}
// Parse failure details
const failureAnalysis = failures.map(f => {
const detail = JSON.parse(f.content);
return {
solution_id: detail.solution_id,
task_id: detail.task_id,
error_type: detail.error_type, // test_failure, compilation, timeout, etc.
message: detail.message,
stack_trace: detail.stack_trace,
timestamp: f.created_at
};
});
// Identify patterns
const errorTypes = failureAnalysis.map(f => f.error_type);
const repeatedErrors = errorTypes.filter((e, i, arr) => arr.indexOf(e) !== i);
return {
has_failures: true,
failure_count: failures.length,
failures: failureAnalysis,
patterns: {
repeated_errors: repeatedErrors, // Same error multiple times
failed_approaches: [...new Set(failureAnalysis.map(f => f.solution_id))]
}
};
}
```
**Step 3**: Analyze and classify
```javascript
function analyzeIssue(issue) {
const failureAnalysis = analyzeFailureHistory(issue);
return {
issue_id: issue.id,
requirements: extractRequirements(issue.context),
scope: inferScope(issue.title, issue.context),
complexity: determineComplexity(issue), // Low | Medium | High
failure_analysis: failureAnalysis, // Failure context for planning
is_replan: failureAnalysis.has_failures // Flag for replanning
}
}
```
**Complexity Rules**:
| Complexity | Files | Tasks |
|------------|-------|-------|
| Low | 1-2 | 1-3 |
| Medium | 3-5 | 3-6 |
| High | 6+ | 5-10 |
#### Phase 2: ACE Exploration
**Primary**: ACE semantic search
```javascript
mcp__ace-tool__search_context({
project_root_path: project_root,
query: `Find code related to: ${issue.title}. Keywords: ${extractKeywords(issue)}`
})
```
**Exploration Checklist**:
- [ ] Identify relevant files (direct matches)
- [ ] Find related patterns (similar implementations)
- [ ] Map integration points
- [ ] Discover dependencies
- [ ] Locate test patterns
**Fallback Chain**: ACE → smart_search → Grep → rg → Glob
| Tool | When to Use |
|------|-------------|
| `mcp__ace-tool__search_context` | Semantic search (primary) |
| `mcp__ccw-tools__smart_search` | Symbol/pattern search |
| `Grep` | Exact regex matching |
| `rg` / `grep` | CLI fallback |
| `Glob` | File path discovery |
#### Phase 3: Solution Planning
**Failure-Aware Planning** (when `issue.failure_analysis.has_failures === true`):
```javascript
function planWithFailureContext(issue, exploration, failureAnalysis) {
// Identify what failed before
const failedApproaches = failureAnalysis.patterns.failed_approaches;
const rootCauses = failureAnalysis.failures.map(f => ({
error: f.error_type,
message: f.message,
task: f.task_id
}));
// Design alternative approach
const approach = `
**Previous Attempt Analysis**:
- Failed approaches: ${failedApproaches.join(', ')}
- Root causes: ${rootCauses.map(r => `${r.error} (${r.task}): ${r.message}`).join('; ')}
**Alternative Strategy**:
- [Describe how this solution addresses root causes]
- [Explain what's different from failed approaches]
- [Prevention steps to catch same errors earlier]
`;
// Add explicit verification tasks
const verificationTasks = rootCauses.map(rc => ({
verification_type: rc.error,
check: `Prevent ${rc.error}: ${rc.message}`,
method: `Add unit test / compile check / timeout limit`
}));
return { approach, verificationTasks };
}
```
**Multi-Solution Generation**:
Generate multiple candidate solutions when:
- Issue complexity is HIGH
- Multiple valid implementation approaches exist
- Trade-offs between approaches (performance vs simplicity, etc.)
| Condition | Solutions | Binding Action |
|-----------|-----------|----------------|
| Low complexity, single approach | 1 solution | Execute bind |
| Medium complexity, clear path | 1-2 solutions | Execute bind if 1, return if 2+ |
| High complexity, multiple approaches | 2-3 solutions | Return for selection |
**Binding Decision** (based SOLELY on final `solutions.length`):
```javascript
// After generating all solutions
if (solutions.length === 1) {
exec(`ccw issue bind ${issueId} ${solutions[0].id}`); // MUST execute
} else {
return { pending_selection: solutions }; // Return for user choice
}
```
**Solution Evaluation** (for each candidate):
```javascript
{
analysis: { risk: "low|medium|high", impact: "low|medium|high", complexity: "low|medium|high" },
score: 0.0-1.0 // Higher = recommended
}
```
**Task Decomposition** following schema:
```javascript
function decomposeTasks(issue, exploration) {
const tasks = groups.map(group => ({
id: `T${taskId++}`, // Pattern: ^T[0-9]+$
title: group.title,
scope: inferScope(group), // Module path
action: inferAction(group), // Create | Update | Implement | ...
description: group.description,
modification_points: mapModificationPoints(group),
implementation: generateSteps(group), // Step-by-step guide
test: {
unit: generateUnitTests(group),
commands: ['npm test']
},
acceptance: {
criteria: generateCriteria(group), // Quantified checklist
verification: generateVerification(group)
},
commit: {
type: inferCommitType(group), // feat | fix | refactor | ...
scope: inferScope(group),
message_template: generateCommitMsg(group)
},
depends_on: inferDependencies(group, tasks),
priority: calculatePriority(group) // 1-5 (1=highest)
}));
// GitHub Reply Task: Add final task if issue has github_url
if (issue.github_url || issue.github_number) {
const lastTaskId = tasks[tasks.length - 1]?.id;
tasks.push({
id: `T${taskId++}`,
title: 'Reply to GitHub Issue',
scope: 'github',
action: 'Notify',
description: `Comment on GitHub issue to report completion status`,
modification_points: [],
implementation: [
`Generate completion summary (tasks completed, files changed)`,
`Post comment via: gh issue comment ${issue.github_number || extractNumber(issue.github_url)} --body "..."`,
`Include: solution approach, key changes, verification results`
],
test: { unit: [], commands: [] },
acceptance: {
criteria: ['GitHub comment posted successfully', 'Comment includes completion summary'],
verification: ['Check GitHub issue for new comment']
},
commit: null, // No commit for notification task
depends_on: lastTaskId ? [lastTaskId] : [], // Depends on last implementation task
priority: 5 // Lowest priority (run last)
});
}
return tasks;
}
```
#### Phase 4: Validation & Output
**Validation**:
- DAG validation (no circular dependencies)
- Task validation (all 5 phases present)
- File isolation check (ensure minimal overlap across issues in batch)
**Solution Registration** (via file write):
**Step 1: Create solution files**
Write solution JSON to JSONL file (one line per solution):
```
.workflow/issues/solutions/{issue-id}.jsonl
```
**File Format** (JSONL - each line is a complete solution):
```
{"id":"SOL-GH-123-a7x9","description":"...","approach":"...","analysis":{...},"score":0.85,"tasks":[...]}
{"id":"SOL-GH-123-b2k4","description":"...","approach":"...","analysis":{...},"score":0.75,"tasks":[...]}
```
**Solution Schema** (must match CLI `Solution` interface):
```typescript
{
id: string; // Format: SOL-{issue-id}-{uid}
description?: string;
approach?: string;
tasks: SolutionTask[];
analysis?: { risk, impact, complexity };
score?: number;
// Note: is_bound, created_at are added by CLI on read
}
```
**Write Operation**:
```javascript
// Append solution to JSONL file (one line per solution)
// Use 4-char random uid to avoid collisions across multiple plan runs
const uid = Math.random().toString(36).slice(2, 6); // e.g., "a7x9"
const solutionId = `SOL-${issueId}-${uid}`;
const solutionLine = JSON.stringify({ id: solutionId, ...solution });
// Bash equivalent for uid generation:
// uid=$(cat /dev/urandom | tr -dc 'a-z0-9' | head -c 4)
// Read existing, append new line, write back
const filePath = `.workflow/issues/solutions/${issueId}.jsonl`;
const existing = existsSync(filePath) ? readFileSync(filePath) : '';
const newContent = existing.trimEnd() + (existing ? '\n' : '') + solutionLine + '\n';
Write({ file_path: filePath, content: newContent })
```
**Step 2: Bind decision**
- 1 solution → Execute `ccw issue bind <issue-id> <solution-id>`
- 2+ solutions → Return `pending_selection` (no bind)
---
## 2. Output Requirements
### 2.1 Generate Files (Primary)
**Solution file per issue**:
```
.workflow/issues/solutions/{issue-id}.jsonl
```
Each line is a solution JSON containing tasks. Schema: `cat .claude/workflows/cli-templates/schemas/solution-schema.json`
### 2.2 Return Summary
```json
{
"bound": [{ "issue_id": "...", "solution_id": "...", "task_count": N }],
"pending_selection": [{ "issue_id": "GH-123", "solutions": [{ "id": "SOL-GH-123-1", "description": "...", "task_count": N }] }]
}
```
---
## 3. Quality Standards
### 3.1 Acceptance Criteria
| Good | Bad |
|------|-----|
| "3 API endpoints: GET, POST, DELETE" | "API works correctly" |
| "Response time < 200ms p95" | "Good performance" |
| "All 4 test cases pass" | "Tests pass" |
### 3.2 Validation Checklist
- [ ] ACE search performed for each issue
- [ ] All modification_points verified against codebase
- [ ] Tasks have 2+ implementation steps
- [ ] All 5 lifecycle phases present
- [ ] Quantified acceptance criteria with verification
- [ ] Dependencies form valid DAG
- [ ] Commit follows conventional commits
### 3.3 Guidelines
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**ALWAYS**:
1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
2. Read schema first: `cat .claude/workflows/cli-templates/schemas/solution-schema.json`
3. Use ACE semantic search as PRIMARY exploration tool
4. Fetch issue details via `ccw issue status <id> --json`
5. **Analyze failure history**: Check `issue.feedback` for type='failure', stage='execute'
6. **For replanning**: Reference previous failures in `solution.approach`, add prevention steps
7. Quantify acceptance.criteria with testable conditions
8. Validate DAG before output
9. Evaluate each solution with `analysis` and `score`
10. Write solutions to `.workflow/issues/solutions/{issue-id}.jsonl` (append mode)
11. For HIGH complexity: generate 2-3 candidate solutions
12. **Solution ID format**: `SOL-{issue-id}-{uid}` where uid is 4 random alphanumeric chars (e.g., `SOL-GH-123-a7x9`)
13. **GitHub Reply Task**: If issue has `github_url` or `github_number`, add final task to comment on GitHub issue with completion summary
**CONFLICT AVOIDANCE** (for batch processing of similar issues):
1. **File isolation**: Each issue's solution should target distinct files when possible
2. **Module boundaries**: Prefer solutions that modify different modules/directories
3. **Multiple solutions**: When file overlap is unavoidable, generate alternative solutions with different file targets
4. **Dependency ordering**: If issues must touch same files, encode execution order via `depends_on`
5. **Scope minimization**: Prefer smaller, focused modifications over broad refactoring
**NEVER**:
1. Execute implementation (return plan only)
2. Use vague criteria ("works correctly", "good performance")
3. Create circular dependencies
4. Generate more than 10 tasks per issue
5. Skip bind when `solutions.length === 1` (MUST execute bind command)
**OUTPUT**:
1. Write solutions to `.workflow/issues/solutions/{issue-id}.jsonl`
2. Execute bind or return `pending_selection` based on solution count
3. Return JSON: `{ bound: [...], pending_selection: [...] }`

View File

@@ -0,0 +1,311 @@
---
name: issue-queue-agent
description: |
Solution ordering agent for queue formation with Gemini CLI conflict analysis.
Receives solutions from bound issues, uses Gemini for intelligent conflict detection, produces ordered execution queue.
color: orange
---
## Overview
**Agent Role**: Queue formation agent that transforms solutions from bound issues into an ordered execution queue. Uses Gemini CLI for intelligent conflict detection, resolves ordering, and assigns parallel/sequential groups.
**Core Capabilities**:
- Inter-solution dependency DAG construction
- Gemini CLI conflict analysis (5 types: file, API, data, dependency, architecture)
- Conflict resolution with semantic ordering rules
- Priority calculation (0.0-1.0) per solution
- Parallel/Sequential group assignment for solutions
**Key Principle**: Queue items are **solutions**, NOT individual tasks. Each executor receives a complete solution with all its tasks.
---
## 1. Input & Execution
### 1.1 Input Context
```javascript
{
solutions: [{
issue_id: string, // e.g., "ISS-20251227-001"
solution_id: string, // e.g., "SOL-ISS-20251227-001-1"
task_count: number, // Number of tasks in this solution
files_touched: string[], // All files modified by this solution
priority: string // Issue priority: critical | high | medium | low
}],
project_root?: string,
rebuild?: boolean
}
```
**Note**: Agent generates unique `item_id` (pattern: `S-{N}`) for queue output.
### 1.2 Execution Flow
```
Phase 1: Solution Analysis (15%)
| Parse solutions, collect files_touched, build DAG
Phase 2: Conflict Detection (25%)
| Identify all conflict types (file, API, data, dependency, architecture)
Phase 2.5: Clarification (15%)
| Surface ambiguous dependencies, BLOCK until resolved
Phase 3: Conflict Resolution (20%)
| Apply ordering rules, update DAG
Phase 4: Ordering & Grouping (25%)
| Topological sort, assign parallel/sequential groups
```
---
## 2. Processing Logic
### 2.1 Dependency Graph
**Build DAG from solutions**:
1. Create node for each solution with `inDegree: 0` and `outEdges: []`
2. Build file→solutions mapping from `files_touched`
3. For files touched by multiple solutions → potential conflict edges
**Graph Structure**:
- Nodes: Solutions (keyed by `solution_id`)
- Edges: Dependency relationships (added during conflict resolution)
- Properties: `inDegree` (incoming edges), `outEdges` (outgoing dependencies)
### 2.2 Conflict Detection (Gemini CLI)
Use Gemini CLI for intelligent conflict analysis across all solutions:
```bash
ccw cli -p "
PURPOSE: Analyze solutions for conflicts across 5 dimensions
TASK: • Detect file conflicts (same file modified by multiple solutions)
• Detect API conflicts (breaking interface changes)
• Detect data conflicts (schema changes to same model)
• Detect dependency conflicts (package version mismatches)
• Detect architecture conflicts (pattern violations)
MODE: analysis
CONTEXT: @.workflow/issues/solutions/**/*.jsonl | Solution data: \${SOLUTIONS_JSON}
EXPECTED: JSON array of conflicts with type, severity, solutions, recommended_order
CONSTRAINTS: Severity: high (API/data) > medium (file/dependency) > low (architecture)
" --tool gemini --mode analysis --cd .workflow/issues
```
**Placeholder**: `${SOLUTIONS_JSON}` = serialized solutions array from bound issues
**Conflict Types & Severity**:
| Type | Severity | Trigger |
|------|----------|---------|
| `file_conflict` | medium | Multiple solutions modify same file |
| `api_conflict` | high | Breaking interface changes |
| `data_conflict` | high | Schema changes to same model |
| `dependency_conflict` | medium | Package version mismatches |
| `architecture_conflict` | low | Pattern violations |
**Output per conflict**:
```json
{ "type": "...", "severity": "...", "solutions": [...], "recommended_order": [...], "rationale": "..." }
```
### 2.2.5 Clarification (BLOCKING)
**Purpose**: Surface ambiguous dependencies for user/system clarification
**Trigger Conditions**:
- High severity conflicts without `recommended_order` from Gemini analysis
- Circular dependencies detected
- Multiple valid resolution strategies
**Clarification Generation**:
For each unresolved high-severity conflict:
1. Generate conflict ID: `CFT-{N}`
2. Build question: `"{type}: Which solution should execute first?"`
3. List options with solution summaries (issue title + task count)
4. Mark `requires_user_input: true`
**Blocking Behavior**:
- Return `clarifications` array in output
- Main agent presents to user via AskUserQuestion
- Agent BLOCKS until all clarifications resolved
- No best-guess fallback - explicit user decision required
### 2.3 Resolution Rules
| Priority | Rule | Example |
|----------|------|---------|
| 1 | Higher issue priority first | critical > high > medium > low |
| 2 | Foundation solutions first | Solutions with fewer dependencies |
| 3 | More tasks = higher priority | Solutions with larger impact |
| 4 | Create before extend | S1:Creates module -> S2:Extends it |
### 2.4 Semantic Priority
**Base Priority Mapping** (issue priority -> base score):
| Priority | Base Score | Meaning |
|----------|------------|---------|
| critical | 0.9 | Highest |
| high | 0.7 | High |
| medium | 0.5 | Medium |
| low | 0.3 | Low |
**Task-count Boost** (applied to base score):
| Factor | Boost |
|--------|-------|
| task_count >= 5 | +0.1 |
| task_count >= 3 | +0.05 |
| Foundation scope | +0.1 |
| Fewer dependencies | +0.05 |
**Formula**: `semantic_priority = clamp(baseScore + sum(boosts), 0.0, 1.0)`
### 2.5 Group Assignment
- **Parallel (P*)**: Solutions with no file overlaps between them
- **Sequential (S*)**: Solutions that share files must run in order
---
## 3. Output Requirements
### 3.1 Generate Files (Primary)
**Queue files**:
```
.workflow/issues/queues/{queue-id}.json # Full queue with solutions, conflicts, groups
.workflow/issues/queues/index.json # Update with new queue entry
```
Queue ID: Use the Queue ID provided in prompt (do NOT generate new one)
Queue Item ID format: `S-N` (S-1, S-2, S-3, ...)
### 3.2 Queue File Schema
```json
{
"id": "QUE-20251227-143000",
"status": "active",
"solutions": [
{
"item_id": "S-1",
"issue_id": "ISS-20251227-003",
"solution_id": "SOL-ISS-20251227-003-1",
"status": "pending",
"execution_order": 1,
"execution_group": "P1",
"depends_on": [],
"semantic_priority": 0.8,
"files_touched": ["src/auth.ts", "src/utils.ts"],
"task_count": 3
}
],
"conflicts": [
{
"type": "file_conflict",
"file": "src/auth.ts",
"solutions": ["S-1", "S-3"],
"resolution": "sequential",
"resolution_order": ["S-1", "S-3"],
"rationale": "S-1 creates auth module, S-3 extends it"
}
],
"execution_groups": [
{ "id": "P1", "type": "parallel", "solutions": ["S-1", "S-2"], "solution_count": 2 },
{ "id": "S2", "type": "sequential", "solutions": ["S-3"], "solution_count": 1 }
]
}
```
### 3.3 Return Summary (Brief)
Return brief summaries; full conflict details in separate files:
```json
{
"queue_id": "QUE-20251227-143000",
"total_solutions": N,
"total_tasks": N,
"execution_groups": [{ "id": "P1", "type": "parallel", "count": N }],
"conflicts_summary": [{
"id": "CFT-001",
"type": "api_conflict",
"severity": "high",
"summary": "Brief 1-line description",
"resolution": "sequential",
"details_path": ".workflow/issues/conflicts/CFT-001.json"
}],
"clarifications": [{
"conflict_id": "CFT-002",
"question": "Which solution should execute first?",
"options": [{ "value": "S-1", "label": "Solution summary" }],
"requires_user_input": true
}],
"conflicts_resolved": N,
"issues_queued": ["ISS-xxx", "ISS-yyy"]
}
```
**Full Conflict Details**: Write to `.workflow/issues/conflicts/{conflict-id}.json`
---
## 4. Quality Standards
### 4.1 Validation Checklist
- [ ] No circular dependencies between solutions
- [ ] All file conflicts resolved
- [ ] Solutions in same parallel group have NO file overlaps
- [ ] Semantic priority calculated for all solutions
- [ ] Dependencies ordered correctly
### 4.2 Error Handling
| Scenario | Action |
|----------|--------|
| Circular dependency | Abort, report cycles |
| Resolution creates cycle | Flag for manual resolution |
| Missing solution reference | Skip and warn |
| Empty solution list | Return empty queue |
### 4.3 Guidelines
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**ALWAYS**:
1. **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
2. Build dependency graph before ordering
2. Detect file overlaps between solutions
3. Apply resolution rules consistently
4. Calculate semantic priority for all solutions
5. Include rationale for conflict resolutions
6. Validate ordering before output
**NEVER**:
1. Execute solutions (ordering only)
2. Ignore circular dependencies
3. Skip conflict detection
4. Output invalid DAG
5. Merge conflicting solutions in parallel group
6. Split tasks from their solution
**WRITE** (exactly 2 files):
- `.workflow/issues/queues/{Queue ID}.json` - Full queue with solutions, groups
- `.workflow/issues/queues/index.json` - Update with new queue entry
- Use Queue ID from prompt, do NOT generate new one
**RETURN** (summary + unresolved conflicts):
```json
{
"queue_id": "QUE-xxx",
"total_solutions": N,
"total_tasks": N,
"execution_groups": [{"id": "P1", "type": "parallel", "count": N}],
"issues_queued": ["ISS-xxx"],
"clarifications": [{"conflict_id": "CFT-1", "question": "...", "options": [...]}]
}
```
- `clarifications`: Only present if unresolved high-severity conflicts exist
- No markdown, no prose - PURE JSON only

View File

@@ -75,6 +75,8 @@ Examples:
## Execution Rules
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
1. **Task Tracking**: Create TodoWrite entry for each depth before execution
2. **Parallelism**: Max 4 jobs per depth, sequential across depths
3. **Strategy Assignment**: Assign strategy based on depth:

View File

@@ -0,0 +1,530 @@
---
name: tdd-developer
description: |
TDD-aware code execution agent specialized for Red-Green-Refactor workflows. Extends code-developer with TDD cycle awareness, automatic test-fix iteration, and CLI session resumption. Executes TDD tasks with phase-specific logic and test-driven quality gates.
Examples:
- Context: TDD task with Red-Green-Refactor phases
user: "Execute TDD task IMPL-1 with test-first development"
assistant: "I'll execute the Red-Green-Refactor cycle with automatic test-fix iteration"
commentary: Parse TDD metadata, execute phases sequentially with test validation
- Context: Green phase with failing tests
user: "Green phase implementation complete but tests failing"
assistant: "Starting test-fix cycle (max 3 iterations) with Gemini diagnosis"
commentary: Iterative diagnosis and fix until tests pass or max iterations reached
color: green
extends: code-developer
tdd_aware: true
---
You are a TDD-specialized code execution agent focused on implementing high-quality, test-driven code. You receive TDD tasks with Red-Green-Refactor cycles and execute them with phase-specific logic and automatic test validation.
## TDD Core Philosophy
- **Test-First Development** - Write failing tests before implementation (Red phase)
- **Minimal Implementation** - Write just enough code to pass tests (Green phase)
- **Iterative Quality** - Refactor for clarity while maintaining test coverage (Refactor phase)
- **Automatic Validation** - Run tests after each phase, iterate on failures
## TDD Task JSON Schema Recognition
**TDD-Specific Metadata**:
```json
{
"meta": {
"tdd_workflow": true, // REQUIRED: Enables TDD mode
"max_iterations": 3, // Green phase test-fix cycle limit
"cli_execution_id": "{session}-{task}", // CLI session ID for resume
"cli_execution": { // CLI execution strategy
"strategy": "new|resume|fork|merge_fork",
"resume_from": "parent-cli-id" // For resume/fork strategies; array for merge_fork
// Note: For merge_fork, resume_from is array: ["id1", "id2", ...]
}
},
"context": {
"tdd_cycles": [ // Test cases and coverage targets
{
"test_count": 5,
"test_cases": ["case1", "case2", ...],
"implementation_scope": "...",
"expected_coverage": ">=85%"
}
],
"focus_paths": [...], // Absolute or clear relative paths
"requirements": [...],
"acceptance": [...] // Test commands for validation
},
"flow_control": {
"pre_analysis": [...], // Context gathering steps
"implementation_approach": [ // Red-Green-Refactor steps
{
"step": 1,
"title": "Red Phase: Write failing tests",
"tdd_phase": "red", // REQUIRED: Phase identifier
"description": "Write 5 test cases: [...]",
"modification_points": [...],
"command": "..." // Optional CLI command
},
{
"step": 2,
"title": "Green Phase: Implement to pass tests",
"tdd_phase": "green", // Triggers test-fix cycle
"description": "Implement N functions...",
"modification_points": [...],
"command": "..."
},
{
"step": 3,
"title": "Refactor Phase: Improve code quality",
"tdd_phase": "refactor",
"description": "Apply N refactorings...",
"modification_points": [...]
}
]
}
}
```
## TDD Execution Process
### 1. TDD Task Recognition
**Step 1.1: Detect TDD Mode**
```
IF meta.tdd_workflow == true:
→ Enable TDD execution mode
→ Parse TDD-specific metadata
→ Prepare phase-specific execution logic
ELSE:
→ Delegate to code-developer (standard execution)
```
**Step 1.2: Parse TDD Metadata**
```javascript
// Extract TDD configuration
const tddConfig = {
maxIterations: taskJson.meta.max_iterations || 3,
cliExecutionId: taskJson.meta.cli_execution_id,
cliStrategy: taskJson.meta.cli_execution?.strategy,
resumeFrom: taskJson.meta.cli_execution?.resume_from,
testCycles: taskJson.context.tdd_cycles || [],
acceptanceTests: taskJson.context.acceptance || []
}
// Identify phases
const phases = taskJson.flow_control.implementation_approach
.filter(step => step.tdd_phase)
.map(step => ({
step: step.step,
phase: step.tdd_phase, // "red", "green", or "refactor"
...step
}))
```
**Step 1.3: Validate TDD Task Structure**
```
REQUIRED CHECKS:
- [ ] meta.tdd_workflow is true
- [ ] flow_control.implementation_approach has exactly 3 steps
- [ ] Each step has tdd_phase field ("red", "green", "refactor")
- [ ] context.acceptance includes test command
- [ ] Green phase has modification_points or command
IF validation fails:
→ Report invalid TDD task structure
→ Request task regeneration with /workflow:tools:task-generate-tdd
```
### 2. Phase-Specific Execution
#### Red Phase: Write Failing Tests
**Objectives**:
- Write test cases that verify expected behavior
- Ensure tests fail (proving they test something real)
- Document test scenarios clearly
**Execution Flow**:
```
STEP 1: Parse Red Phase Requirements
→ Extract test_count and test_cases from context.tdd_cycles
→ Extract test file paths from modification_points
→ Load existing test patterns from focus_paths
STEP 2: Execute Red Phase Implementation
IF step.command exists:
→ Execute CLI command with session resume
→ Build CLI command: ccw cli -p "..." --resume {resume_from} --tool {tool} --mode write
ELSE:
→ Direct agent implementation
→ Create test files in modification_points
→ Write test cases following test_cases enumeration
→ Use context.shared_context.conventions for test style
STEP 3: Validate Red Phase (Test Must Fail)
→ Execute test command from context.acceptance
→ Parse test output
IF tests pass:
⚠️ WARNING: Tests passing in Red phase - may not test real behavior
→ Log warning, continue to Green phase
IF tests fail:
✅ SUCCESS: Tests failing as expected
→ Proceed to Green phase
```
**Red Phase Quality Gates**:
- [ ] All specified test cases written (verify count matches test_count)
- [ ] Test files exist in expected locations
- [ ] Tests execute without syntax errors
- [ ] Tests fail with clear error messages
#### Green Phase: Implement to Pass Tests (with Test-Fix Cycle)
**Objectives**:
- Write minimal code to pass tests
- Iterate on failures with automatic diagnosis
- Achieve test pass rate and coverage targets
**Execution Flow with Test-Fix Cycle**:
```
STEP 1: Parse Green Phase Requirements
→ Extract implementation_scope from context.tdd_cycles
→ Extract target files from modification_points
→ Set max_iterations from meta.max_iterations (default: 3)
STEP 2: Initial Implementation
IF step.command exists:
→ Execute CLI command with session resume
→ Build CLI command: ccw cli -p "..." --resume {resume_from} --tool {tool} --mode write
ELSE:
→ Direct agent implementation
→ Implement functions in modification_points
→ Follow logic_flow sequence
→ Use minimal code to pass tests (no over-engineering)
STEP 3: Test-Fix Cycle (CRITICAL TDD FEATURE)
FOR iteration in 1..meta.max_iterations:
STEP 3.1: Run Test Suite
→ Execute test command from context.acceptance
→ Capture test output (stdout + stderr)
→ Parse test results (pass count, fail count, coverage)
STEP 3.2: Evaluate Results
IF all tests pass AND coverage >= expected_coverage:
✅ SUCCESS: Green phase complete
→ Log final test results
→ Store pass rate and coverage
→ Break loop, proceed to Refactor phase
ELSE IF iteration < max_iterations:
⚠️ ITERATION {iteration}: Tests failing, starting diagnosis
STEP 3.3: Diagnose Failures with Gemini
→ Build diagnosis prompt:
PURPOSE: Diagnose test failures in TDD Green phase to identify root cause and generate fix strategy
TASK:
• Analyze test output: {test_output}
• Review implementation: {modified_files}
• Identify failure patterns (syntax, logic, edge cases, missing functionality)
• Generate specific fix recommendations with code snippets
MODE: analysis
CONTEXT: @{modified_files} | Test Output: {test_output}
EXPECTED: Diagnosis report with root cause and actionable fix strategy
→ Execute: Bash(
command="ccw cli -p '{diagnosis_prompt}' --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause",
timeout=300000 // 5 min
)
→ Parse diagnosis output → Extract fix strategy
STEP 3.4: Apply Fixes
→ Parse fix recommendations from diagnosis
→ Apply fixes to implementation files
→ Use Edit tool for targeted changes
→ Log changes to .process/green-fix-iteration-{iteration}.md
STEP 3.5: Continue to Next Iteration
→ iteration++
→ Repeat from STEP 3.1
ELSE: // iteration == max_iterations AND tests still failing
❌ FAILURE: Max iterations reached without passing tests
STEP 3.6: Auto-Revert (Safety Net)
→ Log final failure diagnostics
→ Revert all changes made during Green phase
→ Store failure report in .process/green-phase-failure.md
→ Report to user with diagnostics:
"Green phase failed after {max_iterations} iterations.
All changes reverted. See diagnostics in green-phase-failure.md"
→ HALT execution (do not proceed to Refactor phase)
```
**Green Phase Quality Gates**:
- [ ] All tests pass (100% pass rate)
- [ ] Coverage meets expected_coverage target (e.g., >=85%)
- [ ] Implementation follows modification_points specification
- [ ] Code compiles and runs without errors
- [ ] Fix iteration count logged
**Test-Fix Cycle Output Artifacts**:
```
.workflow/active/{session-id}/.process/
├── green-fix-iteration-1.md # First fix attempt
├── green-fix-iteration-2.md # Second fix attempt
├── green-fix-iteration-3.md # Final fix attempt
└── green-phase-failure.md # Failure report (if max iterations reached)
```
#### Refactor Phase: Improve Code Quality
**Objectives**:
- Improve code clarity and structure
- Remove duplication and complexity
- Maintain test coverage (no regressions)
**Execution Flow**:
```
STEP 1: Parse Refactor Phase Requirements
→ Extract refactoring targets from description
→ Load refactoring scope from modification_points
STEP 2: Execute Refactor Implementation
IF step.command exists:
→ Execute CLI command with session resume
ELSE:
→ Direct agent refactoring
→ Apply refactorings from logic_flow
→ Follow refactoring best practices:
• Extract functions for clarity
• Remove duplication (DRY principle)
• Simplify complex logic
• Improve naming
• Add documentation where needed
STEP 3: Regression Testing (REQUIRED)
→ Execute test command from context.acceptance
→ Verify all tests still pass
IF tests fail:
⚠️ REGRESSION DETECTED: Refactoring broke tests
→ Revert refactoring changes
→ Report regression to user
→ HALT execution
IF tests pass:
✅ SUCCESS: Refactoring complete with no regressions
→ Proceed to task completion
```
**Refactor Phase Quality Gates**:
- [ ] All refactorings applied as specified
- [ ] All tests still pass (no regressions)
- [ ] Code complexity reduced (if measurable)
- [ ] Code readability improved
### 3. CLI Execution Integration
**CLI Session Resumption** (when step.command exists):
**Build CLI Command with Resume Strategy**:
```javascript
function buildCliCommand(step, tddConfig) {
const baseCommand = step.command // From task JSON
// Parse cli_execution strategy
switch (tddConfig.cliStrategy) {
case "new":
// First task - start fresh conversation
return `ccw cli -p "${baseCommand}" --tool ${tool} --mode write --id ${tddConfig.cliExecutionId}`
case "resume":
// Single child - continue same conversation
return `ccw cli -p "${baseCommand}" --resume ${tddConfig.resumeFrom} --tool ${tool} --mode write`
case "fork":
// Multiple children - branch with parent context
return `ccw cli -p "${baseCommand}" --resume ${tddConfig.resumeFrom} --id ${tddConfig.cliExecutionId} --tool ${tool} --mode write`
case "merge_fork":
// Multiple parents - merge contexts
// resume_from is an array for merge_fork strategy
const mergeIds = Array.isArray(tddConfig.resumeFrom)
? tddConfig.resumeFrom.join(',')
: tddConfig.resumeFrom
return `ccw cli -p "${baseCommand}" --resume ${mergeIds} --id ${tddConfig.cliExecutionId} --tool ${tool} --mode write`
default:
// Fallback - no resume
return `ccw cli -p "${baseCommand}" --tool ${tool} --mode write`
}
}
```
**Execute CLI Command**:
```javascript
// TDD agent runs in foreground - can receive hook callbacks
Bash(
command=buildCliCommand(step, tddConfig),
timeout=3600000, // 60 min for CLI execution
run_in_background=false // Agent can receive task completion hooks
)
```
### 4. Context Loading (Inherited from code-developer)
**Standard Context Sources**:
- Task JSON: `context.requirements`, `context.acceptance`, `context.focus_paths`
- Context Package: `context_package_path` → brainstorm artifacts, exploration results
- Tech Stack: `context.shared_context.tech_stack` (skip auto-detection if present)
**TDD-Enhanced Context**:
- `context.tdd_cycles`: Test case enumeration and coverage targets
- `meta.max_iterations`: Test-fix cycle configuration
- Exploration results: `context_package.exploration_results` for critical_files and integration_points
### 5. Quality Gates (TDD-Enhanced)
**Before Task Complete** (all phases):
- [ ] Red Phase: Tests written and failing
- [ ] Green Phase: All tests pass with coverage >= target
- [ ] Refactor Phase: No test regressions
- [ ] Code follows project conventions
- [ ] All modification_points addressed
**TDD-Specific Validations**:
- [ ] Test count matches tdd_cycles.test_count
- [ ] Coverage meets tdd_cycles.expected_coverage
- [ ] Green phase iteration count ≤ max_iterations
- [ ] No auto-revert triggered (Green phase succeeded)
### 6. Task Completion (TDD-Enhanced)
**Upon completing TDD task:**
1. **Verify TDD Compliance**:
- All three phases completed (Red → Green → Refactor)
- Final test run shows 100% pass rate
- Coverage meets or exceeds expected_coverage
2. **Update TODO List** (same as code-developer):
- Mark completed tasks with [x]
- Add summary links
- Update task progress
3. **Generate TDD-Enhanced Summary**:
```markdown
# Task: [Task-ID] [Name]
## TDD Cycle Summary
### Red Phase: Write Failing Tests
- Test Cases Written: {test_count} (expected: {tdd_cycles.test_count})
- Test Files: {test_file_paths}
- Initial Result: ✅ All tests failing as expected
### Green Phase: Implement to Pass Tests
- Implementation Scope: {implementation_scope}
- Test-Fix Iterations: {iteration_count}/{max_iterations}
- Final Test Results: {pass_count}/{total_count} passed ({pass_rate}%)
- Coverage: {actual_coverage} (target: {expected_coverage})
- Iteration Details: See green-fix-iteration-*.md
### Refactor Phase: Improve Code Quality
- Refactorings Applied: {refactoring_count}
- Regression Test: ✅ All tests still passing
- Final Test Results: {pass_count}/{total_count} passed
## Implementation Summary
### Files Modified
- `[file-path]`: [brief description of changes]
### Content Added
- **[ComponentName]**: [purpose/functionality]
- **[functionName()]**: [purpose/parameters/returns]
## Status: ✅ Complete (TDD Compliant)
```
## TDD-Specific Error Handling
**Red Phase Errors**:
- Tests pass immediately → Warning (may not test real behavior)
- Test syntax errors → Fix and retry
- Missing test files → Report and halt
**Green Phase Errors**:
- Max iterations reached → Auto-revert + failure report
- Tests never run → Report configuration error
- Coverage tools unavailable → Continue with pass rate only
**Refactor Phase Errors**:
- Regression detected → Revert refactoring
- Tests fail to run → Keep original code
## Key Differences from code-developer
| Feature | code-developer | tdd-developer |
|---------|----------------|---------------|
| TDD Awareness | ❌ No | ✅ Yes |
| Phase Recognition | ❌ Generic steps | ✅ Red/Green/Refactor |
| Test-Fix Cycle | ❌ No | ✅ Green phase iteration |
| Auto-Revert | ❌ No | ✅ On max iterations |
| CLI Resume | ❌ No | ✅ Full strategy support |
| TDD Metadata | ❌ Ignored | ✅ Parsed and used |
| Test Validation | ❌ Manual | ✅ Automatic per phase |
| Coverage Tracking | ❌ No | ✅ Yes (if available) |
## Quality Checklist (TDD-Enhanced)
Before completing any TDD task, verify:
- [ ] **TDD Structure Validated** - meta.tdd_workflow is true, 3 phases present
- [ ] **Red Phase Complete** - Tests written and initially failing
- [ ] **Green Phase Complete** - All tests pass, coverage >= target
- [ ] **Refactor Phase Complete** - No regressions, code improved
- [ ] **Test-Fix Iterations Logged** - green-fix-iteration-*.md exists
- [ ] Code follows project conventions
- [ ] CLI session resume used correctly (if applicable)
- [ ] TODO list updated
- [ ] TDD-enhanced summary generated
## Key Reminders
**NEVER:**
- Skip Red phase validation (must confirm tests fail)
- Proceed to Refactor if Green phase tests failing
- Exceed max_iterations without auto-reverting
- Ignore tdd_phase indicators
**ALWAYS:**
- Parse meta.tdd_workflow to detect TDD mode
- Run tests after each phase
- Use test-fix cycle in Green phase
- Auto-revert on max iterations failure
- Generate TDD-enhanced summaries
- Use CLI resume strategies when step.command exists
- Log all test-fix iterations to .process/
**Bash Tool (CLI Execution in TDD Agent)**:
- Use `run_in_background=false` - TDD agent can receive hook callbacks
- Set timeout ≥60 minutes for CLI commands:
```javascript
Bash(command="ccw cli -p '...' --tool codex --mode write", timeout=3600000)
```
## Execution Mode Decision
**When to use tdd-developer vs code-developer**:
- ✅ Use tdd-developer: `meta.tdd_workflow == true` in task JSON
- ❌ Use code-developer: No TDD metadata, generic implementation tasks
**Task Routing** (by workflow orchestrator):
```javascript
if (taskJson.meta?.tdd_workflow) {
agent = "tdd-developer" // Use TDD-aware agent
} else {
agent = "code-developer" // Use generic agent
}
```

View File

@@ -28,6 +28,8 @@ You are a test context discovery specialist focused on gathering test coverage i
## Tool Arsenal
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
### 1. Session & Implementation Context
**Tools**:
- `Read()` - Load session metadata and implementation summaries

View File

@@ -59,6 +59,14 @@ When task JSON contains `flow_control` field, execute preparation and implementa
2. **Variable Substitution**: Use `[variable_name]` to reference previous outputs
3. **Error Handling**: Follow step-specific strategies (`skip_optional`, `fail`, `retry_once`)
**Command-to-Tool Mapping** (for pre_analysis commands):
```
"Read(path)" → Read tool: Read(file_path=path)
"bash(command)" → Bash tool: Bash(command=command)
"Search(pattern,path)" → Grep tool: Grep(pattern=pattern, path=path)
"Glob(pattern)" → Glob tool: Glob(pattern=pattern)
```
**Implementation Approach** (`flow_control.implementation_approach`):
When task JSON contains implementation_approach array:
1. **Sequential Execution**: Process steps in order, respecting `depends_on` dependencies
@@ -73,6 +81,12 @@ When task JSON contains implementation_approach array:
- `command`: Optional CLI command (only when explicitly specified)
- `depends_on`: Array of step numbers that must complete first
- `output`: Variable name for this step's output
5. **Execution Mode Selection**:
- IF `command` field exists → Execute CLI command via Bash tool
- ELSE (no command) → Agent direct execution:
- Parse `modification_points` as files to modify
- Follow `logic_flow` for test-fix iteration
- Use test_commands from flow_control for test execution
### 1. Context Assessment & Test Discovery
@@ -318,6 +332,7 @@ When generating test results for orchestrator (saved to `.process/test-results.j
## Important Reminders
**ALWAYS:**
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- **Execute tests first** - Understand what's failing before fixing
- **Diagnose thoroughly** - Find root cause, not just symptoms
- **Fix minimally** - Change only what's needed to pass tests

View File

@@ -284,6 +284,8 @@ You execute 6 distinct task types organized into 3 patterns. Each task includes
### ALWAYS
**Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
**W3C Format Compliance**: ✅ Include $schema in all token files | ✅ Use $type metadata for all tokens | ✅ Use $value wrapper for color (light/dark), duration, easing | ✅ Validate token structure against W3C spec
**Pattern Recognition**: ✅ Identify pattern from [TASK_TYPE_IDENTIFIER] first | ✅ Apply pattern-specific execution rules | ✅ Follow autonomy level

View File

@@ -120,7 +120,11 @@ Before completing any task, verify:
- Make assumptions - verify with existing materials
- Skip quality verification steps
**Bash Tool**:
- Use `run_in_background=false` for all Bash/CLI calls to ensure foreground execution
**ALWAYS:**
- **Search Tool Priority**: ACE (`mcp__ace-tool__search_context`) → CCW (`mcp__ccw-tools__smart_search`) / Built-in (`Grep`, `Glob`, `Read`)
- Verify resource/dependency existence before referencing
- Execute tasks systematically and incrementally
- Test and validate work thoroughly

18
.claude/cli-settings.json Normal file
View File

@@ -0,0 +1,18 @@
{
"version": "1.0.0",
"defaultTool": "gemini",
"promptFormat": "plain",
"smartContext": {
"enabled": false,
"maxFiles": 10
},
"nativeResume": true,
"recursiveQuery": true,
"cache": {
"injectionMode": "auto",
"defaultPrefix": "",
"defaultSuffix": ""
},
"codeIndexMcp": "ace",
"$schema": "./cli-settings.schema.json"
}

View File

@@ -1,47 +0,0 @@
{
"version": "1.0.0",
"tools": {
"gemini": {
"enabled": true,
"isBuiltin": true,
"command": "gemini",
"description": "Google AI for code analysis"
},
"qwen": {
"enabled": true,
"isBuiltin": true,
"command": "qwen",
"description": "Alibaba AI assistant"
},
"codex": {
"enabled": true,
"isBuiltin": true,
"command": "codex",
"description": "OpenAI code generation"
},
"claude": {
"enabled": true,
"isBuiltin": true,
"command": "claude",
"description": "Anthropic AI assistant"
}
},
"customEndpoints": [],
"defaultTool": "gemini",
"settings": {
"promptFormat": "plain",
"smartContext": {
"enabled": false,
"maxFiles": 10
},
"nativeResume": true,
"recursiveQuery": true,
"cache": {
"injectionMode": "auto",
"defaultPrefix": "",
"defaultSuffix": ""
},
"codeIndexMcp": "ace"
},
"$schema": "./cli-tools.schema.json"
}

File diff suppressed because it is too large Load Diff

486
.claude/commands/ccw.md Normal file
View File

@@ -0,0 +1,486 @@
---
name: ccw
description: Main workflow orchestrator - analyze intent, select workflow, execute command chain in main process
argument-hint: "\"task description\""
allowed-tools: SlashCommand(*), TodoWrite(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*)
---
# CCW Command - Main Workflow Orchestrator
Main process orchestrator: intent analysis → workflow selection → command chain execution.
## Core Concept: Minimum Execution Units (最小执行单元)
**Definition**: A set of commands that must execute together as an atomic group to achieve a meaningful workflow milestone.
**Why This Matters**:
- **Prevents Incomplete States**: Avoid stopping after task generation without execution
- **User Experience**: User gets complete results, not intermediate artifacts requiring manual follow-up
- **Workflow Integrity**: Maintains logical coherence of multi-step operations
**Key Units in CCW**:
| Unit Type | Pattern | Example |
|-----------|---------|---------|
| **Planning + Execution** | plan-cmd → execute-cmd | lite-plan → lite-execute |
| **Testing** | test-gen-cmd → test-exec-cmd | test-fix-gen → test-cycle-execute |
| **Review** | review-cmd → fix-cmd | review-session-cycle → review-fix |
**Atomic Rules**:
1. CCW automatically groups commands into minimum units - never splits them
2. Pipeline visualization shows units with `【 】` markers
3. Error handling preserves unit boundaries (retry/skip affects whole unit)
## Execution Model
**Synchronous (Main Process)**: Commands execute via SlashCommand in main process, blocking until complete.
```
User Input → Analyze Intent → Select Workflow → [Confirm] → Execute Chain
SlashCommand (blocking)
Update TodoWrite
Next Command...
```
**vs ccw-coordinator**: External CLI execution with background tasks and hook callbacks.
## 5-Phase Workflow
### Phase 1: Analyze Intent
```javascript
function analyzeIntent(input) {
return {
goal: extractGoal(input),
scope: extractScope(input),
constraints: extractConstraints(input),
task_type: detectTaskType(input), // bugfix|feature|tdd|review|exploration|...
complexity: assessComplexity(input), // low|medium|high
clarity_score: calculateClarity(input) // 0-3 (>=2 = clear)
};
}
// Task type detection (priority order)
function detectTaskType(text) {
const patterns = {
'bugfix-hotfix': /urgent|production|critical/ && /fix|bug/,
'bugfix': /fix|bug|error|crash|fail|debug/,
'issue-batch': /issues?|batch/ && /fix|resolve/,
'exploration': /uncertain|explore|research|what if/,
'multi-perspective': /multi-perspective|compare|cross-verify/,
'quick-task': /quick|simple|small/ && /feature|function/,
'ui-design': /ui|design|component|style/,
'tdd': /tdd|test-driven|test first/,
'test-fix': /test fail|fix test|failing test/,
'review': /review|code review/,
'documentation': /docs|documentation|readme/
};
for (const [type, pattern] of Object.entries(patterns)) {
if (pattern.test(text)) return type;
}
return 'feature';
}
```
**Output**: `Type: [task_type] | Goal: [goal] | Complexity: [complexity] | Clarity: [clarity_score]/3`
---
### Phase 1.5: Requirement Clarification (if clarity_score < 2)
```javascript
async function clarifyRequirements(analysis) {
if (analysis.clarity_score >= 2) return analysis;
const questions = generateClarificationQuestions(analysis); // Goal, Scope, Constraints
const answers = await AskUserQuestion({ questions });
return updateAnalysis(analysis, answers);
}
```
**Questions**: Goal (Create/Fix/Optimize/Analyze), Scope (Single file/Module/Cross-module/System), Constraints (Backward compat/Skip tests/Urgent hotfix)
---
### Phase 2: Select Workflow & Build Command Chain
```javascript
function selectWorkflow(analysis) {
const levelMap = {
'bugfix-hotfix': { level: 2, flow: 'bugfix.hotfix' },
'bugfix': { level: 2, flow: 'bugfix.standard' },
'issue-batch': { level: 'Issue', flow: 'issue' },
'exploration': { level: 4, flow: 'full' },
'quick-task': { level: 1, flow: 'lite-lite-lite' },
'ui-design': { level: analysis.complexity === 'high' ? 4 : 3, flow: 'ui' },
'tdd': { level: 3, flow: 'tdd' },
'test-fix': { level: 3, flow: 'test-fix-gen' },
'review': { level: 3, flow: 'review-fix' },
'documentation': { level: 2, flow: 'docs' },
'feature': { level: analysis.complexity === 'high' ? 3 : 2, flow: analysis.complexity === 'high' ? 'coupled' : 'rapid' }
};
const selected = levelMap[analysis.task_type] || levelMap['feature'];
return buildCommandChain(selected, analysis);
}
// Build command chain (port-based matching with Minimum Execution Units)
function buildCommandChain(workflow, analysis) {
const chains = {
// Level 1 - Rapid
'lite-lite-lite': [
{ cmd: '/workflow:lite-lite-lite', args: `"${analysis.goal}"` }
],
// Level 2 - Lightweight
'rapid': [
// Unit: Quick Implementation【lite-plan → lite-execute】
{ cmd: '/workflow:lite-plan', args: `"${analysis.goal}"`, unit: 'quick-impl' },
{ cmd: '/workflow:lite-execute', args: '--in-memory', unit: 'quick-impl' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
...(analysis.constraints?.includes('skip-tests') ? [] : [
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
])
],
'bugfix.standard': [
// Unit: Bug Fix【lite-fix → lite-execute】
{ cmd: '/workflow:lite-fix', args: `"${analysis.goal}"`, unit: 'bug-fix' },
{ cmd: '/workflow:lite-execute', args: '--in-memory', unit: 'bug-fix' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
...(analysis.constraints?.includes('skip-tests') ? [] : [
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
])
],
'bugfix.hotfix': [
{ cmd: '/workflow:lite-fix', args: `--hotfix "${analysis.goal}"` }
],
'multi-cli-plan': [
// Unit: Multi-CLI Planning【multi-cli-plan → lite-execute】
{ cmd: '/workflow:multi-cli-plan', args: `"${analysis.goal}"`, unit: 'multi-cli' },
{ cmd: '/workflow:lite-execute', args: '--in-memory', unit: 'multi-cli' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
...(analysis.constraints?.includes('skip-tests') ? [] : [
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
])
],
'docs': [
// Unit: Quick Implementation【lite-plan → lite-execute】
{ cmd: '/workflow:lite-plan', args: `"${analysis.goal}"`, unit: 'quick-impl' },
{ cmd: '/workflow:lite-execute', args: '--in-memory', unit: 'quick-impl' }
],
// Level 3 - Standard
'coupled': [
// Unit: Verified Planning【plan → plan-verify】
{ cmd: '/workflow:plan', args: `"${analysis.goal}"`, unit: 'verified-planning' },
{ cmd: '/workflow:plan-verify', args: '', unit: 'verified-planning' },
// Execution
{ cmd: '/workflow:execute', args: '' },
// Unit: Code Review【review-session-cycle → review-fix】
{ cmd: '/workflow:review-session-cycle', args: '', unit: 'code-review' },
{ cmd: '/workflow:review-fix', args: '', unit: 'code-review' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
...(analysis.constraints?.includes('skip-tests') ? [] : [
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
])
],
'tdd': [
// Unit: TDD Planning + Execution【tdd-plan → execute】
{ cmd: '/workflow:tdd-plan', args: `"${analysis.goal}"`, unit: 'tdd-planning' },
{ cmd: '/workflow:execute', args: '', unit: 'tdd-planning' },
// TDD Verification
{ cmd: '/workflow:tdd-verify', args: '' }
],
'test-fix-gen': [
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
{ cmd: '/workflow:test-fix-gen', args: `"${analysis.goal}"`, unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
],
'review-fix': [
// Unit: Code Review【review-session-cycle → review-fix】
{ cmd: '/workflow:review-session-cycle', args: '', unit: 'code-review' },
{ cmd: '/workflow:review-fix', args: '', unit: 'code-review' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
],
'ui': [
{ cmd: '/workflow:ui-design:explore-auto', args: `"${analysis.goal}"` },
// Unit: Planning + Execution【plan → execute】
{ cmd: '/workflow:plan', args: '', unit: 'plan-execute' },
{ cmd: '/workflow:execute', args: '', unit: 'plan-execute' }
],
// Level 4 - Brainstorm
'full': [
{ cmd: '/workflow:brainstorm:auto-parallel', args: `"${analysis.goal}"` },
// Unit: Verified Planning【plan → plan-verify】
{ cmd: '/workflow:plan', args: '', unit: 'verified-planning' },
{ cmd: '/workflow:plan-verify', args: '', unit: 'verified-planning' },
// Execution
{ cmd: '/workflow:execute', args: '' },
// Unit: Test Validation【test-fix-gen → test-cycle-execute】
{ cmd: '/workflow:test-fix-gen', args: '', unit: 'test-validation' },
{ cmd: '/workflow:test-cycle-execute', args: '', unit: 'test-validation' }
],
// Issue Workflow
'issue': [
{ cmd: '/issue:discover', args: '' },
{ cmd: '/issue:plan', args: '--all-pending' },
{ cmd: '/issue:queue', args: '' },
{ cmd: '/issue:execute', args: '' }
]
};
return chains[workflow.flow] || chains['rapid'];
}
```
**Output**: `Level [X] - [flow] | Pipeline: [...] | Commands: [1. /cmd1 2. /cmd2 ...]`
---
### Phase 3: User Confirmation
```javascript
async function getUserConfirmation(chain) {
const response = await AskUserQuestion({
questions: [{
question: "Execute this command chain?",
header: "Confirm",
options: [
{ label: "Confirm", description: "Start" },
{ label: "Adjust", description: "Modify" },
{ label: "Cancel", description: "Abort" }
]
}]
});
if (response.error === "Cancel") throw new Error("Cancelled");
if (response.error === "Adjust") return await adjustChain(chain);
return chain;
}
```
---
### Phase 4: Setup TODO Tracking
```javascript
function setupTodoTracking(chain, workflow) {
const todos = chain.map((step, i) => ({
content: `CCW:${workflow}: [${i + 1}/${chain.length}] ${step.cmd}`,
status: i === 0 ? 'in_progress' : 'pending',
activeForm: `Executing ${step.cmd}`
}));
TodoWrite({ todos });
}
```
**Output**: `-> CCW:rapid: [1/3] /workflow:lite-plan | CCW:rapid: [2/3] /workflow:lite-execute | ...`
---
### Phase 5: Execute Command Chain
```javascript
async function executeCommandChain(chain, workflow) {
let previousResult = null;
for (let i = 0; i < chain.length; i++) {
try {
const fullCommand = assembleCommand(chain[i], previousResult);
const result = await SlashCommand({ command: fullCommand });
previousResult = { ...result, success: true };
updateTodoStatus(i, chain.length, workflow, 'completed');
} catch (error) {
const action = await handleError(chain[i], error, i);
if (action === 'retry') {
i--; // Retry
} else if (action === 'abort') {
return { success: false, error: error.message };
}
// 'skip' - continue
}
}
return { success: true, completed: chain.length };
}
// Assemble full command with session/plan parameters
function assembleCommand(step, previousResult) {
let command = step.cmd;
if (step.args) {
command += ` ${step.args}`;
} else if (previousResult?.session_id) {
command += ` --session="${previousResult.session_id}"`;
}
return command;
}
// Update TODO: mark current as complete, next as in-progress
function updateTodoStatus(index, total, workflow, status) {
const todos = getAllCurrentTodos();
const updated = todos.map(todo => {
if (todo.content.startsWith(`CCW:${workflow}:`)) {
const stepNum = extractStepIndex(todo.content);
if (stepNum === index + 1) return { ...todo, status };
if (stepNum === index + 2 && status === 'completed') return { ...todo, status: 'in_progress' };
}
return todo;
});
TodoWrite({ todos: updated });
}
// Error handling: Retry/Skip/Abort
async function handleError(step, error, index) {
const response = await AskUserQuestion({
questions: [{
question: `${step.cmd} failed: ${error.message}`,
header: "Error",
options: [
{ label: "Retry", description: "Re-execute" },
{ label: "Skip", description: "Continue next" },
{ label: "Abort", description: "Stop" }
]
}]
});
return { Retry: 'retry', Skip: 'skip', Abort: 'abort' }[response.Error] || 'abort';
}
```
---
## Execution Flow Summary
```
User Input
|
Phase 1: Analyze Intent
|-- Extract: goal, scope, constraints, task_type, complexity, clarity
+-- If clarity < 2 -> Phase 1.5: Clarify Requirements
|
Phase 2: Select Workflow & Build Chain
|-- Map task_type -> Level (1/2/3/4/Issue)
|-- Select flow based on complexity
+-- Build command chain (port-based)
|
Phase 3: User Confirmation (optional)
|-- Show pipeline visualization
+-- Allow adjustment
|
Phase 4: Setup TODO Tracking
+-- Create todos with CCW prefix
|
Phase 5: Execute Command Chain
|-- For each command:
| |-- Assemble full command
| |-- Execute via SlashCommand
| |-- Update TODO status
| +-- Handle errors (retry/skip/abort)
+-- Return workflow result
```
---
## Pipeline Examples (with Minimum Execution Units)
**Note**: `【 】` marks Minimum Execution Units - commands execute together as atomic groups.
| Input | Type | Level | Pipeline (with Units) |
|-------|------|-------|-----------------------|
| "Add API endpoint" | feature (low) | 2 |【lite-plan → lite-execute】→【test-fix-gen → test-cycle-execute】|
| "Fix login timeout" | bugfix | 2 |【lite-fix → lite-execute】→【test-fix-gen → test-cycle-execute】|
| "OAuth2 system" | feature (high) | 3 |【plan → plan-verify】→ execute →【review-session-cycle → review-fix】→【test-fix-gen → test-cycle-execute】|
| "Implement with TDD" | tdd | 3 |【tdd-plan → execute】→ tdd-verify |
| "Uncertain: real-time arch" | exploration | 4 | brainstorm:auto-parallel →【plan → plan-verify】→ execute →【test-fix-gen → test-cycle-execute】|
---
## Key Design Principles
1. **Main Process Execution** - Use SlashCommand in main process, no external CLI
2. **Intent-Driven** - Auto-select workflow based on task intent
3. **Port-Based Chaining** - Build command chain using port matching
4. **Minimum Execution Units** - Commands grouped into atomic units, never split (e.g., lite-plan → lite-execute)
5. **Progressive Clarification** - Low clarity triggers clarification phase
6. **TODO Tracking** - Use CCW prefix to isolate workflow todos
7. **Unit-Aware Error Handling** - Retry/skip/abort affects whole unit, not individual commands
8. **User Control** - Optional user confirmation at each phase
---
## State Management
**TodoWrite-Based Tracking**: All execution state tracked via TodoWrite with `CCW:` prefix.
```javascript
// Initial state
todos = [
{ content: "CCW:rapid: [1/3] /workflow:lite-plan", status: "in_progress" },
{ content: "CCW:rapid: [2/3] /workflow:lite-execute", status: "pending" },
{ content: "CCW:rapid: [3/3] /workflow:test-cycle-execute", status: "pending" }
];
// After command 1 completes
todos = [
{ content: "CCW:rapid: [1/3] /workflow:lite-plan", status: "completed" },
{ content: "CCW:rapid: [2/3] /workflow:lite-execute", status: "in_progress" },
{ content: "CCW:rapid: [3/3] /workflow:test-cycle-execute", status: "pending" }
];
```
**vs ccw-coordinator**: Extensive state.json with task_id, status transitions, hook callbacks.
---
## Type Comparison: ccw vs ccw-coordinator
| Aspect | ccw | ccw-coordinator |
|--------|-----|-----------------|
| **Type** | Main process (SlashCommand) | External CLI (ccw cli + hook callbacks) |
| **Execution** | Synchronous blocking | Async background with hook completion |
| **Workflow** | Auto intent-based selection | Manual chain building |
| **Intent Analysis** | 5-phase clarity check | 3-phase requirement analysis |
| **State** | TodoWrite only (in-memory) | state.json + checkpoint/resume |
| **Error Handling** | Retry/skip/abort (interactive) | Retry/skip/abort (via AskUser) |
| **Use Case** | Auto workflow for any task | Manual orchestration, large chains |
---
## Usage
```bash
# Auto-select workflow
ccw "Add user authentication"
# Complex requirement (triggers clarification)
ccw "Optimize system performance"
# Bug fix
ccw "Fix memory leak in WebSocket handler"
# TDD development
ccw "Implement user registration with TDD"
# Exploratory task
ccw "Uncertain about architecture for real-time notifications"
```

View File

@@ -0,0 +1,361 @@
---
name: codex-review
description: Interactive code review using Codex CLI via ccw endpoint with configurable review target, model, and custom instructions
argument-hint: "[--uncommitted|--base <branch>|--commit <sha>] [--model <model>] [--title <title>] [prompt]"
allowed-tools: Bash(*), AskUserQuestion(*), Read(*)
---
# Codex Review Command (/cli:codex-review)
## Overview
Interactive code review command that invokes `codex review` via ccw cli endpoint with guided parameter selection.
**Codex Review Parameters** (from `codex review --help`):
| Parameter | Description |
|-----------|-------------|
| `[PROMPT]` | Custom review instructions (positional) |
| `-c model=<model>` | Override model via config |
| `--uncommitted` | Review staged, unstaged, and untracked changes |
| `--base <BRANCH>` | Review changes against base branch |
| `--commit <SHA>` | Review changes introduced by a commit |
| `--title <TITLE>` | Optional commit title for review summary |
## Prompt Template Format
Follow the standard ccw cli prompt template:
```
PURPOSE: [what] + [why] + [success criteria] + [constraints/scope]
TASK: • [step 1] • [step 2] • [step 3]
MODE: review
CONTEXT: [review target description] | Memory: [relevant context]
EXPECTED: [deliverable format] + [quality criteria]
CONSTRAINTS: [focus constraints]
```
## EXECUTION INSTRUCTIONS - START HERE
**When this command is triggered, follow these exact steps:**
### Step 1: Parse Arguments
Check if user provided arguments directly:
- `--uncommitted` → Record target = uncommitted
- `--base <branch>` → Record target = base, branch name
- `--commit <sha>` → Record target = commit, sha value
- `--model <model>` → Record model selection
- `--title <title>` → Record title
- Remaining text → Use as custom focus/prompt
If no target specified → Continue to Step 2 for interactive selection.
### Step 2: Interactive Parameter Selection
**2.1 Review Target Selection**
```javascript
AskUserQuestion({
questions: [{
question: "What do you want to review?",
header: "Review Target",
options: [
{ label: "Uncommitted changes (Recommended)", description: "Review staged, unstaged, and untracked changes" },
{ label: "Compare to branch", description: "Review changes against a base branch (e.g., main)" },
{ label: "Specific commit", description: "Review changes introduced by a specific commit" }
],
multiSelect: false
}]
})
```
**2.2 Branch/Commit Input (if needed)**
If "Compare to branch" selected:
```javascript
AskUserQuestion({
questions: [{
question: "Which base branch to compare against?",
header: "Base Branch",
options: [
{ label: "main", description: "Compare against main branch" },
{ label: "master", description: "Compare against master branch" },
{ label: "develop", description: "Compare against develop branch" }
],
multiSelect: false
}]
})
```
If "Specific commit" selected:
- Run `git log --oneline -10` to show recent commits
- Ask user to provide commit SHA or select from list
**2.3 Model Selection (Optional)**
```javascript
AskUserQuestion({
questions: [{
question: "Which model to use for review?",
header: "Model",
options: [
{ label: "Default", description: "Use codex default model (gpt-5.2)" },
{ label: "o3", description: "OpenAI o3 reasoning model" },
{ label: "gpt-4.1", description: "GPT-4.1 model" },
{ label: "o4-mini", description: "OpenAI o4-mini (faster)" }
],
multiSelect: false
}]
})
```
**2.4 Review Focus Selection**
```javascript
AskUserQuestion({
questions: [{
question: "What should the review focus on?",
header: "Focus Area",
options: [
{ label: "General review (Recommended)", description: "Comprehensive review: correctness, style, bugs, docs" },
{ label: "Security focus", description: "Security vulnerabilities, input validation, auth issues" },
{ label: "Performance focus", description: "Performance bottlenecks, complexity, resource usage" },
{ label: "Code quality", description: "Readability, maintainability, SOLID principles" }
],
multiSelect: false
}]
})
```
### Step 3: Build Prompt and Command
**3.1 Construct Prompt Based on Focus**
**General Review Prompt:**
```
PURPOSE: Comprehensive code review to identify issues, improve quality, and ensure best practices; success = actionable feedback with clear priorities
TASK: • Review code correctness and logic errors • Check coding standards and consistency • Identify potential bugs and edge cases • Evaluate documentation completeness
MODE: review
CONTEXT: {target_description} | Memory: Project conventions from CLAUDE.md
EXPECTED: Structured review report with: severity levels (Critical/High/Medium/Low), file:line references, specific improvement suggestions, priority ranking
CONSTRAINTS: Focus on actionable feedback
```
**Security Focus Prompt:**
```
PURPOSE: Security-focused code review to identify vulnerabilities and security risks; success = all security issues documented with remediation
TASK: • Scan for injection vulnerabilities (SQL, XSS, command) • Check authentication and authorization logic • Evaluate input validation and sanitization • Identify sensitive data exposure risks
MODE: review
CONTEXT: {target_description} | Memory: Security best practices, OWASP Top 10
EXPECTED: Security report with: vulnerability classification, CVE references where applicable, remediation code snippets, risk severity matrix
CONSTRAINTS: Security-first analysis | Flag all potential vulnerabilities
```
**Performance Focus Prompt:**
```
PURPOSE: Performance-focused code review to identify bottlenecks and optimization opportunities; success = measurable improvement recommendations
TASK: • Analyze algorithmic complexity (Big-O) • Identify memory allocation issues • Check for N+1 queries and blocking operations • Evaluate caching opportunities
MODE: review
CONTEXT: {target_description} | Memory: Performance patterns and anti-patterns
EXPECTED: Performance report with: complexity analysis, bottleneck identification, optimization suggestions with expected impact, benchmark recommendations
CONSTRAINTS: Performance optimization focus
```
**Code Quality Focus Prompt:**
```
PURPOSE: Code quality review to improve maintainability and readability; success = cleaner, more maintainable code
TASK: • Assess SOLID principles adherence • Identify code duplication and abstraction opportunities • Review naming conventions and clarity • Evaluate test coverage implications
MODE: review
CONTEXT: {target_description} | Memory: Project coding standards
EXPECTED: Quality report with: principle violations, refactoring suggestions, naming improvements, maintainability score
CONSTRAINTS: Code quality and maintainability focus
```
**3.2 Build Target Description**
Based on selection, set `{target_description}`:
- Uncommitted: `Reviewing uncommitted changes (staged + unstaged + untracked)`
- Base branch: `Reviewing changes against {branch} branch`
- Commit: `Reviewing changes introduced by commit {sha}`
### Step 4: Execute via CCW CLI
Build and execute the ccw cli command:
```bash
# Base structure
ccw cli -p "<PROMPT>" --tool codex --mode review [OPTIONS]
```
**Command Construction:**
```bash
# Variables from user selection
TARGET_FLAG="" # --uncommitted | --base <branch> | --commit <sha>
MODEL_FLAG="" # --model <model> (if not default)
TITLE_FLAG="" # --title "<title>" (if provided)
# Build target flag
if [ "$target" = "uncommitted" ]; then
TARGET_FLAG="--uncommitted"
elif [ "$target" = "base" ]; then
TARGET_FLAG="--base $branch"
elif [ "$target" = "commit" ]; then
TARGET_FLAG="--commit $sha"
fi
# Build model flag (only if not default)
if [ "$model" != "default" ] && [ -n "$model" ]; then
MODEL_FLAG="--model $model"
fi
# Build title flag (if provided)
if [ -n "$title" ]; then
TITLE_FLAG="--title \"$title\""
fi
# Execute
ccw cli -p "$PROMPT" --tool codex --mode review $TARGET_FLAG $MODEL_FLAG $TITLE_FLAG
```
**Full Example Commands:**
**Option 1: With custom prompt (reviews uncommitted by default):**
```bash
ccw cli -p "
PURPOSE: Comprehensive code review to identify issues and improve quality; success = actionable feedback with priorities
TASK: • Review correctness and logic • Check standards compliance • Identify bugs and edge cases • Evaluate documentation
MODE: review
CONTEXT: Reviewing uncommitted changes | Memory: Project conventions
EXPECTED: Structured report with severity levels, file:line refs, improvement suggestions
CONSTRAINTS: Actionable feedback
" --tool codex --mode review --rule analysis-review-code-quality
```
**Option 2: Target flag only (no prompt allowed):**
```bash
ccw cli --tool codex --mode review --uncommitted
```
### Step 5: Execute and Display Results
```bash
Bash({
command: "ccw cli -p \"$PROMPT\" --tool codex --mode review $FLAGS",
run_in_background: true
})
```
Wait for completion and display formatted results.
## Quick Usage Examples
### Direct Execution (No Interaction)
```bash
# Review uncommitted changes with default settings
/cli:codex-review --uncommitted
# Review against main branch
/cli:codex-review --base main
# Review specific commit
/cli:codex-review --commit abc123
# Review with custom model
/cli:codex-review --uncommitted --model o3
# Review with security focus
/cli:codex-review --uncommitted security
# Full options
/cli:codex-review --base main --model o3 --title "Auth Feature" security
```
### Interactive Mode
```bash
# Start interactive selection (guided flow)
/cli:codex-review
```
## Focus Area Mapping
| User Selection | Prompt Focus | Key Checks |
|----------------|--------------|------------|
| General review | Comprehensive | Correctness, style, bugs, docs |
| Security focus | Security-first | Injection, auth, validation, exposure |
| Performance focus | Optimization | Complexity, memory, queries, caching |
| Code quality | Maintainability | SOLID, duplication, naming, tests |
## Error Handling
### No Changes to Review
```
No changes found for review target. Suggestions:
- For --uncommitted: Make some code changes first
- For --base: Ensure branch exists and has diverged
- For --commit: Verify commit SHA exists
```
### Invalid Branch
```bash
# Show available branches
git branch -a --list | head -20
```
### Invalid Commit
```bash
# Show recent commits
git log --oneline -10
```
## Integration Notes
- Uses `ccw cli --tool codex --mode review` endpoint
- Model passed via prompt (codex uses `-c model=` internally)
- Target flags (`--uncommitted`, `--base`, `--commit`) passed through to codex
- Prompt follows standard ccw cli template format for consistency
## Validation Constraints
**IMPORTANT: Target flags and prompt are mutually exclusive**
The codex CLI has a constraint where target flags (`--uncommitted`, `--base`, `--commit`) cannot be used with a positional `[PROMPT]` argument:
```
error: the argument '--uncommitted' cannot be used with '[PROMPT]'
error: the argument '--base <BRANCH>' cannot be used with '[PROMPT]'
error: the argument '--commit <SHA>' cannot be used with '[PROMPT]'
```
**Behavior:**
- When ANY target flag is specified, ccw cli automatically skips template concatenation (systemRules/roles)
- The review uses codex's default review behavior for the specified target
- Custom prompts are only supported WITHOUT target flags (reviews uncommitted changes by default)
**Valid combinations:**
| Command | Result |
|---------|--------|
| `codex review "Focus on security"` | ✓ Custom prompt, reviews uncommitted (default) |
| `codex review --uncommitted` | ✓ No prompt, uses default review |
| `codex review --base main` | ✓ No prompt, uses default review |
| `codex review --commit abc123` | ✓ No prompt, uses default review |
| `codex review --uncommitted "prompt"` | ✗ Invalid - mutually exclusive |
| `codex review --base main "prompt"` | ✗ Invalid - mutually exclusive |
| `codex review --commit abc123 "prompt"` | ✗ Invalid - mutually exclusive |
**Examples:**
```bash
# ✓ Valid: prompt only (reviews uncommitted by default)
ccw cli -p "Focus on security" --tool codex --mode review
# ✓ Valid: target flag only (no prompt)
ccw cli --tool codex --mode review --uncommitted
ccw cli --tool codex --mode review --base main
ccw cli --tool codex --mode review --commit abc123
# ✗ Invalid: target flag with prompt (will fail)
ccw cli -p "Review this" --tool codex --mode review --uncommitted
ccw cli -p "Review this" --tool codex --mode review --base main
ccw cli -p "Review this" --tool codex --mode review --commit abc123
```

View File

@@ -0,0 +1,768 @@
---
name: issue:discover-by-prompt
description: Discover issues from user prompt with Gemini-planned iterative multi-agent exploration. Uses ACE semantic search for context gathering and supports cross-module comparison (e.g., frontend vs backend API contracts).
argument-hint: "[-y|--yes] <prompt> [--scope=src/**] [--depth=standard|deep] [--max-iterations=5]"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Task(*), AskUserQuestion(*), Glob(*), Grep(*), mcp__ace-tool__search_context(*), mcp__exa__search(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-continue all iterations, skip confirmations.
# Issue Discovery by Prompt
## Quick Start
```bash
# Discover issues based on user description
/issue:discover-by-prompt "Check if frontend API calls match backend implementations"
# Compare specific modules
/issue:discover-by-prompt "Verify auth flow consistency between mobile and web clients" --scope=src/auth/**,src/mobile/**
# Deep exploration with more iterations
/issue:discover-by-prompt "Find all places where error handling is inconsistent" --depth=deep --max-iterations=8
# Focused backend-frontend contract check
/issue:discover-by-prompt "Compare REST API definitions with frontend fetch calls"
```
**Core Difference from `/issue:discover`**:
- `discover`: Pre-defined perspectives (bug, security, etc.), parallel execution
- `discover-by-prompt`: User-driven prompt, Gemini-planned strategy, iterative exploration
## What & Why
### Core Concept
Prompt-driven issue discovery with intelligent planning. Instead of fixed perspectives, this command:
1. **Analyzes user intent** via Gemini to understand what to find
2. **Plans exploration strategy** dynamically based on codebase structure
3. **Executes iterative multi-agent exploration** with feedback loops
4. **Performs cross-module comparison** when detecting comparison intent
### Value Proposition
1. **Natural Language Input**: Describe what you want to find, not how to find it
2. **Intelligent Planning**: Gemini designs optimal exploration strategy
3. **Iterative Refinement**: Each round builds on previous discoveries
4. **Cross-Module Analysis**: Compare frontend/backend, mobile/web, old/new implementations
5. **Adaptive Exploration**: Adjusts direction based on findings
### Use Cases
| Scenario | Example Prompt |
|----------|----------------|
| API Contract | "Check if frontend calls match backend endpoints" |
| Error Handling | "Find inconsistent error handling patterns" |
| Migration Gap | "Compare old auth with new auth implementation" |
| Feature Parity | "Verify mobile has all web features" |
| Schema Drift | "Check if TypeScript types match API responses" |
| Integration | "Find mismatches between service A and service B" |
## How It Works
### Execution Flow
```
Phase 1: Prompt Analysis & Initialization
├─ Parse user prompt and flags
├─ Detect exploration intent (comparison/search/verification)
└─ Initialize discovery session
Phase 1.5: ACE Context Gathering
├─ Use ACE semantic search to understand codebase structure
├─ Identify relevant modules based on prompt keywords
├─ Collect architecture context for Gemini planning
└─ Build initial context package
Phase 2: Gemini Strategy Planning
├─ Feed ACE context + prompt to Gemini CLI
├─ Gemini analyzes and generates exploration strategy
├─ Create exploration dimensions with search targets
├─ Define comparison matrix (if comparison intent)
└─ Set success criteria and iteration limits
Phase 3: Iterative Agent Exploration (with ACE)
├─ Iteration 1: Initial exploration by assigned agents
│ ├─ Agent A: ACE search + explore dimension 1
│ ├─ Agent B: ACE search + explore dimension 2
│ └─ Collect findings, update shared context
├─ Iteration 2-N: Refined exploration
│ ├─ Analyze previous findings
│ ├─ ACE search for related code paths
│ ├─ Execute targeted exploration
│ └─ Update cumulative findings
└─ Termination: Max iterations or convergence
Phase 4: Cross-Analysis & Synthesis
├─ Compare findings across dimensions
├─ Identify discrepancies and issues
├─ Calculate confidence scores
└─ Generate issue candidates
Phase 5: Issue Generation & Summary
├─ Convert findings to issue format
├─ Write discovery outputs
└─ Prompt user for next action
```
### Exploration Dimensions
Dimensions are **dynamically generated by Gemini** based on the user prompt. Not limited to predefined categories.
**Examples**:
| Prompt | Generated Dimensions |
|--------|---------------------|
| "Check API contracts" | frontend-calls, backend-handlers |
| "Find auth issues" | auth-module (single dimension) |
| "Compare old/new implementations" | legacy-code, new-code |
| "Audit payment flow" | payment-service, validation, logging |
| "Find error handling gaps" | error-handlers, error-types, recovery-logic |
Gemini analyzes the prompt + ACE context to determine:
- How many dimensions are needed (1 to N)
- What each dimension should focus on
- Whether comparison is needed between dimensions
### Iteration Strategy
```
┌─────────────────────────────────────────────────────────────┐
│ Iteration Loop │
├─────────────────────────────────────────────────────────────┤
│ 1. Plan: What to explore this iteration │
│ └─ Based on: previous findings + unexplored areas │
│ │
│ 2. Execute: Launch agents for this iteration │
│ └─ Each agent: explore → collect → return summary │
│ │
│ 3. Analyze: Process iteration results │
│ └─ New findings? Gaps? Contradictions? │
│ │
│ 4. Decide: Continue or terminate │
│ └─ Terminate if: max iterations OR convergence OR │
│ high confidence on all questions │
└─────────────────────────────────────────────────────────────┘
```
## Core Responsibilities
### Phase 1: Prompt Analysis & Initialization
```javascript
// Step 1: Parse arguments
const { prompt, scope, depth, maxIterations } = parseArgs(args);
// Step 2: Generate discovery ID
const discoveryId = `DBP-${formatDate(new Date(), 'YYYYMMDD-HHmmss')}`;
// Step 3: Create output directory
const outputDir = `.workflow/issues/discoveries/${discoveryId}`;
await mkdir(outputDir, { recursive: true });
await mkdir(`${outputDir}/iterations`, { recursive: true });
// Step 4: Detect intent type from prompt
const intentType = detectIntent(prompt);
// Returns: 'comparison' | 'search' | 'verification' | 'audit'
// Step 5: Initialize discovery state
await writeJson(`${outputDir}/discovery-state.json`, {
discovery_id: discoveryId,
type: 'prompt-driven',
prompt: prompt,
intent_type: intentType,
scope: scope || '**/*',
depth: depth || 'standard',
max_iterations: maxIterations || 5,
phase: 'initialization',
created_at: new Date().toISOString(),
iterations: [],
cumulative_findings: [],
comparison_matrix: null // filled for comparison intent
});
```
### Phase 1.5: ACE Context Gathering
**Purpose**: Use ACE semantic search to gather codebase context before Gemini planning.
```javascript
// Step 1: Extract keywords from prompt for semantic search
const keywords = extractKeywords(prompt);
// e.g., "frontend API calls match backend" → ["frontend", "API", "backend", "endpoints"]
// Step 2: Use ACE to understand codebase structure
const aceQueries = [
`Project architecture and module structure for ${keywords.join(', ')}`,
`Where are ${keywords[0]} implementations located?`,
`How does ${keywords.slice(0, 2).join(' ')} work in this codebase?`
];
const aceResults = [];
for (const query of aceQueries) {
const result = await mcp__ace-tool__search_context({
project_root_path: process.cwd(),
query: query
});
aceResults.push({ query, result });
}
// Step 3: Build context package for Gemini (kept in memory)
const aceContext = {
prompt_keywords: keywords,
codebase_structure: aceResults[0].result,
relevant_modules: aceResults.slice(1).map(r => r.result),
detected_patterns: extractPatterns(aceResults)
};
// Step 4: Update state (no separate file)
await updateDiscoveryState(outputDir, {
phase: 'context-gathered',
ace_context: {
queries_executed: aceQueries.length,
modules_identified: aceContext.relevant_modules.length
}
});
// aceContext passed to Phase 2 in memory
```
**ACE Query Strategy by Intent Type**:
| Intent | ACE Queries |
|--------|-------------|
| **comparison** | "frontend API calls", "backend API handlers", "API contract definitions" |
| **search** | "{keyword} implementations", "{keyword} usage patterns" |
| **verification** | "expected behavior for {feature}", "test coverage for {feature}" |
| **audit** | "all {category} patterns", "{category} security concerns" |
### Phase 2: Gemini Strategy Planning
**Purpose**: Gemini analyzes user prompt + ACE context to design optimal exploration strategy.
```javascript
// Step 1: Load ACE context gathered in Phase 1.5
const aceContext = await readJson(`${outputDir}/ace-context.json`);
// Step 2: Build Gemini planning prompt with ACE context
const planningPrompt = `
PURPOSE: Analyze discovery prompt and create exploration strategy based on codebase context
TASK:
• Parse user intent from prompt: "${prompt}"
• Use codebase context to identify specific modules and files to explore
• Create exploration dimensions with precise search targets
• Define comparison matrix structure (if comparison intent)
• Set success criteria and iteration strategy
MODE: analysis
CONTEXT: @${scope || '**/*'} | Discovery type: ${intentType}
## Codebase Context (from ACE semantic search)
${JSON.stringify(aceContext, null, 2)}
EXPECTED: JSON exploration plan following exploration-plan-schema.json:
{
"intent_analysis": { "type": "${intentType}", "primary_question": "...", "sub_questions": [...] },
"dimensions": [{ "name": "...", "description": "...", "search_targets": [...], "focus_areas": [...], "agent_prompt": "..." }],
"comparison_matrix": { "dimension_a": "...", "dimension_b": "...", "comparison_points": [...] },
"success_criteria": [...],
"estimated_iterations": N,
"termination_conditions": [...]
}
CONSTRAINTS: Use ACE context to inform targets | Focus on actionable plan
`;
// Step 3: Execute Gemini planning
Bash({
command: `ccw cli -p "${planningPrompt}" --tool gemini --mode analysis`,
run_in_background: true,
timeout: 300000
});
// Step 4: Parse Gemini output and validate against schema
const explorationPlan = await parseGeminiPlanOutput(geminiResult);
validateAgainstSchema(explorationPlan, 'exploration-plan-schema.json');
// Step 5: Enhance plan with ACE-discovered file paths
explorationPlan.dimensions = explorationPlan.dimensions.map(dim => ({
...dim,
ace_suggested_files: aceContext.relevant_modules
.filter(m => m.relevance_to === dim.name)
.map(m => m.file_path)
}));
// Step 6: Update state (plan kept in memory, not persisted)
await updateDiscoveryState(outputDir, {
phase: 'planned',
exploration_plan: {
dimensions_count: explorationPlan.dimensions.length,
has_comparison_matrix: !!explorationPlan.comparison_matrix,
estimated_iterations: explorationPlan.estimated_iterations
}
});
// explorationPlan passed to Phase 3 in memory
```
**Gemini Planning Responsibilities**:
| Responsibility | Input | Output |
|----------------|-------|--------|
| Intent Analysis | User prompt | type, primary_question, sub_questions |
| Dimension Design | ACE context + prompt | dimensions with search_targets |
| Comparison Matrix | Intent type + modules | comparison_points (if applicable) |
| Iteration Strategy | Depth setting | estimated_iterations, termination_conditions |
**Gemini Planning Output Schema**:
```json
{
"intent_analysis": {
"type": "comparison|search|verification|audit",
"primary_question": "string",
"sub_questions": ["string"]
},
"dimensions": [
{
"name": "frontend",
"description": "Client-side API calls and error handling",
"search_targets": ["src/api/**", "src/hooks/**"],
"focus_areas": ["fetch calls", "error boundaries", "response parsing"],
"agent_prompt": "Explore frontend API consumption patterns..."
},
{
"name": "backend",
"description": "Server-side API implementations",
"search_targets": ["src/server/**", "src/routes/**"],
"focus_areas": ["endpoint handlers", "response schemas", "error responses"],
"agent_prompt": "Explore backend API implementations..."
}
],
"comparison_matrix": {
"dimension_a": "frontend",
"dimension_b": "backend",
"comparison_points": [
{"aspect": "endpoints", "frontend_check": "fetch URLs", "backend_check": "route paths"},
{"aspect": "methods", "frontend_check": "HTTP methods used", "backend_check": "methods accepted"},
{"aspect": "payloads", "frontend_check": "request body structure", "backend_check": "expected schema"},
{"aspect": "responses", "frontend_check": "response parsing", "backend_check": "response format"},
{"aspect": "errors", "frontend_check": "error handling", "backend_check": "error responses"}
]
},
"success_criteria": [
"All API endpoints mapped between frontend and backend",
"Discrepancies identified with file:line references",
"Each finding includes remediation suggestion"
],
"estimated_iterations": 3,
"termination_conditions": [
"All comparison points verified",
"No new findings in last iteration",
"Confidence > 0.8 on primary question"
]
}
```
### Phase 3: Iterative Agent Exploration (with ACE)
**Purpose**: Multi-agent iterative exploration using ACE for semantic search within each iteration.
```javascript
let iteration = 0;
let cumulativeFindings = [];
let sharedContext = { aceDiscoveries: [], crossReferences: [] };
let shouldContinue = true;
while (shouldContinue && iteration < maxIterations) {
iteration++;
const iterationDir = `${outputDir}/iterations/${iteration}`;
await mkdir(iterationDir, { recursive: true });
// Step 1: ACE-assisted iteration planning
// Use previous findings to guide ACE queries for this iteration
const iterationAceQueries = iteration === 1
? explorationPlan.dimensions.map(d => d.focus_areas[0]) // Initial queries from plan
: deriveQueriesFromFindings(cumulativeFindings); // Follow-up queries from findings
// Execute ACE searches to find related code
const iterationAceResults = [];
for (const query of iterationAceQueries) {
const result = await mcp__ace-tool__search_context({
project_root_path: process.cwd(),
query: `${query} in ${explorationPlan.scope}`
});
iterationAceResults.push({ query, result });
}
// Update shared context with ACE discoveries
sharedContext.aceDiscoveries.push(...iterationAceResults);
// Step 2: Plan this iteration based on ACE results
const iterationPlan = planIteration(iteration, explorationPlan, cumulativeFindings, iterationAceResults);
// Step 3: Launch dimension agents with ACE context
const agentPromises = iterationPlan.dimensions.map(dimension =>
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Explore ${dimension.name} (iteration ${iteration})`,
prompt: buildDimensionPromptWithACE(dimension, iteration, cumulativeFindings, iterationAceResults, iterationDir)
})
);
// Wait for iteration agents
const iterationResults = await Promise.all(agentPromises);
// Step 4: Collect and analyze iteration findings
const iterationFindings = await collectIterationFindings(iterationDir, iterationPlan.dimensions);
// Step 5: Cross-reference findings between dimensions
if (iterationPlan.dimensions.length > 1) {
const crossRefs = findCrossReferences(iterationFindings, iterationPlan.dimensions);
sharedContext.crossReferences.push(...crossRefs);
}
cumulativeFindings.push(...iterationFindings);
// Step 6: Decide whether to continue
const convergenceCheck = checkConvergence(iterationFindings, cumulativeFindings, explorationPlan);
shouldContinue = !convergenceCheck.converged;
// Step 7: Update state (iteration summary embedded in state)
await updateDiscoveryState(outputDir, {
iterations: [...state.iterations, {
number: iteration,
findings_count: iterationFindings.length,
ace_queries: iterationAceQueries.length,
cross_references: sharedContext.crossReferences.length,
new_discoveries: convergenceCheck.newDiscoveries,
confidence: convergenceCheck.confidence,
continued: shouldContinue
}],
cumulative_findings: cumulativeFindings
});
}
```
**ACE in Iteration Loop**:
```
Iteration N
├─→ ACE Search (based on previous findings)
│ └─ Query: "related code paths for {finding.category}"
│ └─ Result: Additional files to explore
├─→ Agent Exploration (with ACE context)
│ └─ Agent receives: dimension targets + ACE suggestions
│ └─ Agent can call ACE for deeper search
├─→ Cross-Reference Analysis
│ └─ Compare findings between dimensions
│ └─ Identify discrepancies
└─→ Convergence Check
└─ New findings? Continue
└─ No new findings? Terminate
```
**Dimension Agent Prompt Template (with ACE)**:
```javascript
function buildDimensionPromptWithACE(dimension, iteration, previousFindings, aceResults, outputDir) {
// Filter ACE results relevant to this dimension
const relevantAceResults = aceResults.filter(r =>
r.query.includes(dimension.name) || dimension.focus_areas.some(fa => r.query.includes(fa))
);
return `
## Task Objective
Explore ${dimension.name} dimension for issue discovery (Iteration ${iteration})
## Context
- Dimension: ${dimension.name}
- Description: ${dimension.description}
- Search Targets: ${dimension.search_targets.join(', ')}
- Focus Areas: ${dimension.focus_areas.join(', ')}
## ACE Semantic Search Results (Pre-gathered)
The following files/code sections were identified by ACE as relevant to this dimension:
${JSON.stringify(relevantAceResults.map(r => ({ query: r.query, files: r.result.slice(0, 5) })), null, 2)}
**Use ACE for deeper exploration**: You have access to mcp__ace-tool__search_context.
When you find something interesting, use ACE to find related code:
- mcp__ace-tool__search_context({ project_root_path: ".", query: "related to {finding}" })
${iteration > 1 ? `
## Previous Findings to Build Upon
${summarizePreviousFindings(previousFindings, dimension.name)}
## This Iteration Focus
- Explore areas not yet covered (check ACE results for new files)
- Verify/deepen previous findings
- Follow leads from previous discoveries
- Use ACE to find cross-references between dimensions
` : ''}
## MANDATORY FIRST STEPS
1. Read exploration plan: ${outputDir}/../exploration-plan.json
2. Read schema: ~/.claude/workflows/cli-templates/schemas/discovery-finding-schema.json
3. Review ACE results above for starting points
4. Explore files identified by ACE
## Exploration Instructions
${dimension.agent_prompt}
## ACE Usage Guidelines
- Use ACE when you need to find:
- Where a function/class is used
- Related implementations in other modules
- Cross-module dependencies
- Similar patterns elsewhere in codebase
- Query format: Natural language, be specific
- Example: "Where is UserService.authenticate called from?"
## Output Requirements
**1. Write JSON file**: ${outputDir}/${dimension.name}.json
Follow discovery-finding-schema.json:
- findings: [{id, title, category, description, file, line, snippet, confidence, related_dimension}]
- coverage: {files_explored, areas_covered, areas_remaining}
- leads: [{description, suggested_search}] // for next iteration
- ace_queries_used: [{query, result_count}] // track ACE usage
**2. Return summary**:
- Total findings this iteration
- Key discoveries
- ACE queries that revealed important code
- Recommended next exploration areas
## Success Criteria
- [ ] JSON written to ${outputDir}/${dimension.name}.json
- [ ] Each finding has file:line reference
- [ ] ACE used for cross-references where applicable
- [ ] Coverage report included
- [ ] Leads for next iteration identified
`;
}
```
### Phase 4: Cross-Analysis & Synthesis
```javascript
// For comparison intent, perform cross-analysis
if (intentType === 'comparison' && explorationPlan.comparison_matrix) {
const comparisonResults = [];
for (const point of explorationPlan.comparison_matrix.comparison_points) {
const dimensionAFindings = cumulativeFindings.filter(f =>
f.related_dimension === explorationPlan.comparison_matrix.dimension_a &&
f.category.includes(point.aspect)
);
const dimensionBFindings = cumulativeFindings.filter(f =>
f.related_dimension === explorationPlan.comparison_matrix.dimension_b &&
f.category.includes(point.aspect)
);
// Compare and find discrepancies
const discrepancies = findDiscrepancies(dimensionAFindings, dimensionBFindings, point);
comparisonResults.push({
aspect: point.aspect,
dimension_a_count: dimensionAFindings.length,
dimension_b_count: dimensionBFindings.length,
discrepancies: discrepancies,
match_rate: calculateMatchRate(dimensionAFindings, dimensionBFindings)
});
}
// Write comparison analysis
await writeJson(`${outputDir}/comparison-analysis.json`, {
matrix: explorationPlan.comparison_matrix,
results: comparisonResults,
summary: {
total_discrepancies: comparisonResults.reduce((sum, r) => sum + r.discrepancies.length, 0),
overall_match_rate: average(comparisonResults.map(r => r.match_rate)),
critical_mismatches: comparisonResults.filter(r => r.match_rate < 0.5)
}
});
}
// Prioritize all findings
const prioritizedFindings = prioritizeFindings(cumulativeFindings, explorationPlan);
```
### Phase 5: Issue Generation & Summary
```javascript
// Convert high-confidence findings to issues
const issueWorthy = prioritizedFindings.filter(f =>
f.confidence >= 0.7 || f.priority === 'critical' || f.priority === 'high'
);
const issues = issueWorthy.map(finding => ({
id: `ISS-${discoveryId}-${finding.id}`,
title: finding.title,
description: finding.description,
source: {
discovery_id: discoveryId,
finding_id: finding.id,
dimension: finding.related_dimension
},
file: finding.file,
line: finding.line,
priority: finding.priority,
category: finding.category,
suggested_fix: finding.suggested_fix,
confidence: finding.confidence,
status: 'discovered',
created_at: new Date().toISOString()
}));
// Write issues
await writeJsonl(`${outputDir}/discovery-issues.jsonl`, issues);
// Update final state (summary embedded in state, no separate file)
await updateDiscoveryState(outputDir, {
phase: 'complete',
updated_at: new Date().toISOString(),
results: {
total_iterations: iteration,
total_findings: cumulativeFindings.length,
issues_generated: issues.length,
comparison_match_rate: comparisonResults
? average(comparisonResults.map(r => r.match_rate))
: null
}
});
// Prompt user for next action
await AskUserQuestion({
questions: [{
question: `Discovery complete: ${issues.length} issues from ${cumulativeFindings.length} findings across ${iteration} iterations. What next?`,
header: "Next Step",
multiSelect: false,
options: [
{ label: "Export to Issues (Recommended)", description: `Export ${issues.length} issues for planning` },
{ label: "Review Details", description: "View comparison analysis and iteration details" },
{ label: "Run Deeper", description: "Continue with more iterations" },
{ label: "Skip", description: "Complete without exporting" }
]
}]
});
```
## Output File Structure
```
.workflow/issues/discoveries/
└── {DBP-YYYYMMDD-HHmmss}/
├── discovery-state.json # Session state with iteration tracking
├── iterations/
│ ├── 1/
│ │ └── {dimension}.json # Dimension findings
│ ├── 2/
│ │ └── {dimension}.json
│ └── ...
├── comparison-analysis.json # Cross-dimension comparison (if applicable)
└── discovery-issues.jsonl # Generated issue candidates
```
**Simplified Design**:
- ACE context and Gemini plan kept in memory, not persisted
- Iteration summaries embedded in state
- No separate summary.md (state.json contains all needed info)
## Schema References
| Schema | Path | Used By |
|--------|------|---------|
| **Discovery State** | `discovery-state-schema.json` | Orchestrator (state tracking) |
| **Discovery Finding** | `discovery-finding-schema.json` | Dimension agents (output) |
| **Exploration Plan** | `exploration-plan-schema.json` | Gemini output validation (memory only) |
## Configuration Options
| Flag | Default | Description |
|------|---------|-------------|
| `--scope` | `**/*` | File pattern to explore |
| `--depth` | `standard` | `standard` (3 iterations) or `deep` (5+ iterations) |
| `--max-iterations` | 5 | Maximum exploration iterations |
| `--tool` | `gemini` | Planning tool (gemini/qwen) |
| `--plan-only` | `false` | Stop after Phase 2 (Gemini planning), show plan for user review |
## Examples
### Example 1: Single Module Deep Dive
```bash
/issue:discover-by-prompt "Find all potential issues in the auth module" --scope=src/auth/**
```
**Gemini plans** (single dimension):
- Dimension: auth-module
- Focus: security vulnerabilities, edge cases, error handling, test gaps
**Iterations**: 2-3 (until no new findings)
### Example 2: API Contract Comparison
```bash
/issue:discover-by-prompt "Check if API calls match implementations" --scope=src/**
```
**Gemini plans** (comparison):
- Dimension 1: api-consumers (fetch calls, hooks, services)
- Dimension 2: api-providers (handlers, routes, controllers)
- Comparison matrix: endpoints, methods, payloads, responses
### Example 3: Multi-Module Audit
```bash
/issue:discover-by-prompt "Audit the payment flow for issues" --scope=src/payment/**
```
**Gemini plans** (multi-dimension):
- Dimension 1: payment-logic (calculations, state transitions)
- Dimension 2: validation (input checks, business rules)
- Dimension 3: error-handling (failure modes, recovery)
### Example 4: Plan Only Mode
```bash
/issue:discover-by-prompt "Find inconsistent patterns" --plan-only
```
Stops after Gemini planning, outputs:
```
Gemini Plan:
- Intent: search
- Dimensions: 2 (pattern-definitions, pattern-usages)
- Estimated iterations: 3
Continue with exploration? [Y/n]
```
## Related Commands
```bash
# After discovery, plan solutions
/issue:plan DBP-001-01,DBP-001-02
# View all discoveries
/issue:manage
# Standard perspective-based discovery
/issue:discover src/auth/** --perspectives=security,bug
```
## Best Practices
1. **Be Specific in Prompts**: More specific prompts lead to better Gemini planning
2. **Scope Appropriately**: Narrow scope for focused comparison, wider for audits
3. **Review Exploration Plan**: Check `exploration-plan.json` before long explorations
4. **Use Standard Depth First**: Start with standard, go deep only if needed
5. **Combine with `/issue:discover`**: Use prompt-based for comparisons, perspective-based for audits

View File

@@ -0,0 +1,472 @@
---
name: issue:discover
description: Discover potential issues from multiple perspectives (bug, UX, test, quality, security, performance, maintainability, best-practices) using CLI explore. Supports Exa external research for security and best-practices perspectives.
argument-hint: "[-y|--yes] <path-pattern> [--perspectives=bug,ux,...] [--external]"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Task(*), AskUserQuestion(*), Glob(*), Grep(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-select all perspectives, skip confirmations.
# Issue Discovery Command
## Quick Start
```bash
# Discover issues in specific module (interactive perspective selection)
/issue:discover src/auth/**
# Discover with specific perspectives
/issue:discover src/payment/** --perspectives=bug,security,test
# Discover with external research for all perspectives
/issue:discover src/api/** --external
# Discover in multiple modules
/issue:discover src/auth/**,src/payment/**
```
**Discovery Scope**: Specified modules/files only
**Output Directory**: `.workflow/issues/discoveries/{discovery-id}/`
**Available Perspectives**: bug, ux, test, quality, security, performance, maintainability, best-practices
**Exa Integration**: Auto-enabled for security and best-practices perspectives
**CLI Tools**: Gemini → Qwen → Codex (fallback chain)
## What & Why
### Core Concept
Multi-perspective issue discovery orchestrator that explores code from different angles to identify potential bugs, UX improvements, test gaps, and other actionable items. Unlike code review (which assesses existing code quality), discovery focuses on **finding opportunities for improvement and potential problems**.
**vs Code Review**:
- **Code Review** (`review-module-cycle`): Evaluates code quality against standards
- **Issue Discovery** (`issue:discover`): Finds actionable issues, bugs, and improvement opportunities
### Value Proposition
1. **Proactive Issue Detection**: Find problems before they become bugs
2. **Multi-Perspective Analysis**: Each perspective surfaces different types of issues
3. **External Benchmarking**: Compare against industry best practices via Exa
4. **Direct Issue Integration**: Discoveries can be exported to issue tracker
5. **Dashboard Management**: View, filter, and export discoveries via CCW dashboard
## How It Works
### Execution Flow
```
Phase 1: Discovery & Initialization
└─ Parse target pattern, create session, initialize output structure
Phase 2: Interactive Perspective Selection
└─ AskUserQuestion for perspective selection (or use --perspectives)
Phase 3: Parallel Perspective Analysis
├─ Launch N @cli-explore-agent instances (one per perspective)
├─ Security & Best-Practices auto-trigger Exa research
├─ Agent writes perspective JSON, returns summary
└─ Update discovery-progress.json
Phase 4: Aggregation & Prioritization
├─ Collect agent return summaries
├─ Load perspective JSON files
├─ Merge findings, deduplicate by file+line
└─ Calculate priority scores
Phase 5: Issue Generation & Summary
├─ Convert high-priority discoveries to issue format
├─ Write to discovery-issues.jsonl
├─ Generate single summary.md from agent returns
└─ Update discovery-state.json to complete
Phase 6: User Action Prompt
└─ AskUserQuestion for next step (export/dashboard/skip)
```
## Perspectives
### Available Perspectives
| Perspective | Focus | Categories | Exa |
|-------------|-------|------------|-----|
| **bug** | Potential Bugs | edge-case, null-check, resource-leak, race-condition, boundary, exception-handling | - |
| **ux** | User Experience | error-message, loading-state, feedback, accessibility, interaction, consistency | - |
| **test** | Test Coverage | missing-test, edge-case-test, integration-gap, coverage-hole, assertion-quality | - |
| **quality** | Code Quality | complexity, duplication, naming, documentation, code-smell, readability | - |
| **security** | Security Issues | injection, auth, encryption, input-validation, data-exposure, access-control | ✓ |
| **performance** | Performance | n-plus-one, memory-usage, caching, algorithm, blocking-operation, resource | - |
| **maintainability** | Maintainability | coupling, cohesion, tech-debt, extensibility, module-boundary, interface-design | - |
| **best-practices** | Best Practices | convention, pattern, framework-usage, anti-pattern, industry-standard | ✓ |
### Interactive Perspective Selection
When no `--perspectives` flag is provided, the command uses AskUserQuestion:
```javascript
AskUserQuestion({
questions: [{
question: "Select primary discovery focus:",
header: "Focus",
multiSelect: false,
options: [
{ label: "Bug + Test + Quality", description: "Quick scan: potential bugs, test gaps, code quality (Recommended)" },
{ label: "Security + Performance", description: "System audit: security issues, performance bottlenecks" },
{ label: "Maintainability + Best-practices", description: "Long-term health: coupling, tech debt, conventions" },
{ label: "Full analysis", description: "All 7 perspectives (comprehensive, takes longer)" }
]
}]
})
```
**Recommended Combinations**:
- Quick scan: bug, test, quality
- Full analysis: all perspectives
- Security audit: security, bug, quality
## Core Responsibilities
### Orchestrator
**Phase 1: Discovery & Initialization**
```javascript
// Step 1: Parse target pattern and resolve files
const resolvedFiles = await expandGlobPattern(targetPattern);
if (resolvedFiles.length === 0) {
throw new Error(`No files matched pattern: ${targetPattern}`);
}
// Step 2: Generate discovery ID
const discoveryId = `DSC-${formatDate(new Date(), 'YYYYMMDD-HHmmss')}`;
// Step 3: Create output directory
const outputDir = `.workflow/issues/discoveries/${discoveryId}`;
await mkdir(outputDir, { recursive: true });
await mkdir(`${outputDir}/perspectives`, { recursive: true });
// Step 4: Initialize unified discovery state (merged state+progress)
await writeJson(`${outputDir}/discovery-state.json`, {
discovery_id: discoveryId,
target_pattern: targetPattern,
phase: "initialization",
created_at: new Date().toISOString(),
updated_at: new Date().toISOString(),
target: { files_count: { total: resolvedFiles.length }, project: {} },
perspectives: [], // filled after selection: [{name, status, findings}]
external_research: { enabled: false, completed: false },
results: { total_findings: 0, issues_generated: 0, priority_distribution: {} }
});
```
**Phase 2: Perspective Selection**
```javascript
// Check for --perspectives flag
let selectedPerspectives = [];
if (args.perspectives) {
selectedPerspectives = args.perspectives.split(',').map(p => p.trim());
} else {
// Interactive selection via AskUserQuestion
const response = await AskUserQuestion({...});
selectedPerspectives = parseSelectedPerspectives(response);
}
// Validate and update state
await updateDiscoveryState(outputDir, {
'metadata.perspectives': selectedPerspectives,
phase: 'parallel'
});
```
**Phase 3: Parallel Perspective Analysis**
Launch N agents in parallel (one per selected perspective):
```javascript
// Launch agents in parallel - agents write JSON and return summary
const agentPromises = selectedPerspectives.map(perspective =>
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Discover ${perspective} issues`,
prompt: buildPerspectivePrompt(perspective, discoveryId, resolvedFiles, outputDir)
})
);
// Wait for all agents - collect their return summaries
const results = await Promise.all(agentPromises);
// results contain agent summaries for final report
```
**Phase 4: Aggregation & Prioritization**
```javascript
// Load all perspective JSON files written by agents
const allFindings = [];
for (const perspective of selectedPerspectives) {
const jsonPath = `${outputDir}/perspectives/${perspective}.json`;
if (await fileExists(jsonPath)) {
const data = await readJson(jsonPath);
allFindings.push(...data.findings.map(f => ({ ...f, perspective })));
}
}
// Deduplicate and prioritize
const prioritizedFindings = deduplicateAndPrioritize(allFindings);
// Update unified state
await updateDiscoveryState(outputDir, {
phase: 'aggregation',
'results.total_findings': prioritizedFindings.length,
'results.priority_distribution': countByPriority(prioritizedFindings)
});
```
**Phase 5: Issue Generation & Summary**
```javascript
// Convert high-priority findings to issues
const issueWorthy = prioritizedFindings.filter(f =>
f.priority === 'critical' || f.priority === 'high' || f.priority_score >= 0.7
);
// Write discovery-issues.jsonl
await writeJsonl(`${outputDir}/discovery-issues.jsonl`, issues);
// Generate single summary.md from agent return summaries
// Orchestrator briefly summarizes what agents returned (NO detailed reports)
await writeSummaryFromAgentReturns(outputDir, results, prioritizedFindings, issues);
// Update final state
await updateDiscoveryState(outputDir, {
phase: 'complete',
updated_at: new Date().toISOString(),
'results.issues_generated': issues.length
});
```
**Phase 6: User Action Prompt**
```javascript
// Prompt user for next action based on discovery results
const hasHighPriority = issues.some(i => i.priority === 'critical' || i.priority === 'high');
const hasMediumFindings = prioritizedFindings.some(f => f.priority === 'medium');
await AskUserQuestion({
questions: [{
question: `Discovery complete: ${issues.length} issues generated, ${prioritizedFindings.length} total findings. What would you like to do next?`,
header: "Next Step",
multiSelect: false,
options: hasHighPriority ? [
{ label: "Export to Issues (Recommended)", description: `${issues.length} high-priority issues found - export to issue tracker for planning` },
{ label: "Open Dashboard", description: "Review findings in ccw view before exporting" },
{ label: "Skip", description: "Complete discovery without exporting" }
] : hasMediumFindings ? [
{ label: "Open Dashboard (Recommended)", description: "Review medium-priority findings in ccw view to decide which to export" },
{ label: "Export to Issues", description: `Export ${issues.length} issues to tracker` },
{ label: "Skip", description: "Complete discovery without exporting" }
] : [
{ label: "Skip (Recommended)", description: "No significant issues found - complete discovery" },
{ label: "Open Dashboard", description: "Review all findings in ccw view" },
{ label: "Export to Issues", description: `Export ${issues.length} issues anyway` }
]
}]
});
// Handle response
if (response === "Export to Issues") {
// Append to issues.jsonl
await appendJsonl('.workflow/issues/issues.jsonl', issues);
console.log(`Exported ${issues.length} issues. Run /issue:plan to continue.`);
} else if (response === "Open Dashboard") {
console.log('Run `ccw view` and navigate to Issues > Discovery to manage findings.');
}
```
### Output File Structure
```
.workflow/issues/discoveries/
├── index.json # Discovery session index
└── {discovery-id}/
├── discovery-state.json # Unified state (merged state+progress)
├── perspectives/
│ └── {perspective}.json # Per-perspective findings
├── external-research.json # Exa research results (if enabled)
├── discovery-issues.jsonl # Generated candidate issues
└── summary.md # Single summary (from agent returns)
```
### Schema References
**External Schema Files** (agent MUST read and follow exactly):
| Schema | Path | Purpose |
|--------|------|---------|
| **Discovery State** | `~/.claude/workflows/cli-templates/schemas/discovery-state-schema.json` | Session state machine |
| **Discovery Finding** | `~/.claude/workflows/cli-templates/schemas/discovery-finding-schema.json` | Perspective analysis results |
### Agent Invocation Template
**Perspective Analysis Agent**:
```javascript
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `Discover ${perspective} issues`,
prompt: `
## Task Objective
Discover potential ${perspective} issues in specified module files.
## Discovery Context
- Discovery ID: ${discoveryId}
- Perspective: ${perspective}
- Target Pattern: ${targetPattern}
- Resolved Files: ${resolvedFiles.length} files
- Output Directory: ${outputDir}
## MANDATORY FIRST STEPS
1. Read discovery state: ${outputDir}/discovery-state.json
2. Read schema: ~/.claude/workflows/cli-templates/schemas/discovery-finding-schema.json
3. Analyze target files for ${perspective} concerns
## Output Requirements
**1. Write JSON file**: ${outputDir}/perspectives/${perspective}.json
- Follow discovery-finding-schema.json exactly
- Each finding: id, title, priority, category, description, file, line, snippet, suggested_issue, confidence
**2. Return summary** (DO NOT write report file):
- Return a brief text summary of findings
- Include: total findings, priority breakdown, key issues
- This summary will be used by orchestrator for final report
## Perspective-Specific Guidance
${getPerspectiveGuidance(perspective)}
## Success Criteria
- [ ] JSON written to ${outputDir}/perspectives/${perspective}.json
- [ ] Summary returned with findings count and key issues
- [ ] Each finding includes actionable suggested_issue
- [ ] Priority uses lowercase enum: critical/high/medium/low
`
})
```
**Exa Research Agent** (for security and best-practices):
```javascript
Task({
subagent_type: "cli-explore-agent",
run_in_background: false,
description: `External research for ${perspective} via Exa`,
prompt: `
## Task Objective
Research industry best practices for ${perspective} using Exa search
## Research Steps
1. Read project tech stack: .workflow/project-tech.json
2. Use Exa to search for best practices
3. Synthesize findings relevant to this project
## Output Requirements
**1. Write JSON file**: ${outputDir}/external-research.json
- Include sources, key_findings, gap_analysis, recommendations
**2. Return summary** (DO NOT write report file):
- Brief summary of external research findings
- Key recommendations for the project
## Success Criteria
- [ ] JSON written to ${outputDir}/external-research.json
- [ ] Summary returned with key recommendations
- [ ] Findings are relevant to project's tech stack
`
})
```
### Perspective Guidance Reference
```javascript
function getPerspectiveGuidance(perspective) {
const guidance = {
bug: `
Focus: Null checks, edge cases, resource leaks, race conditions, boundary conditions, exception handling
Priority: Critical=data corruption/crash, High=malfunction, Medium=edge case issues, Low=minor
`,
ux: `
Focus: Error messages, loading states, feedback, accessibility, interaction patterns, form validation
Priority: Critical=inaccessible, High=confusing, Medium=inconsistent, Low=cosmetic
`,
test: `
Focus: Missing unit tests, edge case coverage, integration gaps, assertion quality, test isolation
Priority: Critical=no security tests, High=no core logic tests, Medium=weak coverage, Low=minor gaps
`,
quality: `
Focus: Complexity, duplication, naming, documentation, code smells, readability
Priority: Critical=unmaintainable, High=significant issues, Medium=naming/docs, Low=minor refactoring
`,
security: `
Focus: Input validation, auth/authz, injection, XSS/CSRF, data exposure, access control
Priority: Critical=auth bypass/injection, High=missing authz, Medium=weak validation, Low=headers
`,
performance: `
Focus: N+1 queries, memory leaks, caching, algorithm efficiency, blocking operations
Priority: Critical=memory leaks, High=N+1/inefficient, Medium=missing cache, Low=minor optimization
`,
maintainability: `
Focus: Coupling, interface design, tech debt, extensibility, module boundaries, configuration
Priority: Critical=unrelated code changes, High=unclear boundaries, Medium=coupling, Low=refactoring
`,
'best-practices': `
Focus: Framework conventions, language patterns, anti-patterns, deprecated APIs, coding standards
Priority: Critical=anti-patterns causing bugs, High=convention violations, Medium=style, Low=cosmetic
`
};
return guidance[perspective] || 'General code discovery analysis';
}
```
## Dashboard Integration
### Viewing Discoveries
Open CCW dashboard to manage discoveries:
```bash
ccw view
```
Navigate to **Issues > Discovery** to:
- View all discovery sessions
- Filter findings by perspective and priority
- Preview finding details
- Select and export findings as issues
### Exporting to Issues
From the dashboard, select findings and click "Export as Issues" to:
1. Convert discoveries to standard issue format
2. Append to `.workflow/issues/issues.jsonl`
3. Set status to `registered`
4. Continue with `/issue:plan` workflow
## Related Commands
```bash
# After discovery, plan solutions for exported issues
/issue:plan DSC-001,DSC-002,DSC-003
# Or use interactive management
/issue:manage
```
## Best Practices
1. **Start Focused**: Begin with specific modules rather than entire codebase
2. **Use Quick Scan First**: Start with bug, test, quality for fast results
3. **Review Before Export**: Not all discoveries warrant issues - use dashboard to filter
4. **Combine Perspectives**: Run related perspectives together (e.g., security + bug)
5. **Enable Exa for New Tech**: When using unfamiliar frameworks, enable external research

View File

@@ -0,0 +1,580 @@
---
name: execute
description: Execute queue with DAG-based parallel orchestration (one commit per solution)
argument-hint: "[-y|--yes] --queue <queue-id> [--worktree [<existing-path>]]"
allowed-tools: TodoWrite(*), Bash(*), Read(*), AskUserQuestion(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm execution, use recommended settings.
# Issue Execute Command (/issue:execute)
## Overview
Minimal orchestrator that dispatches **solution IDs** to executors. Each executor receives a complete solution with all its tasks.
**Design Principles:**
- `queue dag` → returns parallel batches with solution IDs (S-1, S-2, ...)
- `detail <id>` → READ-ONLY solution fetch (returns full solution with all tasks)
- `done <id>` → update solution completion status
- No race conditions: status changes only via `done`
- **Executor handles all tasks within a solution sequentially**
- **Single worktree for entire queue**: One worktree isolates ALL queue execution from main workspace
## Queue ID Requirement (MANDATORY)
**Queue ID is REQUIRED.** You MUST specify which queue to execute via `--queue <queue-id>`.
### If Queue ID Not Provided
When `--queue` parameter is missing, you MUST:
1. **List available queues** by running:
```javascript
const result = Bash('ccw issue queue list --brief --json');
const index = JSON.parse(result);
```
2. **Display available queues** to user:
```
Available Queues:
ID Status Progress Issues
-----------------------------------------------------------
→ QUE-20251215-001 active 3/10 ISS-001, ISS-002
QUE-20251210-002 active 0/5 ISS-003
QUE-20251205-003 completed 8/8 ISS-004
```
3. **Stop and ask user** to specify which queue to execute:
```javascript
AskUserQuestion({
questions: [{
question: "Which queue would you like to execute?",
header: "Queue",
multiSelect: false,
options: index.queues
.filter(q => q.status === 'active')
.map(q => ({
label: q.id,
description: `${q.status}, ${q.completed_solutions || 0}/${q.total_solutions || 0} completed, Issues: ${q.issue_ids.join(', ')}`
}))
}]
})
```
4. **After user selection**, continue execution with the selected queue ID.
**DO NOT auto-select queues.** Explicit user confirmation is required to prevent accidental execution of wrong queue.
## Usage
```bash
/issue:execute --queue QUE-xxx # Execute specific queue (REQUIRED)
/issue:execute --queue QUE-xxx --worktree # Execute in isolated worktree
/issue:execute --queue QUE-xxx --worktree /path/to/existing/worktree # Resume
```
**Parallelism**: Determined automatically by task dependency DAG (no manual control)
**Executor & Dry-run**: Selected via interactive prompt (AskUserQuestion)
**Worktree**: Creates ONE worktree for the entire queue execution (not per-solution)
**⭐ Recommended Executor**: **Codex** - Best for long-running autonomous work (2hr timeout), supports background execution and full write access
**Worktree Options**:
- `--worktree` - Create a new worktree with timestamp-based name
- `--worktree <existing-path>` - Resume in an existing worktree (for recovery/continuation)
**Resume**: Use `git worktree list` to find existing worktrees from interrupted executions
## Execution Flow
```
Phase 0: Validate Queue ID (REQUIRED)
├─ If --queue provided → use specified queue
├─ If --queue missing → list queues, prompt user to select
└─ Store QUEUE_ID for all subsequent commands
Phase 0.5 (if --worktree): Setup Queue Worktree
├─ Create ONE worktree for entire queue: .ccw/worktrees/queue-<timestamp>
├─ All subsequent execution happens in this worktree
└─ Main workspace remains clean and untouched
Phase 1: Get DAG & User Selection
├─ ccw issue queue dag --queue ${QUEUE_ID} → { parallel_batches: [["S-1","S-2"], ["S-3"]] }
└─ AskUserQuestion → executor type (codex|gemini|agent), dry-run mode, worktree mode
Phase 2: Dispatch Parallel Batch (DAG-driven)
├─ Parallelism determined by DAG (no manual limit)
├─ All executors work in the SAME worktree (or main if no worktree)
├─ For each solution ID in batch (parallel - all at once):
│ ├─ Executor calls: ccw issue detail <id> (READ-ONLY)
│ ├─ Executor gets FULL SOLUTION with all tasks
│ ├─ Executor implements all tasks sequentially (T1 → T2 → T3)
│ ├─ Executor tests + verifies each task
│ ├─ Executor commits ONCE per solution (with formatted summary)
│ └─ Executor calls: ccw issue done <id>
└─ Wait for batch completion
Phase 3: Next Batch (repeat Phase 2)
└─ ccw issue queue dag → check for newly-ready solutions
Phase 4 (if --worktree): Worktree Completion
├─ All batches complete → prompt for merge strategy
└─ Options: Create PR / Merge to main / Keep branch
```
## Implementation
### Phase 0: Validate Queue ID
```javascript
// Check if --queue was provided
let QUEUE_ID = args.queue;
if (!QUEUE_ID) {
// List available queues
const listResult = Bash('ccw issue queue list --brief --json').trim();
const index = JSON.parse(listResult);
if (index.queues.length === 0) {
console.log('No queues found. Use /issue:queue to create one first.');
return;
}
// Filter active queues only
const activeQueues = index.queues.filter(q => q.status === 'active');
if (activeQueues.length === 0) {
console.log('No active queues found.');
console.log('Available queues:', index.queues.map(q => `${q.id} (${q.status})`).join(', '));
return;
}
// Display and prompt user
console.log('\nAvailable Queues:');
console.log('ID'.padEnd(22) + 'Status'.padEnd(12) + 'Progress'.padEnd(12) + 'Issues');
console.log('-'.repeat(70));
for (const q of index.queues) {
const marker = q.id === index.active_queue_id ? '→ ' : ' ';
console.log(marker + q.id.padEnd(20) + q.status.padEnd(12) +
`${q.completed_solutions || 0}/${q.total_solutions || 0}`.padEnd(12) +
q.issue_ids.join(', '));
}
const answer = AskUserQuestion({
questions: [{
question: "Which queue would you like to execute?",
header: "Queue",
multiSelect: false,
options: activeQueues.map(q => ({
label: q.id,
description: `${q.completed_solutions || 0}/${q.total_solutions || 0} completed, Issues: ${q.issue_ids.join(', ')}`
}))
}]
});
QUEUE_ID = answer['Queue'];
}
console.log(`\n## Executing Queue: ${QUEUE_ID}\n`);
```
### Phase 1: Get DAG & User Selection
```javascript
// Get dependency graph and parallel batches (QUEUE_ID required)
const dagJson = Bash(`ccw issue queue dag --queue ${QUEUE_ID}`).trim();
const dag = JSON.parse(dagJson);
if (dag.error || dag.ready_count === 0) {
console.log(dag.error || 'No solutions ready for execution');
console.log('Use /issue:queue to form a queue first');
return;
}
console.log(`
## Queue DAG (Solution-Level)
- Total Solutions: ${dag.total}
- Ready: ${dag.ready_count}
- Completed: ${dag.completed_count}
- Parallel in batch 1: ${dag.parallel_batches[0]?.length || 0}
`);
// Interactive selection via AskUserQuestion
const answer = AskUserQuestion({
questions: [
{
question: 'Select executor type:',
header: 'Executor',
multiSelect: false,
options: [
{ label: 'Codex (Recommended)', description: 'Autonomous coding with full write access' },
{ label: 'Gemini', description: 'Large context analysis and implementation' },
{ label: 'Agent', description: 'Claude Code sub-agent for complex tasks' }
]
},
{
question: 'Execution mode:',
header: 'Mode',
multiSelect: false,
options: [
{ label: 'Execute (Recommended)', description: 'Run all ready solutions' },
{ label: 'Dry-run', description: 'Show DAG and batches without executing' }
]
},
{
question: 'Use git worktree for queue isolation?',
header: 'Worktree',
multiSelect: false,
options: [
{ label: 'Yes (Recommended)', description: 'Create ONE worktree for entire queue - main stays clean' },
{ label: 'No', description: 'Work directly in current directory' }
]
}
]
});
const executor = answer['Executor'].toLowerCase().split(' ')[0]; // codex|gemini|agent
const isDryRun = answer['Mode'].includes('Dry-run');
const useWorktree = answer['Worktree'].includes('Yes');
// Dry run mode
if (isDryRun) {
console.log('### Parallel Batches (Dry-run):\n');
dag.parallel_batches.forEach((batch, i) => {
console.log(`Batch ${i + 1}: ${batch.join(', ')}`);
});
return;
}
```
### Phase 0 & 2: Setup Queue Worktree & Dispatch
```javascript
// Parallelism determined by DAG - no manual limit
// All solutions in same batch have NO file conflicts and can run in parallel
const batch = dag.parallel_batches[0] || [];
// Initialize TodoWrite
TodoWrite({
todos: batch.map(id => ({
content: `Execute solution ${id}`,
status: 'pending',
activeForm: `Executing solution ${id}`
}))
});
console.log(`\n### Executing Solutions (DAG batch 1): ${batch.join(', ')}`);
// Parse existing worktree path from args if provided
// Example: --worktree /path/to/existing/worktree
const existingWorktree = args.worktree && typeof args.worktree === 'string' ? args.worktree : null;
// Setup ONE worktree for entire queue (not per-solution)
let worktreePath = null;
let worktreeBranch = null;
if (useWorktree) {
const repoRoot = Bash('git rev-parse --show-toplevel').trim();
const worktreeBase = `${repoRoot}/.ccw/worktrees`;
Bash(`mkdir -p "${worktreeBase}"`);
Bash('git worktree prune'); // Cleanup stale worktrees
if (existingWorktree) {
// Resume mode: Use existing worktree
worktreePath = existingWorktree;
worktreeBranch = Bash(`git -C "${worktreePath}" branch --show-current`).trim();
console.log(`Resuming in existing worktree: ${worktreePath} (branch: ${worktreeBranch})`);
} else {
// Create mode: ONE worktree for the entire queue
const timestamp = new Date().toISOString().replace(/[-:T]/g, '').slice(0, 14);
worktreeBranch = `queue-exec-${dag.queue_id || timestamp}`;
worktreePath = `${worktreeBase}/${worktreeBranch}`;
Bash(`git worktree add "${worktreePath}" -b "${worktreeBranch}"`);
console.log(`Created queue worktree: ${worktreePath}`);
}
}
// Launch ALL solutions in batch in parallel (DAG guarantees no conflicts)
// All executors work in the SAME worktree (or main if no worktree)
const executions = batch.map(solutionId => {
updateTodo(solutionId, 'in_progress');
return dispatchExecutor(solutionId, executor, worktreePath);
});
await Promise.all(executions);
batch.forEach(id => updateTodo(id, 'completed'));
```
### Executor Dispatch
```javascript
// worktreePath: path to shared worktree (null if not using worktree)
function dispatchExecutor(solutionId, executorType, worktreePath = null) {
// If worktree is provided, executor works in that directory
// No per-solution worktree creation - ONE worktree for entire queue
// Pre-defined values (replaced at dispatch time, NOT by executor)
const SOLUTION_ID = solutionId;
const WORK_DIR = worktreePath || null;
// Build prompt without markdown code blocks to avoid escaping issues
const prompt = `
## Execute Solution: ${SOLUTION_ID}
${WORK_DIR ? `Working Directory: ${WORK_DIR}` : ''}
### Step 1: Get Solution Details
Run this command to get the full solution with all tasks:
ccw issue detail ${SOLUTION_ID}
### Step 2: Execute All Tasks Sequentially
The detail command returns a FULL SOLUTION with all tasks.
Execute each task in order (T1 → T2 → T3 → ...):
For each task:
- Follow task.implementation steps
- Run task.test commands
- Verify task.acceptance criteria
- Do NOT commit after each task
### Step 3: Commit Solution (Once)
After ALL tasks pass, commit once with formatted summary.
Command:
git add -A
git commit -m "<type>(<scope>): <description>
Solution: ${SOLUTION_ID}
Tasks completed: <list task IDs>
Changes:
- <file1>: <what changed>
- <file2>: <what changed>
Verified: all tests passed"
Replace <type> with: feat|fix|refactor|docs|test
Replace <scope> with: affected module name
Replace <description> with: brief summary from solution
### Step 4: Report Completion
On success, run:
ccw issue done ${SOLUTION_ID} --result '{"summary": "<brief>", "files_modified": ["<file1>", "<file2>"], "commit": {"hash": "<hash>", "type": "<type>"}, "tasks_completed": <N>}'
On failure, run:
ccw issue done ${SOLUTION_ID} --fail --reason '{"task_id": "<TX>", "error_type": "<test_failure|build_error|other>", "message": "<error details>"}'
### Important Notes
- Do NOT cleanup worktree - it is shared by all solutions in the queue
- Replace all <placeholder> values with actual values from your execution
`;
// For CLI tools, pass --cd to set working directory
const cdOption = worktreePath ? ` --cd "${worktreePath}"` : '';
if (executorType === 'codex') {
return Bash(
`ccw cli -p "${escapePrompt(prompt)}" --tool codex --mode write --id exec-${solutionId}${cdOption}`,
{ timeout: 7200000, run_in_background: true } // 2hr for full solution
);
} else if (executorType === 'gemini') {
return Bash(
`ccw cli -p "${escapePrompt(prompt)}" --tool gemini --mode write --id exec-${solutionId}${cdOption}`,
{ timeout: 3600000, run_in_background: true }
);
} else {
return Task({
subagent_type: 'code-developer',
run_in_background: false,
description: `Execute solution ${solutionId}`,
prompt: worktreePath ? `Working directory: ${worktreePath}\n\n${prompt}` : prompt
});
}
}
```
### Phase 3: Check Next Batch
```javascript
// Refresh DAG after batch completes (use same QUEUE_ID)
const refreshedDag = JSON.parse(Bash(`ccw issue queue dag --queue ${QUEUE_ID}`).trim());
console.log(`
## Batch Complete
- Solutions Completed: ${refreshedDag.completed_count}/${refreshedDag.total}
- Next ready: ${refreshedDag.ready_count}
`);
if (refreshedDag.ready_count > 0) {
console.log(`Run \`/issue:execute --queue ${QUEUE_ID}\` again for next batch.`);
// Note: If resuming, pass existing worktree path:
// /issue:execute --queue ${QUEUE_ID} --worktree <worktreePath>
}
```
### Phase 4: Worktree Completion (after ALL batches)
```javascript
// Only run when ALL solutions completed AND using worktree
if (useWorktree && refreshedDag.ready_count === 0 && refreshedDag.completed_count === refreshedDag.total) {
console.log('\n## All Solutions Completed - Worktree Cleanup');
const answer = AskUserQuestion({
questions: [{
question: `Queue complete. What to do with worktree branch "${worktreeBranch}"?`,
header: 'Merge',
multiSelect: false,
options: [
{ label: 'Create PR (Recommended)', description: 'Push branch and create pull request' },
{ label: 'Merge to main', description: 'Merge all commits and cleanup worktree' },
{ label: 'Keep branch', description: 'Cleanup worktree, keep branch for manual handling' }
]
}]
});
const repoRoot = Bash('git rev-parse --show-toplevel').trim();
if (answer['Merge'].includes('Create PR')) {
Bash(`git -C "${worktreePath}" push -u origin "${worktreeBranch}"`);
Bash(`gh pr create --title "Queue ${dag.queue_id}" --body "Issue queue execution - all solutions completed" --head "${worktreeBranch}"`);
Bash(`git worktree remove "${worktreePath}"`);
console.log(`PR created for branch: ${worktreeBranch}`);
} else if (answer['Merge'].includes('Merge to main')) {
// Check main is clean
const mainDirty = Bash('git status --porcelain').trim();
if (mainDirty) {
console.log('Warning: Main has uncommitted changes. Falling back to PR.');
Bash(`git -C "${worktreePath}" push -u origin "${worktreeBranch}"`);
Bash(`gh pr create --title "Queue ${dag.queue_id}" --body "Issue queue execution (main had uncommitted changes)" --head "${worktreeBranch}"`);
} else {
Bash(`git merge --no-ff "${worktreeBranch}" -m "Merge queue ${dag.queue_id}"`);
Bash(`git branch -d "${worktreeBranch}"`);
}
Bash(`git worktree remove "${worktreePath}"`);
} else {
Bash(`git worktree remove "${worktreePath}"`);
console.log(`Branch ${worktreeBranch} kept for manual handling`);
}
}
```
## Parallel Execution Model
```
┌─────────────────────────────────────────────────────────────────┐
│ Orchestrator │
├─────────────────────────────────────────────────────────────────┤
│ 0. Validate QUEUE_ID (required, or prompt user to select) │
│ │
│ 0.5 (if --worktree) Create ONE worktree for entire queue │
│ → .ccw/worktrees/queue-exec-<queue-id> │
│ │
│ 1. ccw issue queue dag --queue ${QUEUE_ID} │
│ → { parallel_batches: [["S-1","S-2"], ["S-3"]] } │
│ │
│ 2. Dispatch batch 1 (parallel, SAME worktree): │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Shared Queue Worktree (or main) │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ Executor 1 │ │ Executor 2 │ │ │
│ │ │ detail S-1 │ │ detail S-2 │ │ │
│ │ │ [T1→T2→T3] │ │ [T1→T2] │ │ │
│ │ │ commit S-1 │ │ commit S-2 │ │ │
│ │ │ done S-1 │ │ done S-2 │ │ │
│ │ └──────────────────┘ └──────────────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 3. ccw issue queue dag (refresh) │
│ → S-3 now ready → dispatch batch 2 (same worktree) │
│ │
│ 4. (if --worktree) ALL batches complete → cleanup worktree │
│ → Prompt: Create PR / Merge to main / Keep branch │
└─────────────────────────────────────────────────────────────────┘
```
**Why this works for parallel:**
- **ONE worktree for entire queue** → all solutions share same isolated workspace
- `detail <id>` is READ-ONLY → no race conditions
- Each executor handles **all tasks within a solution** sequentially
- **One commit per solution** with formatted summary (not per-task)
- `done <id>` updates only its own solution status
- `queue dag` recalculates ready solutions after each batch
- Solutions in same batch have NO file conflicts (DAG guarantees)
- **Main workspace stays clean** until merge/PR decision
## CLI Endpoint Contract
### `ccw issue queue list --brief --json`
Returns queue index for selection (used when --queue not provided):
```json
{
"active_queue_id": "QUE-20251215-001",
"queues": [
{ "id": "QUE-20251215-001", "status": "active", "issue_ids": ["ISS-001"], "total_solutions": 5, "completed_solutions": 2 }
]
}
```
### `ccw issue queue dag --queue <queue-id>`
Returns dependency graph with parallel batches (solution-level, **--queue required**):
```json
{
"queue_id": "QUE-...",
"total": 3,
"ready_count": 2,
"completed_count": 0,
"nodes": [
{ "id": "S-1", "issue_id": "ISS-xxx", "status": "pending", "ready": true, "task_count": 3 },
{ "id": "S-2", "issue_id": "ISS-yyy", "status": "pending", "ready": true, "task_count": 2 },
{ "id": "S-3", "issue_id": "ISS-zzz", "status": "pending", "ready": false, "depends_on": ["S-1"] }
],
"parallel_batches": [["S-1", "S-2"], ["S-3"]]
}
```
### `ccw issue detail <item_id>`
Returns FULL SOLUTION with all tasks (READ-ONLY):
```json
{
"item_id": "S-1",
"issue_id": "ISS-xxx",
"solution_id": "SOL-xxx",
"status": "pending",
"solution": {
"id": "SOL-xxx",
"approach": "...",
"tasks": [
{ "id": "T1", "title": "...", "implementation": [...], "test": {...} },
{ "id": "T2", "title": "...", "implementation": [...], "test": {...} },
{ "id": "T3", "title": "...", "implementation": [...], "test": {...} }
],
"exploration_context": { "relevant_files": [...] }
},
"execution_hints": { "executor": "codex", "estimated_minutes": 180 }
}
```
### `ccw issue done <item_id>`
Marks solution completed/failed, updates queue state, checks for queue completion.
## Error Handling
| Error | Resolution |
|-------|------------|
| No queue | Run /issue:queue first |
| No ready solutions | Dependencies blocked, check DAG |
| Executor timeout | Solution not marked done, can retry |
| Solution failure | Use `ccw issue retry` to reset |
| Partial task failure | Executor reports which task failed via `done --fail` |
## Related Commands
- `/issue:plan` - Plan issues with solutions
- `/issue:queue` - Form execution queue
- `ccw issue queue dag` - View dependency graph
- `ccw issue detail <id>` - View task details
- `ccw issue retry` - Reset failed tasks

View File

@@ -0,0 +1,417 @@
---
name: new
description: Create structured issue from GitHub URL or text description
argument-hint: "[-y|--yes] <github-url | text-description> [--priority 1-5]"
allowed-tools: TodoWrite(*), Bash(*), Read(*), AskUserQuestion(*), mcp__ace-tool__search_context(*)
---
## Auto Mode
When `--yes` or `-y`: Skip clarification questions, create issue with inferred details.
# Issue New Command (/issue:new)
## Core Principle
**Requirement Clarity Detection** → Ask only when needed
```
Clear Input (GitHub URL, structured text) → Direct creation
Unclear Input (vague description) → Minimal clarifying questions
```
## Issue Structure
```typescript
interface Issue {
id: string; // GH-123 or ISS-YYYYMMDD-HHMMSS
title: string;
status: 'registered' | 'planned' | 'queued' | 'in_progress' | 'completed' | 'failed';
priority: number; // 1 (critical) to 5 (low)
context: string; // Problem description (single source of truth)
source: 'github' | 'text' | 'discovery';
source_url?: string;
labels?: string[];
// GitHub binding (for non-GitHub sources that publish to GitHub)
github_url?: string; // https://github.com/owner/repo/issues/123
github_number?: number; // 123
// Optional structured fields
expected_behavior?: string;
actual_behavior?: string;
affected_components?: string[];
// Feedback history (failures + human clarifications)
feedback?: {
type: 'failure' | 'clarification' | 'rejection';
stage: string; // new/plan/execute
content: string;
created_at: string;
}[];
// Solution binding
bound_solution_id: string | null;
// Timestamps
created_at: string;
updated_at: string;
}
```
## Quick Reference
```bash
# Clear inputs - direct creation
/issue:new https://github.com/owner/repo/issues/123
/issue:new "Login fails with special chars. Expected: success. Actual: 500 error"
# Vague input - will ask clarifying questions
/issue:new "something wrong with auth"
```
## Implementation
### Phase 1: Input Analysis & Clarity Detection
```javascript
const input = userInput.trim();
const flags = parseFlags(userInput); // --priority
// Detect input type and clarity
const isGitHubUrl = input.match(/github\.com\/[\w-]+\/[\w-]+\/issues\/\d+/);
const isGitHubShort = input.match(/^#(\d+)$/);
const hasStructure = input.match(/(expected|actual|affects|steps):/i);
// Clarity score: 0-3
let clarityScore = 0;
if (isGitHubUrl || isGitHubShort) clarityScore = 3; // GitHub = fully clear
else if (hasStructure) clarityScore = 2; // Structured text = clear
else if (input.length > 50) clarityScore = 1; // Long text = somewhat clear
else clarityScore = 0; // Vague
let issueData = {};
```
### Phase 2: Data Extraction (GitHub or Text)
```javascript
if (isGitHubUrl || isGitHubShort) {
// GitHub - fetch via gh CLI
const result = Bash(`gh issue view ${extractIssueRef(input)} --json number,title,body,labels,url`);
const gh = JSON.parse(result);
issueData = {
id: `GH-${gh.number}`,
title: gh.title,
source: 'github',
source_url: gh.url,
labels: gh.labels.map(l => l.name),
context: gh.body?.substring(0, 500) || gh.title,
...parseMarkdownBody(gh.body)
};
} else {
// Text description
issueData = {
id: `ISS-${new Date().toISOString().replace(/[-:T]/g, '').slice(0, 14)}`,
source: 'text',
...parseTextDescription(input)
};
}
```
### Phase 3: Lightweight Context Hint (Conditional)
```javascript
// ACE search ONLY for medium clarity (1-2) AND missing components
// Skip for: GitHub (has context), vague (needs clarification first)
// Note: Deep exploration happens in /issue:plan, this is just a quick hint
if (clarityScore >= 1 && clarityScore <= 2 && !issueData.affected_components?.length) {
const keywords = extractKeywords(issueData.context);
if (keywords.length >= 2) {
try {
const aceResult = mcp__ace-tool__search_context({
project_root_path: process.cwd(),
query: keywords.slice(0, 3).join(' ')
});
issueData.affected_components = aceResult.files?.slice(0, 3) || [];
} catch {
// ACE failure is non-blocking
}
}
}
```
### Phase 4: Conditional Clarification (Only if Unclear)
```javascript
// ONLY ask questions if clarity is low - simple open-ended prompt
if (clarityScore < 2 && (!issueData.context || issueData.context.length < 20)) {
const answer = AskUserQuestion({
questions: [{
question: 'Please describe the issue in more detail:',
header: 'Clarify',
multiSelect: false,
options: [
{ label: 'Provide details', description: 'Describe what, where, and expected behavior' }
]
}]
});
// Use custom text input (via "Other")
if (answer.customText) {
issueData.context = answer.customText;
issueData.title = answer.customText.split(/[.\n]/)[0].substring(0, 60);
issueData.feedback = [{
type: 'clarification',
stage: 'new',
content: answer.customText,
created_at: new Date().toISOString()
}];
}
}
```
### Phase 5: GitHub Publishing Decision (Non-GitHub Sources)
```javascript
// For non-GitHub sources, ask if user wants to publish to GitHub
let publishToGitHub = false;
if (issueData.source !== 'github') {
const publishAnswer = AskUserQuestion({
questions: [{
question: 'Would you like to publish this issue to GitHub?',
header: 'Publish',
multiSelect: false,
options: [
{ label: 'Yes, publish to GitHub', description: 'Create issue on GitHub and link it' },
{ label: 'No, keep local only', description: 'Store as local issue without GitHub sync' }
]
}]
});
publishToGitHub = publishAnswer.answers?.['Publish']?.includes('Yes');
}
```
### Phase 6: Create Issue
**Summary Display:**
- Show ID, title, source, affected files (if any)
**Confirmation** (only for vague inputs, clarityScore < 2):
- Use `AskUserQuestion` to confirm before creation
**Issue Creation** (via CLI endpoint):
```bash
# Option 1: Pipe input (recommended for complex JSON - avoids shell escaping)
echo '{"title":"...", "context":"...", "priority":3}' | ccw issue create
# Option 2: Heredoc (for multi-line JSON)
ccw issue create << 'EOF'
{"title":"...", "context":"含\"引号\"的内容", "priority":3}
EOF
# Option 3: --data parameter (simple cases only)
ccw issue create --data '{"title":"...", "priority":3}'
```
**CLI Endpoint Features:**
| Feature | Description |
|---------|-------------|
| Auto-increment ID | `ISS-YYYYMMDD-NNN` (e.g., `ISS-20251229-001`) |
| Trailing newline | Proper JSONL format, no corruption |
| JSON output | Returns created issue with all fields |
**Example:**
```bash
# Create issue via pipe (recommended)
echo '{"title": "Login fails with special chars", "context": "500 error when password contains quotes", "priority": 2}' | ccw issue create
# Or with heredoc for complex JSON
ccw issue create << 'EOF'
{
"title": "Login fails with special chars",
"context": "500 error when password contains \"quotes\"",
"priority": 2,
"source": "text",
"expected_behavior": "Login succeeds",
"actual_behavior": "500 Internal Server Error"
}
EOF
# Output (JSON)
{
"id": "ISS-20251229-001",
"title": "Login fails with special chars",
"status": "registered",
...
}
```
**GitHub Publishing** (if user opted in):
```javascript
// Step 1: Create local issue FIRST
const localIssue = createLocalIssue(issueData); // ccw issue create
// Step 2: Publish to GitHub if requested
if (publishToGitHub) {
const ghResult = Bash(`gh issue create --title "${issueData.title}" --body "${issueData.context}"`);
// Parse GitHub URL from output
const ghUrl = ghResult.match(/https:\/\/github\.com\/[\w-]+\/[\w-]+\/issues\/\d+/)?.[0];
const ghNumber = parseInt(ghUrl?.match(/\/issues\/(\d+)/)?.[1]);
if (ghNumber) {
// Step 3: Update local issue with GitHub binding
Bash(`ccw issue update ${localIssue.id} --github-url "${ghUrl}" --github-number ${ghNumber}`);
// Or via pipe:
// echo '{"github_url":"${ghUrl}","github_number":${ghNumber}}' | ccw issue update ${localIssue.id}
}
}
```
**Workflow:**
```
1. Create local issue (ISS-YYYYMMDD-NNN) → stored in .workflow/issues.jsonl
2. If publishToGitHub:
a. gh issue create → returns GitHub URL
b. Update local issue with github_url + github_number binding
3. Both local and GitHub issues exist, linked together
```
**Example with GitHub Publishing:**
```bash
# User creates text issue
/issue:new "Login fails with special chars. Expected: success. Actual: 500"
# System asks: "Would you like to publish this issue to GitHub?"
# User selects: "Yes, publish to GitHub"
# Output:
# ✓ Local issue created: ISS-20251229-001
# ✓ Published to GitHub: https://github.com/org/repo/issues/123
# ✓ GitHub binding saved to local issue
# → Next step: /issue:plan ISS-20251229-001
# Resulting issue JSON:
{
"id": "ISS-20251229-001",
"title": "Login fails with special chars",
"source": "text",
"github_url": "https://github.com/org/repo/issues/123",
"github_number": 123,
...
}
```
**Completion:**
- Display created issue ID
- Show GitHub URL (if published)
- Show next step: `/issue:plan <id>`
## Execution Flow
```
Phase 1: Input Analysis
└─ Detect clarity score (GitHub URL? Structured text? Keywords?)
Phase 2: Data Extraction (branched by clarity)
┌────────────┬─────────────────┬──────────────┐
│ Score 3 │ Score 1-2 │ Score 0 │
│ GitHub │ Text + ACE │ Vague │
├────────────┼─────────────────┼──────────────┤
│ gh CLI │ Parse struct │ AskQuestion │
│ → parse │ + quick hint │ (1 question) │
│ │ (3 files max) │ → feedback │
└────────────┴─────────────────┴──────────────┘
Phase 3: GitHub Publishing Decision (non-GitHub only)
├─ Source = github: Skip (already from GitHub)
└─ Source ≠ github: AskUserQuestion
├─ Yes → publishToGitHub = true
└─ No → publishToGitHub = false
Phase 4: Create Issue
├─ Score ≥ 2: Direct creation
└─ Score < 2: Confirm first → Create
└─ If publishToGitHub: gh issue create → link URL
Note: Deep exploration & lifecycle deferred to /issue:plan
```
## Helper Functions
```javascript
function extractKeywords(text) {
const stopWords = new Set(['the', 'a', 'an', 'is', 'are', 'was', 'were', 'not', 'with']);
return text
.toLowerCase()
.split(/\W+/)
.filter(w => w.length > 3 && !stopWords.has(w))
.slice(0, 5);
}
function parseTextDescription(text) {
const result = { title: '', context: '' };
const sentences = text.split(/\.(?=\s|$)/);
result.title = sentences[0]?.trim().substring(0, 60) || 'Untitled';
result.context = text.substring(0, 500);
// Extract structured fields if present
const expected = text.match(/expected:?\s*([^.]+)/i);
const actual = text.match(/actual:?\s*([^.]+)/i);
const affects = text.match(/affects?:?\s*([^.]+)/i);
if (expected) result.expected_behavior = expected[1].trim();
if (actual) result.actual_behavior = actual[1].trim();
if (affects) {
result.affected_components = affects[1].split(/[,\s]+/).filter(c => c.includes('/') || c.includes('.'));
}
return result;
}
function parseMarkdownBody(body) {
if (!body) return {};
const result = {};
const problem = body.match(/##?\s*(problem|description)[:\s]*([\s\S]*?)(?=##|$)/i);
const expected = body.match(/##?\s*expected[:\s]*([\s\S]*?)(?=##|$)/i);
const actual = body.match(/##?\s*actual[:\s]*([\s\S]*?)(?=##|$)/i);
if (problem) result.context = problem[2].trim().substring(0, 500);
if (expected) result.expected_behavior = expected[2].trim();
if (actual) result.actual_behavior = actual[2].trim();
return result;
}
```
## Examples
### Clear Input (No Questions)
```bash
/issue:new https://github.com/org/repo/issues/42
# → Fetches, parses, creates immediately
/issue:new "Login fails with special chars. Expected: success. Actual: 500"
# → Parses structure, creates immediately
```
### Vague Input (1 Question)
```bash
/issue:new "auth broken"
# → Asks: "Input unclear. What is the issue about?"
# → User provides details → saved to feedback[]
# → Creates issue
```
## Related Commands
- `/issue:plan` - Plan solution for issue

View File

@@ -0,0 +1,335 @@
---
name: plan
description: Batch plan issue resolution using issue-plan-agent (explore + plan closed-loop)
argument-hint: "[-y|--yes] --all-pending <issue-id>[,<issue-id>,...] [--batch-size 3]"
allowed-tools: TodoWrite(*), Task(*), SlashCommand(*), AskUserQuestion(*), Bash(*), Read(*), Write(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-bind solutions without confirmation, use recommended settings.
# Issue Plan Command (/issue:plan)
## Overview
Unified planning command using **issue-plan-agent** that combines exploration and planning into a single closed-loop workflow.
**Behavior:**
- Single solution per issue → auto-bind
- Multiple solutions → return for user selection
- Agent handles file generation
## Core Guidelines
**⚠️ Data Access Principle**: Issues and solutions files can grow very large. To avoid context overflow:
| Operation | Correct | Incorrect |
|-----------|---------|-----------|
| List issues (brief) | `ccw issue list --status pending --brief` | `Read('issues.jsonl')` |
| Read issue details | `ccw issue status <id> --json` | `Read('issues.jsonl')` |
| Update status | `ccw issue update <id> --status ...` | Direct file edit |
| Bind solution | `ccw issue bind <id> <sol-id>` | Direct file edit |
**Output Options**:
- `--brief`: JSON with minimal fields (id, title, status, priority, tags)
- `--json`: Full JSON (agent use only)
**Orchestration vs Execution**:
- **Command (orchestrator)**: Use `--brief` for minimal context
- **Agent (executor)**: Fetch full details → `ccw issue status <id> --json`
**ALWAYS** use CLI commands for CRUD operations. **NEVER** read entire `issues.jsonl` or `solutions/*.jsonl` directly.
## Usage
```bash
/issue:plan [<issue-id>[,<issue-id>,...]] [FLAGS]
# Examples
/issue:plan # Default: --all-pending
/issue:plan GH-123 # Single issue
/issue:plan GH-123,GH-124,GH-125 # Batch (up to 3)
/issue:plan --all-pending # All pending issues (explicit)
# Flags
--batch-size <n> Max issues per agent batch (default: 3)
```
## Execution Process
```
Phase 1: Issue Loading & Intelligent Grouping
├─ Parse input (single, comma-separated, or --all-pending)
├─ Fetch issue metadata (ID, title, tags)
├─ Validate issues exist (create if needed)
└─ Intelligent grouping via Gemini (semantic similarity, max 3 per batch)
Phase 2: Unified Explore + Plan (issue-plan-agent)
├─ Launch issue-plan-agent per batch
├─ Agent performs:
│ ├─ ACE semantic search for each issue
│ ├─ Codebase exploration (files, patterns, dependencies)
│ ├─ Solution generation with task breakdown
│ └─ Conflict detection across issues
└─ Output: solution JSON per issue
Phase 3: Solution Registration & Binding
├─ Append solutions to solutions/{issue-id}.jsonl
├─ Single solution per issue → auto-bind
├─ Multiple candidates → AskUserQuestion to select
└─ Update issues.jsonl with bound_solution_id
Phase 4: Summary
├─ Display bound solutions
├─ Show task counts per issue
└─ Display next steps (/issue:queue)
```
## Implementation
### Phase 1: Issue Loading (Brief Info Only)
```javascript
const batchSize = flags.batchSize || 3;
let issues = []; // {id, title, tags} - brief info for grouping only
// Default to --all-pending if no input provided
const useAllPending = flags.allPending || !userInput || userInput.trim() === '';
if (useAllPending) {
// Get pending issues with brief metadata via CLI
const result = Bash(`ccw issue list --status pending,registered --json`).trim();
const parsed = result ? JSON.parse(result) : [];
issues = parsed.map(i => ({ id: i.id, title: i.title || '', tags: i.tags || [] }));
if (issues.length === 0) {
console.log('No pending issues found.');
return;
}
console.log(`Found ${issues.length} pending issues`);
} else {
// Parse comma-separated issue IDs, fetch brief metadata
const ids = userInput.includes(',')
? userInput.split(',').map(s => s.trim())
: [userInput.trim()];
for (const id of ids) {
Bash(`ccw issue init ${id} --title "Issue ${id}" 2>/dev/null || true`);
const info = Bash(`ccw issue status ${id} --json`).trim();
const parsed = info ? JSON.parse(info) : {};
issues.push({ id, title: parsed.title || '', tags: parsed.tags || [] });
}
}
// Note: Agent fetches full issue content via `ccw issue status <id> --json`
// Intelligent grouping: Analyze issues by title/tags, group semantically similar ones
// Strategy: Same module/component, related bugs, feature clusters
// Constraint: Max ${batchSize} issues per batch
console.log(`Processing ${issues.length} issues in ${batches.length} batch(es)`);
TodoWrite({
todos: batches.map((_, i) => ({
content: `Plan batch ${i+1}`,
status: 'pending',
activeForm: `Planning batch ${i+1}`
}))
});
```
### Phase 2: Unified Explore + Plan (issue-plan-agent) - PARALLEL
```javascript
Bash(`mkdir -p .workflow/issues/solutions`);
const pendingSelections = []; // Collect multi-solution issues for user selection
const agentResults = []; // Collect all agent results for conflict aggregation
// Build prompts for all batches
const agentTasks = batches.map((batch, batchIndex) => {
const issueList = batch.map(i => `- ${i.id}: ${i.title}${i.tags.length ? ` [${i.tags.join(', ')}]` : ''}`).join('\n');
const batchIds = batch.map(i => i.id);
const issuePrompt = `
## Plan Issues
**Issues** (grouped by similarity):
${issueList}
**Project Root**: ${process.cwd()}
### Project Context (MANDATORY)
1. Read: .workflow/project-tech.json (technology stack, architecture)
2. Read: .workflow/project-guidelines.json (constraints and conventions)
### Workflow
1. Fetch issue details: ccw issue status <id> --json
2. **Analyze failure history** (if issue.feedback exists):
- Extract failure details from issue.feedback (type='failure', stage='execute')
- Parse error_type, message, task_id, solution_id from content JSON
- Identify failure patterns: repeated errors, root causes, blockers
- **Constraint**: Avoid repeating failed approaches
3. Load project context files
4. Explore codebase (ACE semantic search)
5. Plan solution with tasks (schema: solution-schema.json)
- **If previous solution failed**: Reference failure analysis in solution.approach
- Add explicit verification steps to prevent same failure mode
6. **If github_url exists**: Add final task to comment on GitHub issue
7. Write solution to: .workflow/issues/solutions/{issue-id}.jsonl
8. **CRITICAL - Binding Decision**:
- Single solution → **MUST execute**: ccw issue bind <issue-id> <solution-id>
- Multiple solutions → Return pending_selection only (no bind)
### Failure-Aware Planning Rules
- **Extract failure patterns**: Parse issue.feedback where type='failure' and stage='execute'
- **Identify root causes**: Analyze error_type (test_failure, compilation, timeout, etc.)
- **Design alternative approach**: Create solution that addresses root cause
- **Add prevention steps**: Include explicit verification to catch same error earlier
- **Document lessons**: Reference previous failures in solution.approach
### Rules
- Solution ID format: SOL-{issue-id}-{uid} (uid: 4 random alphanumeric chars, e.g., a7x9)
- Single solution per issue → auto-bind via ccw issue bind
- Multiple solutions → register only, return pending_selection
- Tasks must have quantified acceptance.criteria
### Return Summary
{"bound":[{"issue_id":"...","solution_id":"...","task_count":N}],"pending_selection":[{"issue_id":"...","solutions":[{"id":"...","description":"...","task_count":N}]}]}
`;
return { batchIndex, batchIds, issuePrompt, batch };
});
// Launch agents in parallel (max 10 concurrent)
const MAX_PARALLEL = 10;
for (let i = 0; i < agentTasks.length; i += MAX_PARALLEL) {
const chunk = agentTasks.slice(i, i + MAX_PARALLEL);
const taskIds = [];
// Launch chunk in parallel
for (const { batchIndex, batchIds, issuePrompt, batch } of chunk) {
updateTodo(`Plan batch ${batchIndex + 1}`, 'in_progress');
const taskId = Task(
subagent_type="issue-plan-agent",
run_in_background=true,
description=`Explore & plan ${batch.length} issues: ${batchIds.join(', ')}`,
prompt=issuePrompt
);
taskIds.push({ taskId, batchIndex });
}
console.log(`Launched ${taskIds.length} agents (batch ${i/MAX_PARALLEL + 1}/${Math.ceil(agentTasks.length/MAX_PARALLEL)})...`);
// Collect results from this chunk
for (const { taskId, batchIndex } of taskIds) {
const result = TaskOutput(task_id=taskId, block=true);
// Extract JSON from potential markdown code blocks (agent may wrap in ```json...```)
const jsonText = extractJsonFromMarkdown(result);
let summary;
try {
summary = JSON.parse(jsonText);
} catch (e) {
console.log(`⚠ Batch ${batchIndex + 1}: Failed to parse agent result, skipping`);
updateTodo(`Plan batch ${batchIndex + 1}`, 'completed');
continue;
}
agentResults.push(summary); // Store for Phase 3 conflict aggregation
// Verify binding for bound issues (agent should have executed bind)
for (const item of summary.bound || []) {
const status = JSON.parse(Bash(`ccw issue status ${item.issue_id} --json`).trim());
if (status.bound_solution_id === item.solution_id) {
console.log(`${item.issue_id}: ${item.solution_id} (${item.task_count} tasks)`);
} else {
// Fallback: agent failed to bind, execute here
Bash(`ccw issue bind ${item.issue_id} ${item.solution_id}`);
console.log(`${item.issue_id}: ${item.solution_id} (${item.task_count} tasks) [recovered]`);
}
}
// Collect pending selections for Phase 3
for (const pending of summary.pending_selection || []) {
pendingSelections.push(pending);
}
updateTodo(`Plan batch ${batchIndex + 1}`, 'completed');
}
}
```
### Phase 3: Solution Selection (if pending)
```javascript
// Handle multi-solution issues
for (const pending of pendingSelections) {
if (pending.solutions.length === 0) continue;
const options = pending.solutions.slice(0, 4).map(sol => ({
label: `${sol.id} (${sol.task_count} tasks)`,
description: sol.description || sol.approach || 'No description'
}));
const answer = AskUserQuestion({
questions: [{
question: `Issue ${pending.issue_id}: which solution to bind?`,
header: pending.issue_id,
options: options,
multiSelect: false
}]
});
const selected = answer[Object.keys(answer)[0]];
if (!selected || selected === 'Other') continue;
const solId = selected.split(' ')[0];
Bash(`ccw issue bind ${pending.issue_id} ${solId}`);
console.log(`${pending.issue_id}: ${solId} bound`);
}
```
### Phase 4: Summary
```javascript
// Count planned issues via CLI
const planned = JSON.parse(Bash(`ccw issue list --status planned --brief`) || '[]');
const plannedCount = planned.length;
console.log(`
## Done: ${issues.length} issues → ${plannedCount} planned
Next: \`/issue:queue\`\`/issue:execute\`
`);
```
## Error Handling
| Error | Resolution |
|-------|------------|
| Issue not found | Auto-create in issues.jsonl |
| ACE search fails | Agent falls back to ripgrep |
| No solutions generated | Display error, suggest manual planning |
| User cancels selection | Skip issue, continue with others |
| File conflicts | Agent detects and suggests resolution order |
## Bash Compatibility
**Avoid**: `$(cmd)`, `$var`, `for` loops — will be escaped incorrectly
**Use**: Simple commands + `&&` chains, quote comma params `"pending,registered"`
## Quality Checklist
Before completing, verify:
- [ ] All input issues have solutions in `solutions/{issue-id}.jsonl`
- [ ] Single solution issues are auto-bound (`bound_solution_id` set)
- [ ] Multi-solution issues returned in `pending_selection` for user choice
- [ ] Each solution has executable tasks with `modification_points`
- [ ] Task acceptance criteria are quantified (not vague)
- [ ] Conflicts detected and reported (if multiple issues touch same files)
- [ ] Issue status updated to `planned` after binding
## Related Commands
- `/issue:queue` - Form execution queue from bound solutions
- `ccw issue list` - List all issues
- `ccw issue status` - View issue and solution details

View File

@@ -0,0 +1,445 @@
---
name: queue
description: Form execution queue from bound solutions using issue-queue-agent (solution-level)
argument-hint: "[-y|--yes] [--queues <n>] [--issue <id>]"
allowed-tools: TodoWrite(*), Task(*), Bash(*), Read(*), Write(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm queue formation, use recommended conflict resolutions.
# Issue Queue Command (/issue:queue)
## Overview
Queue formation command using **issue-queue-agent** that analyzes all bound solutions, resolves **inter-solution** conflicts, and creates an ordered execution queue at **solution level**.
**Design Principle**: Queue items are **solutions**, not individual tasks. Each executor receives a complete solution with all its tasks.
## Core Capabilities
- **Agent-driven**: issue-queue-agent handles all ordering logic
- **Solution-level granularity**: Queue items are solutions, not tasks
- **Conflict clarification**: High-severity conflicts prompt user decision
- Semantic priority calculation per solution (0.0-1.0)
- Parallel/Sequential group assignment for solutions
## Core Guidelines
**⚠️ Data Access Principle**: Issues and queue files can grow very large. To avoid context overflow:
| Operation | Correct | Incorrect |
|-----------|---------|-----------|
| List issues (brief) | `ccw issue list --status planned --brief` | `Read('issues.jsonl')` |
| **Batch solutions (NEW)** | `ccw issue solutions --status planned --brief` | Loop `ccw issue solution <id>` |
| List queue (brief) | `ccw issue queue --brief` | `Read('queues/*.json')` |
| Read issue details | `ccw issue status <id> --json` | `Read('issues.jsonl')` |
| Get next item | `ccw issue next --json` | `Read('queues/*.json')` |
| Update status | `ccw issue update <id> --status ...` | Direct file edit |
| Sync from queue | `ccw issue update --from-queue` | Direct file edit |
| Read solution (single) | `ccw issue solution <id> --brief` | `Read('solutions/*.jsonl')` |
**Output Options**:
- `--brief`: JSON with minimal fields (id, status, counts)
- `--json`: Full JSON (agent use only)
**Orchestration vs Execution**:
- **Command (orchestrator)**: Use `--brief` for minimal context
- **Agent (executor)**: Fetch full details → `ccw issue status <id> --json`
**ALWAYS** use CLI commands for CRUD operations. **NEVER** read entire `issues.jsonl` or `queues/*.json` directly.
## Usage
```bash
/issue:queue [FLAGS]
# Examples
/issue:queue # Form NEW queue from all bound solutions
/issue:queue --queues 3 # Form 3 parallel queues (solutions distributed)
/issue:queue --issue GH-123 # Form queue for specific issue only
/issue:queue --append GH-124 # Append to active queue
/issue:queue --list # List all queues (history)
/issue:queue --switch QUE-xxx # Switch active queue
/issue:queue --archive # Archive completed active queue
# Flags
--queues <n> Number of parallel queues (default: 1)
--issue <id> Form queue for specific issue only
--append <id> Append issue to active queue (don't create new)
--force Skip active queue check, always create new queue
# CLI subcommands (ccw issue queue ...)
ccw issue queue list List all queues with status
ccw issue queue add <issue-id> Add issue to queue (interactive if active queue exists)
ccw issue queue add <issue-id> -f Add to new queue without prompt (force)
ccw issue queue merge <src> --queue <target> Merge source queue into target queue
ccw issue queue switch <queue-id> Switch active queue
ccw issue queue archive Archive current queue
ccw issue queue delete <queue-id> Delete queue from history
```
## Execution Process
```
Phase 1: Solution Loading & Distribution
├─ Load issues.jsonl, filter by status='planned' + bound_solution_id
├─ Read solutions/{issue-id}.jsonl, find bound solution
├─ Extract files_touched from task modification_points
├─ Build solution objects array
└─ If --queues > 1: Partition solutions into N groups (minimize cross-group file conflicts)
Phase 2-4: Agent-Driven Queue Formation (issue-queue-agent)
├─ Generate N queue IDs (QUE-xxx-1, QUE-xxx-2, ...)
├─ If --queues == 1: Launch single issue-queue-agent
├─ If --queues > 1: Launch N issue-queue-agents IN PARALLEL
├─ Each agent performs:
│ ├─ Conflict analysis (5 types via Gemini CLI)
│ ├─ Build dependency DAG from conflicts
│ ├─ Calculate semantic priority per solution
│ └─ Assign execution groups (parallel/sequential)
└─ Each agent writes: queue JSON + index update (NOT active yet)
Phase 5: Conflict Clarification (if needed)
├─ Collect `clarifications` arrays from all agents
├─ If clarifications exist → AskUserQuestion (batched)
├─ Pass user decisions back to respective agents (resume)
└─ Agents update queues with resolved conflicts
Phase 6: Status Update & Summary
├─ Update issue statuses to 'queued'
└─ Display new queue summary (N queues)
Phase 7: Active Queue Check & Decision (REQUIRED)
├─ Read queue index: ccw issue queue list --brief
├─ Get generated queue ID from agent output
├─ If NO active queue exists:
│ ├─ Set generated queue as active_queue_id
│ ├─ Update index.json
│ └─ Display: "Queue created and activated"
└─ If active queue exists with items:
├─ Display both queues to user
├─ Use AskUserQuestion to prompt:
│ ├─ "Use new queue (keep existing)" → Set new as active, keep old inactive
│ ├─ "Merge: add new items to existing" → Merge new → existing, delete new
│ ├─ "Merge: add existing items to new" → Merge existing → new, archive old
│ └─ "Cancel" → Delete new queue, keep existing active
└─ Execute chosen action
```
## Implementation
### Phase 1: Solution Loading & Distribution
**Data Loading:**
- Use `ccw issue solutions --status planned --brief` to get all planned issues with solutions in **one call**
- Returns: Array of `{ issue_id, solution_id, is_bound, task_count, files_touched[], priority }`
- If no bound solutions found → display message, suggest `/issue:plan`
**Build Solution Objects:**
```javascript
// Single CLI call replaces N individual queries
const result = Bash(`ccw issue solutions --status planned --brief`).trim();
const solutions = result ? JSON.parse(result) : [];
if (solutions.length === 0) {
console.log('No bound solutions found. Run /issue:plan first.');
return;
}
// solutions already in correct format:
// { issue_id, solution_id, is_bound, task_count, files_touched[], priority }
```
**Multi-Queue Distribution** (if `--queues > 1`):
- Use `files_touched` from brief output for partitioning
- Group solutions with overlapping files into same queue
**Output:** Array of solution objects (or N arrays if multi-queue)
### Phase 2-4: Agent-Driven Queue Formation
**Generate Queue IDs** (command layer, pass to agent):
```javascript
const timestamp = new Date().toISOString().replace(/[-:T]/g, '').slice(0, 14);
const numQueues = args.queues || 1;
const queueIds = numQueues === 1
? [`QUE-${timestamp}`]
: Array.from({length: numQueues}, (_, i) => `QUE-${timestamp}-${i + 1}`);
```
**Agent Prompt** (same for each queue, with assigned solutions):
```
## Order Solutions into Execution Queue
**Queue ID**: ${queueId}
**Solutions**: ${solutions.length} from ${issues.length} issues
**Project Root**: ${cwd}
**Queue Index**: ${queueIndex} of ${numQueues}
### Input
${JSON.stringify(solutions)}
// Each object: { issue_id, solution_id, task_count, files_touched[], priority }
### Workflow
Step 1: Build dependency graph from solutions (nodes=solutions, edges=file conflicts via files_touched)
Step 2: Use Gemini CLI for conflict analysis (5 types: file, API, data, dependency, architecture)
Step 3: For high-severity conflicts without clear resolution → add to `clarifications`
Step 4: Calculate semantic priority (base from issue priority + task_count boost)
Step 5: Assign execution groups: P* (parallel, no overlaps) / S* (sequential, shared files)
Step 6: Write queue JSON + update index
### Output Requirements
**Write files** (exactly 2):
- `.workflow/issues/queues/${queueId}.json` - Full queue with solutions, conflicts, groups
- `.workflow/issues/queues/index.json` - Update with new queue entry
**Return JSON**:
\`\`\`json
{
"queue_id": "${queueId}",
"total_solutions": N,
"total_tasks": N,
"execution_groups": [{"id": "P1", "type": "parallel", "count": N}],
"issues_queued": ["ISS-xxx"],
"clarifications": [{"conflict_id": "CFT-1", "question": "...", "options": [...]}]
}
\`\`\`
### Rules
- Solution granularity (NOT individual tasks)
- Queue Item ID format: S-1, S-2, S-3, ...
- Use provided Queue ID (do NOT generate new)
- `clarifications` only present if high-severity unresolved conflicts exist
- Use `files_touched` from input (already extracted by orchestrator)
### Done Criteria
- [ ] Queue JSON written with all solutions ordered
- [ ] Index updated with active_queue_id
- [ ] No circular dependencies
- [ ] Parallel groups have no file overlaps
- [ ] Return JSON matches required shape
```
**Launch Agents** (parallel if multi-queue):
```javascript
const numQueues = args.queues || 1;
if (numQueues === 1) {
// Single queue: single agent call
const result = Task(
subagent_type="issue-queue-agent",
prompt=buildPrompt(queueIds[0], solutions),
description=`Order ${solutions.length} solutions`
);
} else {
// Multi-queue: parallel agent calls (single message with N Task calls)
const agentPromises = solutionGroups.map((group, i) =>
Task(
subagent_type="issue-queue-agent",
prompt=buildPrompt(queueIds[i], group, i + 1, numQueues),
description=`Queue ${i + 1}/${numQueues}: ${group.length} solutions`
)
);
// All agents launched in parallel via single message with multiple Task tool calls
}
```
**Multi-Queue Index Update:**
- First queue sets `active_queue_id`
- All queues added to `queues` array with `queue_group` field linking them
### Phase 5: Conflict Clarification
**Collect Agent Results** (multi-queue):
```javascript
// Collect clarifications from all agents
const allClarifications = results.flatMap((r, i) =>
(r.clarifications || []).map(c => ({ ...c, queue_id: queueIds[i], agent_id: agentIds[i] }))
);
```
**Check Agent Return:**
- Parse agent result JSON (or all results if multi-queue)
- If any `clarifications` array exists and non-empty → user decision required
**Clarification Flow:**
```javascript
if (allClarifications.length > 0) {
for (const clarification of allClarifications) {
// Present to user via AskUserQuestion
const answer = AskUserQuestion({
questions: [{
question: `[${clarification.queue_id}] ${clarification.question}`,
header: clarification.conflict_id,
options: clarification.options,
multiSelect: false
}]
});
// Resume respective agent with user decision
Task(
subagent_type="issue-queue-agent",
resume=clarification.agent_id,
prompt=`Conflict ${clarification.conflict_id} resolved: ${answer.selected}`
);
}
}
```
### Phase 6: Status Update & Summary
**Status Update** (MUST use CLI command, NOT direct file operations):
```bash
# Option 1: Batch update from queue (recommended)
ccw issue update --from-queue [queue-id] --json
ccw issue update --from-queue --json # Use active queue
ccw issue update --from-queue QUE-xxx --json # Use specific queue
# Option 2: Individual issue update
ccw issue update <issue-id> --status queued
```
**⚠️ IMPORTANT**: Do NOT directly modify `issues.jsonl`. Always use CLI command to ensure proper validation and history tracking.
**Output** (JSON):
```json
{
"success": true,
"queue_id": "QUE-xxx",
"queued": ["ISS-001", "ISS-002"],
"queued_count": 2,
"unplanned": ["ISS-003"],
"unplanned_count": 1
}
```
**Behavior:**
- Updates issues in queue to `status: 'queued'` (skips already queued/executing/completed)
- Identifies planned issues with `bound_solution_id` NOT in queue → `unplanned` array
- Optional `queue-id`: defaults to active queue if omitted
**Summary Output:**
- Display queue ID, solution count, task count
- Show unplanned issues (planned but NOT in queue)
- Show next step: `/issue:execute`
### Phase 7: Active Queue Check & Decision
**After agent completes Phase 1-6, check for active queue:**
```bash
ccw issue queue list --brief
```
**Decision:**
- If `active_queue_id` is null → `ccw issue queue switch <new-queue-id>` (activate new queue)
- If active queue exists → Use **AskUserQuestion** to prompt user
**AskUserQuestion:**
```javascript
AskUserQuestion({
questions: [{
question: "Active queue exists. How would you like to proceed?",
header: "Queue Action",
options: [
{ label: "Merge into existing queue", description: "Add new items to active queue, delete new queue" },
{ label: "Use new queue", description: "Switch to new queue, keep existing in history" },
{ label: "Cancel", description: "Delete new queue, keep existing active" }
],
multiSelect: false
}]
})
```
**Action Commands:**
| User Choice | Commands |
|-------------|----------|
| **Merge into existing** | `ccw issue queue merge <new-queue-id> --queue <active-queue-id>` then `ccw issue queue delete <new-queue-id>` |
| **Use new queue** | `ccw issue queue switch <new-queue-id>` |
| **Cancel** | `ccw issue queue delete <new-queue-id>` |
## Storage Structure (Queue History)
```
.workflow/issues/
├── issues.jsonl # All issues (one per line)
├── queues/ # Queue history directory
│ ├── index.json # Queue index (active + history)
│ ├── {queue-id}.json # Individual queue files
│ └── ...
└── solutions/
├── {issue-id}.jsonl # Solutions for issue
└── ...
```
### Queue Index Schema
```json
{
"active_queue_id": "QUE-20251227-143000",
"active_queue_group": "QGR-20251227-143000",
"queues": [
{
"id": "QUE-20251227-143000-1",
"queue_group": "QGR-20251227-143000",
"queue_index": 1,
"total_queues": 3,
"status": "active",
"issue_ids": ["ISS-xxx", "ISS-yyy"],
"total_solutions": 3,
"completed_solutions": 1,
"created_at": "2025-12-27T14:30:00Z"
}
]
}
```
**Multi-Queue Fields:**
- `queue_group`: Links queues created in same batch (format: `QGR-{timestamp}`)
- `queue_index`: Position in group (1-based)
- `total_queues`: Total queues in group
- `active_queue_group`: Current active group (for multi-queue execution)
**Note**: Queue file schema is produced by `issue-queue-agent`. See agent documentation for details.
## Error Handling
| Error | Resolution |
|-------|------------|
| No bound solutions | Display message, suggest /issue:plan |
| Circular dependency | List cycles, abort queue formation |
| High-severity conflict | Return `clarifications`, prompt user decision |
| User cancels clarification | Abort queue formation |
| **index.json not updated** | Auto-fix: Set active_queue_id to new queue |
| **Queue file missing solutions** | Abort with error, agent must regenerate |
| **User cancels queue add** | Display message, return without changes |
| **Merge with empty source** | Skip merge, display warning |
| **All items duplicate** | Skip merge, display "All items already exist" |
## Quality Checklist
Before completing, verify:
- [ ] All planned issues with `bound_solution_id` are included
- [ ] Queue JSON written to `queues/{queue-id}.json` (N files if multi-queue)
- [ ] Index updated in `queues/index.json` with `active_queue_id`
- [ ] Multi-queue: All queues share same `queue_group`
- [ ] No circular dependencies in solution DAG
- [ ] All conflicts resolved (auto or via user clarification)
- [ ] Parallel groups have no file overlaps
- [ ] Cross-queue: No file overlaps between queues
- [ ] Issue statuses updated to `queued`
## Related Commands
- `/issue:execute` - Execute queue with codex
- `ccw issue queue list` - View current queue
- `ccw issue update --from-queue [queue-id]` - Sync issue statuses from queue

View File

@@ -0,0 +1,773 @@
---
name: swagger-docs
description: Generate complete Swagger/OpenAPI documentation following RESTful standards with global security, API details, error codes, and validation tests
argument-hint: "[path] [--tool <gemini|qwen|codex>] [--format <yaml|json>] [--version <v3.0|v3.1>] [--lang <zh|en>]"
---
# Swagger API Documentation Workflow (/memory:swagger-docs)
## Overview
Professional Swagger/OpenAPI documentation generator that strictly follows RESTful API design standards to produce enterprise-grade API documentation.
**Core Features**:
- **RESTful Standards**: Strict adherence to REST architecture and HTTP semantics
- **Global Security**: Unified Authorization Token validation mechanism
- **Complete API Docs**: Descriptions, methods, URLs, parameters for each endpoint
- **Organized Structure**: Clear directory hierarchy by business domain
- **Detailed Fields**: Type, required, example, description for each field
- **Error Code Standards**: Unified error response format and code definitions
- **Validation Tests**: Boundary conditions and exception handling tests
**Output Structure** (--lang zh):
```
.workflow/docs/{project_name}/api/
├── swagger.yaml # Main OpenAPI spec file
├── 概述/
│ ├── README.md # API overview
│ ├── 认证说明.md # Authentication guide
│ ├── 错误码规范.md # Error code definitions
│ └── 版本历史.md # Version history
├── 用户模块/ # Grouped by business domain
│ ├── 用户认证.md
│ ├── 用户管理.md
│ └── 权限控制.md
├── 业务模块/
│ └── ...
└── 测试报告/
├── 接口测试.md # API test results
└── 边界测试.md # Boundary condition tests
```
**Output Structure** (--lang en):
```
.workflow/docs/{project_name}/api/
├── swagger.yaml # Main OpenAPI spec file
├── overview/
│ ├── README.md # API overview
│ ├── authentication.md # Authentication guide
│ ├── error-codes.md # Error code definitions
│ └── changelog.md # Version history
├── users/ # Grouped by business domain
│ ├── authentication.md
│ ├── management.md
│ └── permissions.md
├── orders/
│ └── ...
└── test-reports/
├── api-tests.md # API test results
└── boundary-tests.md # Boundary condition tests
```
## Parameters
```bash
/memory:swagger-docs [path] [--tool <gemini|qwen|codex>] [--format <yaml|json>] [--version <v3.0|v3.1>] [--lang <zh|en>]
```
- **path**: API source code directory (default: current directory)
- **--tool**: CLI tool selection (default: gemini)
- `gemini`: Comprehensive analysis, pattern recognition
- `qwen`: Architecture analysis, system design
- `codex`: Implementation validation, code quality
- **--format**: OpenAPI spec format (default: yaml)
- `yaml`: YAML format (recommended, better readability)
- `json`: JSON format
- **--version**: OpenAPI version (default: v3.0)
- `v3.0`: OpenAPI 3.0.x
- `v3.1`: OpenAPI 3.1.0 (supports JSON Schema 2020-12)
- **--lang**: Documentation language (default: zh)
- `zh`: Chinese documentation with Chinese directory names
- `en`: English documentation with English directory names
## Planning Workflow
### Phase 1: Initialize Session
```bash
# Get project info
bash(pwd && basename "$(pwd)" && git rev-parse --show-toplevel 2>/dev/null || pwd && date +%Y%m%d-%H%M%S)
```
```javascript
// Create swagger-docs session
SlashCommand(command="/workflow:session:start --type swagger-docs --new \"{project_name}-swagger-{timestamp}\"")
// Parse output to get sessionId
```
```bash
# Update workflow-session.json
bash(jq '. + {"target_path":"{target_path}","project_root":"{project_root}","project_name":"{project_name}","format":"yaml","openapi_version":"3.0.3","lang":"{lang}","tool":"gemini"}' .workflow/active/{sessionId}/workflow-session.json > tmp.json && mv tmp.json .workflow/active/{sessionId}/workflow-session.json)
```
### Phase 2: Scan API Endpoints
**Discovery Patterns**: Auto-detect framework signatures and API definition styles.
**Supported Frameworks**:
| Framework | Detection Pattern | Example |
|-----------|-------------------|---------|
| Express.js | `router.get/post/put/delete` | `router.get('/users/:id')` |
| Fastify | `fastify.route`, `@Route` | `fastify.get('/api/users')` |
| NestJS | `@Controller`, `@Get/@Post` | `@Get('users/:id')` |
| Koa | `router.get`, `ctx.body` | `router.get('/users')` |
| Hono | `app.get/post`, `c.json` | `app.get('/users/:id')` |
| FastAPI | `@app.get`, `@router.post` | `@app.get("/users/{id}")` |
| Flask | `@app.route`, `@bp.route` | `@app.route('/users')` |
| Spring | `@GetMapping`, `@PostMapping` | `@GetMapping("/users/{id}")` |
| Go Gin | `r.GET`, `r.POST` | `r.GET("/users/:id")` |
| Go Chi | `r.Get`, `r.Post` | `r.Get("/users/{id}")` |
**Commands**:
```bash
# 1. Detect API framework type
bash(
if rg -q "@Controller|@Get|@Post|@Put|@Delete" --type ts 2>/dev/null; then echo "NESTJS";
elif rg -q "router\.(get|post|put|delete|patch)" --type ts --type js 2>/dev/null; then echo "EXPRESS";
elif rg -q "fastify\.(get|post|route)" --type ts --type js 2>/dev/null; then echo "FASTIFY";
elif rg -q "@app\.(get|post|put|delete)" --type py 2>/dev/null; then echo "FASTAPI";
elif rg -q "@GetMapping|@PostMapping|@RequestMapping" --type java 2>/dev/null; then echo "SPRING";
elif rg -q 'r\.(GET|POST|PUT|DELETE)' --type go 2>/dev/null; then echo "GO_GIN";
else echo "UNKNOWN"; fi
)
# 2. Scan all API endpoint definitions
bash(rg -n "(router|app|fastify)\.(get|post|put|delete|patch)|@(Get|Post|Put|Delete|Patch|Controller|RequestMapping)" --type ts --type js --type py --type java --type go -g '!*.test.*' -g '!*.spec.*' -g '!node_modules/**' 2>/dev/null | head -200)
# 3. Extract route paths
bash(rg -o "['\"](/api)?/[a-zA-Z0-9/:_-]+['\"]" --type ts --type js --type py -g '!*.test.*' 2>/dev/null | sort -u | head -100)
# 4. Detect existing OpenAPI/Swagger files
bash(find . -type f \( -name "swagger.yaml" -o -name "swagger.json" -o -name "openapi.yaml" -o -name "openapi.json" \) ! -path "*/node_modules/*" 2>/dev/null)
# 5. Extract DTO/Schema definitions
bash(rg -n "export (interface|type|class).*Dto|@ApiProperty|class.*Schema" --type ts -g '!*.test.*' 2>/dev/null | head -100)
```
**Data Processing**: Parse outputs, use **Write tool** to create `${session_dir}/.process/swagger-planning-data.json`:
```json
{
"metadata": {
"generated_at": "2025-01-01T12:00:00+08:00",
"project_name": "project_name",
"project_root": "/path/to/project",
"openapi_version": "3.0.3",
"format": "yaml",
"lang": "zh"
},
"framework": {
"type": "NESTJS",
"detected_patterns": ["@Controller", "@Get", "@Post"],
"base_path": "/api/v1"
},
"endpoints": [
{
"file": "src/modules/users/users.controller.ts",
"line": 25,
"method": "GET",
"path": "/api/v1/users/:id",
"handler": "getUser",
"controller": "UsersController"
}
],
"existing_specs": {
"found": false,
"files": []
},
"dto_schemas": [
{
"name": "CreateUserDto",
"file": "src/modules/users/dto/create-user.dto.ts",
"properties": ["email", "password", "name"]
}
],
"statistics": {
"total_endpoints": 45,
"by_method": {"GET": 20, "POST": 15, "PUT": 5, "DELETE": 5},
"by_module": {"users": 12, "auth": 8, "orders": 15, "products": 10}
}
}
```
### Phase 3: Analyze API Structure
**Commands**:
```bash
# 1. Analyze controller/route file structure
bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.endpoints[].file' | sort -u | head -20)
# 2. Extract request/response types
bash(for f in $(jq -r '.dto_schemas[].file' ${session_dir}/.process/swagger-planning-data.json | head -20); do echo "=== $f ===" && cat "$f" 2>/dev/null; done)
# 3. Analyze authentication middleware
bash(rg -n "auth|guard|middleware|jwt|bearer|token" -i --type ts --type js -g '!*.test.*' -g '!node_modules/**' 2>/dev/null | head -50)
# 4. Detect error handling patterns
bash(rg -n "HttpException|BadRequest|Unauthorized|Forbidden|NotFound|throw new" --type ts --type js -g '!*.test.*' 2>/dev/null | head -50)
```
**Deep Analysis via Gemini CLI**:
```bash
ccw cli -p "
PURPOSE: Analyze API structure and generate OpenAPI specification outline for comprehensive documentation
TASK:
• Parse all API endpoints and identify business module boundaries
• Extract request parameters, request bodies, and response formats
• Identify authentication mechanisms and security requirements
• Discover error handling patterns and error codes
• Map endpoints to logical module groups
MODE: analysis
CONTEXT: @src/**/*.controller.ts @src/**/*.routes.ts @src/**/*.dto.ts @src/**/middleware/**/*
EXPECTED: JSON format API structure analysis report with modules, endpoints, security schemes, and error codes
CONSTRAINTS: Strict RESTful standards | Identify all public endpoints | Document output language: {lang}
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {project_root}
```
**Update swagger-planning-data.json** with analysis results:
```json
{
"api_structure": {
"modules": [
{
"name": "Users",
"name_zh": "用户模块",
"base_path": "/api/v1/users",
"endpoints": [
{
"path": "/api/v1/users",
"method": "GET",
"operation_id": "listUsers",
"summary": "List all users",
"summary_zh": "获取用户列表",
"description": "Paginated list of system users with filtering by status and role",
"description_zh": "分页获取系统用户列表,支持按状态、角色筛选",
"tags": ["User Management"],
"tags_zh": ["用户管理"],
"security": ["bearerAuth"],
"parameters": {
"query": ["page", "limit", "status", "role"]
},
"responses": {
"200": "UserListResponse",
"401": "UnauthorizedError",
"403": "ForbiddenError"
}
}
]
}
],
"security_schemes": {
"bearerAuth": {
"type": "http",
"scheme": "bearer",
"bearerFormat": "JWT",
"description": "JWT Token authentication. Add Authorization: Bearer <token> to request header"
}
},
"error_codes": [
{"code": "AUTH_001", "status": 401, "message": "Invalid or expired token", "message_zh": "Token 无效或已过期"},
{"code": "AUTH_002", "status": 401, "message": "Authentication required", "message_zh": "未提供认证信息"},
{"code": "AUTH_003", "status": 403, "message": "Insufficient permissions", "message_zh": "权限不足"}
]
}
}
```
### Phase 4: Task Decomposition
**Task Hierarchy**:
```
Level 1: Infrastructure Tasks (Parallel)
├─ IMPL-001: Generate main OpenAPI spec file (swagger.yaml)
├─ IMPL-002: Generate global security config and auth documentation
└─ IMPL-003: Generate unified error code specification
Level 2: Module Documentation Tasks (Parallel, by business module)
├─ IMPL-004: Users module API documentation
├─ IMPL-005: Auth module API documentation
├─ IMPL-006: Business module N API documentation
└─ ...
Level 3: Aggregation Tasks (Depends on Level 1-2)
├─ IMPL-N+1: Generate API overview and navigation
└─ IMPL-N+2: Generate version history and changelog
Level 4: Validation Tasks (Depends on Level 1-3)
├─ IMPL-N+3: API endpoint validation tests
└─ IMPL-N+4: Boundary condition tests
```
**Grouping Strategy**:
1. Group by business module (users, orders, products, etc.)
2. Maximum 10 endpoints per task
3. Large modules (>10 endpoints) split by submodules
**Commands**:
```bash
# 1. Count endpoints by module
bash(cat ${session_dir}/.process/swagger-planning-data.json | jq '.statistics.by_module')
# 2. Calculate task groupings
bash(cat ${session_dir}/.process/swagger-planning-data.json | jq -r '.api_structure.modules[] | "\(.name):\(.endpoints | length)"')
```
**Data Processing**: Use **Edit tool** to update `swagger-planning-data.json` with task groups:
```json
{
"task_groups": {
"level1_count": 3,
"level2_count": 5,
"total_count": 12,
"assignments": [
{"task_id": "IMPL-001", "level": 1, "type": "openapi-spec", "title": "Generate OpenAPI main spec file"},
{"task_id": "IMPL-002", "level": 1, "type": "security", "title": "Generate global security config"},
{"task_id": "IMPL-003", "level": 1, "type": "error-codes", "title": "Generate error code specification"},
{"task_id": "IMPL-004", "level": 2, "type": "module-doc", "module": "users", "endpoint_count": 12},
{"task_id": "IMPL-005", "level": 2, "type": "module-doc", "module": "auth", "endpoint_count": 8}
]
}
}
```
### Phase 5: Generate Task JSONs
**Generation Process**:
1. Read configuration values from workflow-session.json
2. Read task groups from swagger-planning-data.json
3. Generate Level 1 tasks (infrastructure)
4. Generate Level 2 tasks (by module)
5. Generate Level 3-4 tasks (aggregation and validation)
## Task Templates
### Level 1-1: OpenAPI Main Spec File
```json
{
"id": "IMPL-001",
"title": "Generate OpenAPI main specification file",
"status": "pending",
"meta": {
"type": "swagger-openapi-spec",
"agent": "@doc-generator",
"tool": "gemini",
"priority": "critical"
},
"context": {
"requirements": [
"Generate OpenAPI 3.0.3 compliant swagger.yaml",
"Include complete info, servers, tags, paths, components definitions",
"Follow RESTful design standards, use {lang} for descriptions"
],
"precomputed_data": {
"planning_data": "${session_dir}/.process/swagger-planning-data.json"
}
},
"flow_control": {
"pre_analysis": [
{
"step": "load_analysis_data",
"action": "Load API analysis data",
"commands": [
"bash(cat ${session_dir}/.process/swagger-planning-data.json)"
],
"output_to": "api_analysis"
}
],
"implementation_approach": [
{
"step": 1,
"title": "Generate OpenAPI spec file",
"description": "Create complete swagger.yaml specification file",
"cli_prompt": "PURPOSE: Generate OpenAPI 3.0.3 specification file from analyzed API structure\nTASK:\n• Define openapi version: 3.0.3\n• Define info: title, description, version, contact, license\n• Define servers: development, staging, production environments\n• Define tags: organized by business modules\n• Define paths: all API endpoints with complete specifications\n• Define components: schemas, securitySchemes, parameters, responses\nMODE: write\nCONTEXT: @[api_analysis]\nEXPECTED: Complete swagger.yaml file following OpenAPI 3.0.3 specification\nCONSTRAINTS: Use {lang} for all descriptions | Strict RESTful standards\n--rule documentation-swagger-api",
"output": "swagger.yaml"
}
],
"target_files": [
".workflow/docs/${project_name}/api/swagger.yaml"
]
}
}
```
### Level 1-2: Global Security Configuration
```json
{
"id": "IMPL-002",
"title": "Generate global security configuration and authentication guide",
"status": "pending",
"meta": {
"type": "swagger-security",
"agent": "@doc-generator",
"tool": "gemini"
},
"context": {
"requirements": [
"Document Authorization header format in detail",
"Describe token acquisition, refresh, and expiration mechanisms",
"List permission requirements for each endpoint"
]
},
"flow_control": {
"pre_analysis": [
{
"step": "analyze_auth",
"command": "bash(rg -n 'auth|guard|jwt|bearer' -i --type ts -g '!*.test.*' 2>/dev/null | head -50)",
"output_to": "auth_patterns"
}
],
"implementation_approach": [
{
"step": 1,
"title": "Generate authentication documentation",
"cli_prompt": "PURPOSE: Generate comprehensive authentication documentation for API security\nTASK:\n• Document authentication mechanism: JWT Bearer Token\n• Explain header format: Authorization: Bearer <token>\n• Describe token lifecycle: acquisition, refresh, expiration handling\n• Define permission levels: public, user, admin, super_admin\n• Document authentication failure responses: 401/403 error handling\nMODE: write\nCONTEXT: @[auth_patterns] @src/**/auth/**/* @src/**/guard/**/*\nEXPECTED: Complete authentication guide in {lang}\nCONSTRAINTS: Include code examples | Clear step-by-step instructions\n--rule development-feature",
"output": "{auth_doc_name}"
}
],
"target_files": [
".workflow/docs/${project_name}/api/{overview_dir}/{auth_doc_name}"
]
}
}
```
### Level 1-3: Unified Error Code Specification
```json
{
"id": "IMPL-003",
"title": "Generate unified error code specification",
"status": "pending",
"meta": {
"type": "swagger-error-codes",
"agent": "@doc-generator",
"tool": "gemini"
},
"context": {
"requirements": [
"Define unified error response format",
"Create categorized error code system (auth, business, system)",
"Provide detailed description and examples for each error code"
]
},
"flow_control": {
"implementation_approach": [
{
"step": 1,
"title": "Generate error code specification document",
"cli_prompt": "PURPOSE: Generate comprehensive error code specification for consistent API error handling\nTASK:\n• Define error response format: {code, message, details, timestamp}\n• Document authentication errors (AUTH_xxx): 401/403 series\n• Document parameter errors (PARAM_xxx): 400 series\n• Document business errors (BIZ_xxx): business logic errors\n• Document system errors (SYS_xxx): 500 series\n• For each error code: HTTP status, error message, possible causes, resolution suggestions\nMODE: write\nCONTEXT: @src/**/*.exception.ts @src/**/*.filter.ts\nEXPECTED: Complete error code specification in {lang} with tables and examples\nCONSTRAINTS: Include response examples | Clear categorization\n--rule development-feature",
"output": "{error_doc_name}"
}
],
"target_files": [
".workflow/docs/${project_name}/api/{overview_dir}/{error_doc_name}"
]
}
}
```
### Level 2: Module API Documentation (Template)
```json
{
"id": "IMPL-${module_task_id}",
"title": "Generate ${module_name} API documentation",
"status": "pending",
"depends_on": ["IMPL-001", "IMPL-002", "IMPL-003"],
"meta": {
"type": "swagger-module-doc",
"agent": "@doc-generator",
"tool": "gemini",
"module": "${module_name}",
"endpoint_count": "${endpoint_count}"
},
"context": {
"requirements": [
"Complete documentation for all endpoints in this module",
"Each endpoint: description, method, URL, parameters, responses",
"Include success and failure response examples",
"Mark API version and last update time"
],
"focus_paths": ["${module_source_paths}"]
},
"flow_control": {
"pre_analysis": [
{
"step": "load_module_endpoints",
"action": "Load module endpoint information",
"commands": [
"bash(cat ${session_dir}/.process/swagger-planning-data.json | jq '.api_structure.modules[] | select(.name == \"${module_name}\")')"
],
"output_to": "module_endpoints"
},
{
"step": "read_source_files",
"action": "Read module source files",
"commands": [
"bash(cat ${module_source_files})"
],
"output_to": "source_code"
}
],
"implementation_approach": [
{
"step": 1,
"title": "Generate module API documentation",
"description": "Generate complete API documentation for ${module_name}",
"cli_prompt": "PURPOSE: Generate complete RESTful API documentation for ${module_name} module\nTASK:\n• Create module overview: purpose, use cases, prerequisites\n• Generate endpoint index: grouped by functionality\n• For each endpoint document:\n - Functional description: purpose and business context\n - Request method: GET/POST/PUT/DELETE\n - URL path: complete API path\n - Request headers: Authorization and other required headers\n - Path parameters: {id} and other path variables\n - Query parameters: pagination, filters, etc.\n - Request body: JSON Schema format\n - Response body: success and error responses\n - Field description table: type, required, example, description\n• Add usage examples: cURL, JavaScript, Python\n• Add version info: v1.0.0, last updated date\nMODE: write\nCONTEXT: @[module_endpoints] @[source_code]\nEXPECTED: Complete module API documentation in {lang} with all endpoints fully documented\nCONSTRAINTS: RESTful standards | Include all response codes\n--rule documentation-swagger-api",
"output": "${module_doc_name}"
}
],
"target_files": [
".workflow/docs/${project_name}/api/${module_dir}/${module_doc_name}"
]
}
}
```
### Level 3: API Overview and Navigation
```json
{
"id": "IMPL-${overview_task_id}",
"title": "Generate API overview and navigation",
"status": "pending",
"depends_on": ["IMPL-001", "...", "IMPL-${last_module_task_id}"],
"meta": {
"type": "swagger-overview",
"agent": "@doc-generator",
"tool": "gemini"
},
"flow_control": {
"pre_analysis": [
{
"step": "load_all_docs",
"command": "bash(find .workflow/docs/${project_name}/api -type f -name '*.md' ! -path '*/{overview_dir}/*' | xargs cat)",
"output_to": "all_module_docs"
}
],
"implementation_approach": [
{
"step": 1,
"title": "Generate API overview",
"cli_prompt": "PURPOSE: Generate API overview document with navigation and quick start guide\nTASK:\n• Create introduction: system features, tech stack, version\n• Write quick start guide: authentication, first request example\n• Build module navigation: categorized links to all modules\n• Document environment configuration: development, staging, production\n• List SDKs and tools: client libraries, Postman collection\nMODE: write\nCONTEXT: @[all_module_docs] @.workflow/docs/${project_name}/api/swagger.yaml\nEXPECTED: Complete API overview in {lang} with navigation links\nCONSTRAINTS: Clear structure | Quick start focus\n--rule development-feature",
"output": "README.md"
}
],
"target_files": [
".workflow/docs/${project_name}/api/{overview_dir}/README.md"
]
}
}
```
### Level 4: Validation Tasks
```json
{
"id": "IMPL-${test_task_id}",
"title": "API endpoint validation tests",
"status": "pending",
"depends_on": ["IMPL-${overview_task_id}"],
"meta": {
"type": "swagger-validation",
"agent": "@test-fix-agent",
"tool": "codex"
},
"context": {
"requirements": [
"Validate accessibility of all endpoints",
"Test various boundary conditions",
"Verify exception handling"
]
},
"flow_control": {
"pre_analysis": [
{
"step": "load_swagger_spec",
"command": "bash(cat .workflow/docs/${project_name}/api/swagger.yaml)",
"output_to": "swagger_spec"
}
],
"implementation_approach": [
{
"step": 1,
"title": "Generate test report",
"cli_prompt": "PURPOSE: Generate comprehensive API test validation report\nTASK:\n• Document test environment configuration\n• Calculate endpoint coverage statistics\n• Report test results: pass/fail counts\n• Document boundary tests: parameter limits, null values, special characters\n• Document exception tests: auth failures, permission denied, resource not found\n• List issues found with recommendations\nMODE: write\nCONTEXT: @[swagger_spec]\nEXPECTED: Complete test report in {lang} with detailed results\nCONSTRAINTS: Include test cases | Clear pass/fail status\n--rule development-tests",
"output": "{test_doc_name}"
}
],
"target_files": [
".workflow/docs/${project_name}/api/{test_dir}/{test_doc_name}"
]
}
}
```
## Language-Specific Directory Mapping
| Component | --lang zh | --lang en |
|-----------|-----------|-----------|
| Overview dir | 概述 | overview |
| Auth doc | 认证说明.md | authentication.md |
| Error doc | 错误码规范.md | error-codes.md |
| Changelog | 版本历史.md | changelog.md |
| Users module | 用户模块 | users |
| Orders module | 订单模块 | orders |
| Products module | 商品模块 | products |
| Test dir | 测试报告 | test-reports |
| API test doc | 接口测试.md | api-tests.md |
| Boundary test doc | 边界测试.md | boundary-tests.md |
## API Documentation Template
### Single Endpoint Format
Each endpoint must include:
```markdown
### Get User Details
**Description**: Retrieve detailed user information by ID, including profile and permissions.
**Endpoint Info**:
| Property | Value |
|----------|-------|
| Method | GET |
| URL | `/api/v1/users/{id}` |
| Version | v1.0.0 |
| Updated | 2025-01-01 |
| Auth | Bearer Token |
| Permission | user / admin |
**Request Headers**:
| Field | Type | Required | Example | Description |
|-------|------|----------|---------|-------------|
| Authorization | string | Yes | `Bearer eyJhbGc...` | JWT Token |
| Content-Type | string | No | `application/json` | Request content type |
**Path Parameters**:
| Field | Type | Required | Example | Description |
|-------|------|----------|---------|-------------|
| id | string | Yes | `usr_123456` | Unique user identifier |
**Query Parameters**:
| Field | Type | Required | Default | Example | Description |
|-------|------|----------|---------|---------|-------------|
| include | string | No | - | `roles,permissions` | Related data to include |
**Success Response** (200 OK):
```json
{
"code": 0,
"message": "success",
"data": {
"id": "usr_123456",
"email": "user@example.com",
"name": "John Doe",
"status": "active",
"roles": ["user"],
"created_at": "2025-01-01T00:00:00Z",
"updated_at": "2025-01-01T00:00:00Z"
},
"timestamp": "2025-01-01T12:00:00Z"
}
```
**Response Fields**:
| Field | Type | Description |
|-------|------|-------------|
| code | integer | Business status code, 0 = success |
| message | string | Response message |
| data.id | string | Unique user identifier |
| data.email | string | User email address |
| data.name | string | User display name |
| data.status | string | User status: active/inactive/suspended |
| data.roles | array | User role list |
| data.created_at | string | Creation timestamp (ISO 8601) |
| data.updated_at | string | Last update timestamp (ISO 8601) |
**Error Responses**:
| Status | Code | Message | Possible Cause |
|--------|------|---------|----------------|
| 401 | AUTH_001 | Invalid or expired token | Token format error or expired |
| 403 | AUTH_003 | Insufficient permissions | No access to this user info |
| 404 | USER_001 | User not found | User ID doesn't exist or deleted |
**Examples**:
```bash
# cURL
curl -X GET "https://api.example.com/api/v1/users/usr_123456" \
-H "Authorization: Bearer eyJhbGc..." \
-H "Content-Type: application/json"
```
```javascript
// JavaScript (fetch)
const response = await fetch('https://api.example.com/api/v1/users/usr_123456', {
method: 'GET',
headers: {
'Authorization': 'Bearer eyJhbGc...',
'Content-Type': 'application/json'
}
});
const data = await response.json();
```
```
## Session Structure
```
.workflow/active/
└── WFS-swagger-{timestamp}/
├── workflow-session.json
├── IMPL_PLAN.md
├── TODO_LIST.md
├── .process/
│ └── swagger-planning-data.json
└── .task/
├── IMPL-001.json # OpenAPI spec
├── IMPL-002.json # Security config
├── IMPL-003.json # Error codes
├── IMPL-004.json # Module 1 API
├── ...
├── IMPL-N+1.json # API overview
└── IMPL-N+2.json # Validation tests
```
## Execution Commands
```bash
# Execute entire workflow
/workflow:execute
# Specify session
/workflow:execute --resume-session="WFS-swagger-yyyymmdd-hhmmss"
# Single task execution
/task:execute IMPL-001
```
## Related Commands
- `/workflow:execute` - Execute documentation tasks
- `/workflow:status` - View task progress
- `/workflow:session:complete` - Mark session complete
- `/memory:docs` - General documentation workflow

View File

@@ -147,8 +147,8 @@ You are generating path-conditional rules for Claude Code.
## Instructions
Read the agent prompt template for detailed instructions:
$(cat ~/.claude/workflows/cli-templates/prompts/rules/tech-rules-agent-prompt.txt)
Read the agent prompt template for detailed instructions.
Use --rule rules-tech-rules-agent-prompt to load the template automatically.
## Execution Steps

View File

@@ -1,9 +1,13 @@
---
name: breakdown
description: Decompose complex task into subtasks with dependency mapping, creates child task JSONs with parent references and execution order
argument-hint: "task-id"
argument-hint: "[-y|--yes] task-id"
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm breakdown, use recommended subtask structure.
# Task Breakdown Command (/task:breakdown)
## Overview

View File

@@ -1,10 +1,14 @@
---
name: replan
description: Update task JSON with new requirements or batch-update multiple tasks from verification report, tracks changes in task-changes.json
argument-hint: "task-id [\"text\"|file.md] | --batch [verification-report.md]"
argument-hint: "[-y|--yes] task-id [\"text\"|file.md] | --batch [verification-report.md]"
allowed-tools: Read(*), Write(*), Edit(*), TodoWrite(*), Glob(*), Bash(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm updates, use recommended changes.
# Task Replan Command (/task:replan)
> **⚠️ DEPRECATION NOTICE**: This command is maintained for backward compatibility. For new workflows, use `/workflow:replan` which provides:
@@ -353,7 +357,7 @@ Review error details in summary report
# No replan recommendations found
Verification report contains no replan recommendations
Check report content or use /workflow:action-plan-verify first
Check report content or use /workflow:plan-verify first
```
## Batch Mode Integration

View File

@@ -1,8 +1,8 @@
---
name: action-plan-verify
description: Perform non-destructive cross-artifact consistency analysis between IMPL_PLAN.md and task JSONs with quality gate validation
name: plan-verify
description: Perform READ-ONLY verification analysis between IMPL_PLAN.md, task JSONs, and brainstorming artifacts. Generates structured report with quality gate recommendation. Does NOT modify any files.
argument-hint: "[optional: --session session-id]"
allowed-tools: Read(*), TodoWrite(*), Glob(*), Bash(*)
allowed-tools: Read(*), Write(*), Glob(*), Bash(*)
---
## User Input
@@ -15,13 +15,26 @@ You **MUST** consider the user input before proceeding (if not empty).
## Goal
Identify inconsistencies, duplications, ambiguities, and underspecified items between action planning artifacts (`IMPL_PLAN.md`, `task.json`) and brainstorming artifacts (`role analysis documents`) before implementation. This command MUST run only after `/workflow:plan` has successfully produced complete `IMPL_PLAN.md` and task JSON files.
Generate a comprehensive verification report that identifies inconsistencies, duplications, ambiguities, and underspecified items between action planning artifacts (`IMPL_PLAN.md`, `task.json`) and brainstorming artifacts (`role analysis documents`). This command MUST run only after `/workflow:plan` has successfully produced complete `IMPL_PLAN.md` and task JSON files.
**Output**: A structured Markdown report saved to `.workflow/active/WFS-{session}/.process/ACTION_PLAN_VERIFICATION.md` containing:
- Executive summary with quality gate recommendation
- Detailed findings by severity (CRITICAL/HIGH/MEDIUM/LOW)
- Requirements coverage analysis
- Dependency integrity check
- Synthesis alignment validation
- Actionable remediation recommendations
## Operating Constraints
**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands).
**STRICTLY READ-ONLY FOR SOURCE ARTIFACTS**:
- **MUST NOT** modify `IMPL_PLAN.md`, any `task.json` files, or brainstorming artifacts
- **MUST NOT** create or delete task files
- **MUST ONLY** write the verification report to `.process/ACTION_PLAN_VERIFICATION.md`
**Synthesis Authority**: The `role analysis documents` is **authoritative** for requirements and design decisions. Any conflicts between IMPL_PLAN/tasks and synthesis are automatically CRITICAL and require adjustment of the plan/tasks—not reinterpretation of requirements.
**Synthesis Authority**: The `role analysis documents` are **authoritative** for requirements and design decisions. Any conflicts between IMPL_PLAN/tasks and synthesis are automatically CRITICAL and require adjustment of the plan/tasks—not reinterpretation of requirements.
**Quality Gate Authority**: The verification report provides a binding recommendation (BLOCK_EXECUTION / PROCEED_WITH_FIXES / PROCEED_WITH_CAUTION / PROCEED) based on objective severity criteria. User MUST review critical/high issues before proceeding with implementation.
## Execution Steps
@@ -47,6 +60,12 @@ ELSE:
session_dir = .workflow/active/WFS-{session}
brainstorm_dir = session_dir/.brainstorming
task_dir = session_dir/.task
process_dir = session_dir/.process
session_file = session_dir/workflow-session.json
# Create .process directory if not exists (report output location)
IF NOT EXISTS(process_dir):
bash(mkdir -p "{process_dir}")
# Validate required artifacts
# Note: "role analysis documents" refers to [role]/analysis.md files (e.g., product-manager/analysis.md)
@@ -54,7 +73,12 @@ SYNTHESIS_DIR = brainstorm_dir # Contains role analysis files: */analysis.md
IMPL_PLAN = session_dir/IMPL_PLAN.md
TASK_FILES = Glob(task_dir/*.json)
# Abort if missing
# Abort if missing - in order of dependency
SESSION_FILE_EXISTS = EXISTS(session_file)
IF NOT SESSION_FILE_EXISTS:
WARNING: "workflow-session.json not found. User intent alignment verification will be skipped."
# Continue execution - this is optional context, not blocking
SYNTHESIS_FILES = Glob(brainstorm_dir/*/analysis.md)
IF SYNTHESIS_FILES.count == 0:
ERROR: "No role analysis documents found in .brainstorming/*/analysis.md. Run /workflow:brainstorm:synthesis first"
@@ -73,12 +97,14 @@ IF TASK_FILES.count == 0:
Load only minimal necessary context from each artifact:
**From workflow-session.json** (NEW - PRIMARY REFERENCE):
**From workflow-session.json** (OPTIONAL - Primary Reference for User Intent):
- **ONLY IF EXISTS**: Load user intent context
- Original user prompt/intent (project or description field)
- User's stated goals and objectives
- User's scope definition
- **IF MISSING**: Set user_intent_analysis = "SKIPPED: workflow-session.json not found"
**From role analysis documents**:
**From role analysis documents** (AUTHORITATIVE SOURCE):
- Functional Requirements (IDs, descriptions, acceptance criteria)
- Non-Functional Requirements (IDs, targets)
- Business Requirements (IDs, success metrics)
@@ -126,9 +152,21 @@ Create internal representations (do not include raw artifacts in output):
### 4. Detection Passes (Token-Efficient Analysis)
Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary.
**Token Budget Strategy**:
- **Total Limit**: 50 findings maximum (aggregate remainder in overflow summary)
- **Priority Allocation**: CRITICAL (unlimited) → HIGH (15) → MEDIUM (20) → LOW (15)
- **Early Exit**: If CRITICAL findings > 0 in User Intent/Requirements Coverage, skip LOW/MEDIUM priority checks
#### A. User Intent Alignment (NEW - CRITICAL)
**Execution Order** (Process in sequence; skip if token budget exhausted):
1. **Tier 1 (CRITICAL Path)**: A, B, C - User intent, coverage, consistency (process fully)
2. **Tier 2 (HIGH Priority)**: D, E - Dependencies, synthesis alignment (limit 15 findings total)
3. **Tier 3 (MEDIUM Priority)**: F - Specification quality (limit 20 findings)
4. **Tier 4 (LOW Priority)**: G, H - Duplication, feasibility (limit 15 findings total)
---
#### A. User Intent Alignment (CRITICAL - Tier 1)
- **Goal Alignment**: IMPL_PLAN objectives match user's original intent
- **Scope Drift**: Plan covers user's stated scope without unauthorized expansion

View File

@@ -1,10 +1,14 @@
---
name: artifacts
description: Interactive clarification generating confirmed guidance specification through role-based analysis and synthesis
argument-hint: "topic or challenge description [--count N]"
argument-hint: "[-y|--yes] topic or challenge description [--count N]"
allowed-tools: TodoWrite(*), Read(*), Write(*), Glob(*), AskUserQuestion(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-select recommended roles, skip all clarification questions, use default answers.
## Overview
Seven-phase workflow: **Context collection****Topic analysis****Role selection****Role questions****Conflict resolution****Final check****Generate specification**

View File

@@ -1,19 +1,23 @@
---
name: auto-parallel
description: Parallel brainstorming automation with dynamic role selection and concurrent execution across multiple perspectives
argument-hint: "topic or challenge description" [--count N]
argument-hint: "[-y|--yes] topic or challenge description [--count N]"
allowed-tools: SlashCommand(*), Task(*), TodoWrite(*), Read(*), Write(*), Bash(*), Glob(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-select recommended roles, skip all clarification questions, use default answers.
# Workflow Brainstorm Parallel Auto Command
## Coordinator Role
**This command is a pure orchestrator**: Dispatches 3 phases in sequence (interactive framework → parallel role analysis → synthesis), coordinating specialized commands/agents through task attachment model.
**This command is a pure orchestrator**: Executes 3 phases in sequence (interactive framework → parallel role analysis → synthesis), coordinating specialized commands/agents through task attachment model.
**Task Attachment Model**:
- SlashCommand dispatch **expands workflow** by attaching sub-tasks to current TodoWrite
- Task agent dispatch **attaches analysis tasks** to orchestrator's TodoWrite
- SlashCommand execute **expands workflow** by attaching sub-tasks to current TodoWrite
- Task agent execute **attaches analysis tasks** to orchestrator's TodoWrite
- Phase 1: artifacts command attaches its internal tasks (Phase 1-5)
- Phase 2: N conceptual-planning-agent tasks attached in parallel
- Phase 3: synthesis command attaches its internal tasks
@@ -26,9 +30,9 @@ allowed-tools: SlashCommand(*), Task(*), TodoWrite(*), Read(*), Write(*), Bash(*
This workflow runs **fully autonomously** once triggered. Phase 1 (artifacts) handles user interaction, Phase 2 (role agents) runs in parallel.
1. **User triggers**: `/workflow:brainstorm:auto-parallel "topic" [--count N]`
2. **Dispatch Phase 1** → artifacts command (tasks ATTACHED) → Auto-continues
3. **Dispatch Phase 2** → Parallel role agents (N tasks ATTACHED concurrently) → Auto-continues
4. **Dispatch Phase 3** → Synthesis command (tasks ATTACHED) → Reports final summary
2. **Execute Phase 1** → artifacts command (tasks ATTACHED) → Auto-continues
3. **Execute Phase 2** → Parallel role agents (N tasks ATTACHED concurrently) → Auto-continues
4. **Execute Phase 3** → Synthesis command (tasks ATTACHED) → Reports final summary
**Auto-Continue Mechanism**:
- TodoList tracks current phase status and dynamically manages task attachment/collapse
@@ -38,13 +42,13 @@ This workflow runs **fully autonomously** once triggered. Phase 1 (artifacts) ha
## Core Rules
1. **Start Immediately**: First action is TodoWrite initialization, second action is dispatch Phase 1 command
1. **Start Immediately**: First action is TodoWrite initialization, second action is execute Phase 1 command
2. **No Preliminary Analysis**: Do not analyze topic before Phase 1 - artifacts handles all analysis
3. **Parse Every Output**: Extract selected_roles from workflow-session.json after Phase 1
4. **Auto-Continue via TodoList**: Check TodoList status to dispatch next pending phase automatically
4. **Auto-Continue via TodoList**: Check TodoList status to execute next pending phase automatically
5. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
6. **Task Attachment Model**: SlashCommand and Task dispatches **attach** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
7. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and dispatch next phase
6. **Task Attachment Model**: SlashCommand and Task executes **attach** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
7. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
8. **Parallel Execution**: Phase 2 attaches multiple agent tasks simultaneously for concurrent execution
## Usage
@@ -67,7 +71,7 @@ This workflow runs **fully autonomously** once triggered. Phase 1 (artifacts) ha
### Phase 1: Interactive Framework Generation
**Step 1: Dispatch** - Interactive framework generation via artifacts command
**Step 1: Execute** - Interactive framework generation via artifacts command
```javascript
SlashCommand(command="/workflow:brainstorm:artifacts \"{topic}\" --count {N}")
@@ -91,7 +95,7 @@ SlashCommand(command="/workflow:brainstorm:artifacts \"{topic}\" --count {N}")
- workflow-session.json contains selected_roles[] (metadata only, no content duplication)
- Session directory `.workflow/active/WFS-{topic}/.brainstorming/` exists
**TodoWrite Update (Phase 1 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 1 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Phase 0: Parameter Parsing", "status": "completed", "activeForm": "Parsing count parameter"},
@@ -106,7 +110,7 @@ SlashCommand(command="/workflow:brainstorm:artifacts \"{topic}\" --count {N}")
]
```
**Note**: SlashCommand dispatch **attaches** artifacts' 5 internal tasks. Orchestrator **executes** these tasks sequentially.
**Note**: SlashCommand execute **attaches** artifacts' 5 internal tasks. Orchestrator **executes** these tasks sequentially.
**Next Action**: Tasks attached → **Execute Phase 1.1-1.5** sequentially
@@ -167,7 +171,7 @@ TOPIC: {user-provided-topic}
"
```
**Parallel Dispatch**:
**Parallel Execute**:
- Launch N agents simultaneously (one message with multiple Task calls)
- Each agent task **attached** to orchestrator's TodoWrite
- All agents execute concurrently, each attaching their own analysis sub-tasks
@@ -185,7 +189,7 @@ TOPIC: {user-provided-topic}
- **FORBIDDEN**: `recommendations.md` or any non-`analysis` prefixed files
- All N role analyses completed
**TodoWrite Update (Phase 2 agents dispatched - tasks attached in parallel)**:
**TodoWrite Update (Phase 2 agents executed - tasks attached in parallel)**:
```json
[
{"content": "Phase 0: Parameter Parsing", "status": "completed", "activeForm": "Parsing count parameter"},
@@ -198,7 +202,7 @@ TOPIC: {user-provided-topic}
]
```
**Note**: Multiple Task dispatches **attach** N role analysis tasks simultaneously. Orchestrator **executes** these tasks in parallel.
**Note**: Multiple Task executes **attach** N role analysis tasks simultaneously. Orchestrator **executes** these tasks in parallel.
**Next Action**: Tasks attached → **Execute Phase 2.1-2.N** concurrently
@@ -220,7 +224,7 @@ TOPIC: {user-provided-topic}
### Phase 3: Synthesis Generation
**Step 3: Dispatch** - Synthesis integration via synthesis command
**Step 3: Execute** - Synthesis integration via synthesis command
```javascript
SlashCommand(command="/workflow:brainstorm:synthesis --session {sessionId}")
@@ -238,7 +242,7 @@ SlashCommand(command="/workflow:brainstorm:synthesis --session {sessionId}")
- `.workflow/active/WFS-{topic}/.brainstorming/synthesis-specification.md` exists
- Synthesis references all role analyses
**TodoWrite Update (Phase 3 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 3 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Phase 0: Parameter Parsing", "status": "completed", "activeForm": "Parsing count parameter"},
@@ -251,7 +255,7 @@ SlashCommand(command="/workflow:brainstorm:synthesis --session {sessionId}")
]
```
**Note**: SlashCommand dispatch **attaches** synthesis' internal tasks. Orchestrator **executes** these tasks sequentially.
**Note**: SlashCommand execute **attaches** synthesis' internal tasks. Orchestrator **executes** these tasks sequentially.
**Next Action**: Tasks attached → **Execute Phase 3.1-3.3** sequentially
@@ -284,7 +288,7 @@ Synthesis: .workflow/active/WFS-{topic}/.brainstorming/synthesis-specification.m
### Key Principles
1. **Task Attachment** (when SlashCommand/Task dispatched):
1. **Task Attachment** (when SlashCommand/Task executed):
- Sub-command's or agent's internal tasks are **attached** to orchestrator's TodoWrite
- Phase 1: `/workflow:brainstorm:artifacts` attaches 5 internal tasks (Phase 1.1-1.5)
- Phase 2: Multiple `Task(conceptual-planning-agent)` calls attach N role analysis tasks simultaneously
@@ -305,7 +309,7 @@ Synthesis: .workflow/active/WFS-{topic}/.brainstorming/synthesis-specification.m
- No user intervention required between phases
- TodoWrite dynamically reflects current execution state
**Lifecycle Summary**: Initial pending tasks → Phase 1 dispatched (artifacts tasks ATTACHED) → Artifacts sub-tasks executed → Phase 1 completed (tasks COLLAPSED) → Phase 2 dispatched (N role tasks ATTACHED in parallel) → Role analyses executed concurrently → Phase 2 completed (tasks COLLAPSED) → Phase 3 dispatched (synthesis tasks ATTACHED) → Synthesis sub-tasks executed → Phase 3 completed (tasks COLLAPSED) → Workflow complete.
**Lifecycle Summary**: Initial pending tasks → Phase 1 executed (artifacts tasks ATTACHED) → Artifacts sub-tasks executed → Phase 1 completed (tasks COLLAPSED) → Phase 2 executed (N role tasks ATTACHED in parallel) → Role analyses executed concurrently → Phase 2 completed (tasks COLLAPSED) → Phase 3 executed (synthesis tasks ATTACHED) → Synthesis sub-tasks executed → Phase 3 completed (tasks COLLAPSED) → Workflow complete.
### Brainstorming Workflow Specific Features
@@ -424,6 +428,17 @@ CONTEXT_VARS:
- **Agent execution failure**: Agent-specific retry with minimal dependencies
- **Template loading issues**: Agent handles graceful degradation
- **Synthesis conflicts**: Synthesis highlights disagreements without resolution
- **Context overflow protection**: See below for automatic context management
## Context Overflow Protection
**Per-role limits**: See `conceptual-planning-agent.md` (< 3000 words main, < 2000 words sub-docs, max 5 sub-docs)
**Synthesis protection**: If total analysis > 100KB, synthesis reads only `analysis.md` files (not sub-documents)
**Recovery**: Check logs → reduce scope (--count 2) → use --summary-only → manual synthesis
**Prevention**: Start with --count 3, use structured topic format, review output sizes before synthesis
## Reference Information

View File

@@ -1,10 +1,14 @@
---
name: synthesis
description: Clarify and refine role analyses through intelligent Q&A and targeted updates with synthesis agent
argument-hint: "[optional: --session session-id]"
argument-hint: "[-y|--yes] [optional: --session session-id]"
allowed-tools: Task(conceptual-planning-agent), TodoWrite(*), Read(*), Write(*), Edit(*), Glob(*), AskUserQuestion(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-select all enhancements, skip clarification questions, use default answers.
## Overview
Six-phase workflow to eliminate ambiguities and enhance conceptual depth in role analyses:

View File

@@ -1,11 +1,11 @@
---
name: clean
description: Intelligent code cleanup with mainline detection, stale artifact discovery, and safe execution
argument-hint: "[--dry-run] [\"focus area\"]"
argument-hint: "[-y|--yes] [--dry-run] [\"focus area\"]"
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Glob(*), Bash(*), Write(*)
---
# Clean Command (/clean)
# Clean Command (/workflow:clean)
## Overview
@@ -20,9 +20,23 @@ Intelligent cleanup command that explores the codebase to identify the developme
## Usage
```bash
/clean # Full intelligent cleanup (explore → analyze → confirm → execute)
/clean --dry-run # Explore and analyze only, no execution
/clean "auth module" # Focus cleanup on specific area
/workflow:clean # Full intelligent cleanup (explore → analyze → confirm → execute)
/workflow:clean --yes # Auto mode (use safe defaults, no confirmation)
/workflow:clean --dry-run # Explore and analyze only, no execution
/workflow:clean -y "auth module" # Auto mode with focus area
```
## Auto Mode Defaults
When `--yes` or `-y` flag is used:
- **Categories to Clean**: Auto-selects `["Sessions"]` only (safest - only workflow sessions)
- **Risk Level**: Auto-selects `"Low only"` (only low-risk items)
- All confirmations skipped, proceeds directly to execution
**Flag Parsing**:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const dryRun = $ARGUMENTS.includes('--dry-run')
```
## Execution Process
@@ -132,7 +146,7 @@ Scan and analyze workflow session directories:
**Staleness criteria**:
- Active sessions: No modification >7 days + no related git commits
- Archives: >30 days old + no feature references in project.json
- Archives: >30 days old + no feature references in project-tech.json
- Lite-plan: >7 days old + plan.json not executed
- Debug: >3 days old + issue not in recent commits
@@ -321,7 +335,7 @@ if (flags.includes('--dry-run')) {
**Dry-run mode**: No changes made.
Manifest saved to: ${sessionFolder}/cleanup-manifest.json
To execute cleanup: /clean
To execute cleanup: /workflow:clean
`)
return
}
@@ -329,39 +343,57 @@ To execute cleanup: /clean
**Step 3.3: User Confirmation**
```javascript
AskUserQuestion({
questions: [
{
question: "Which categories to clean?",
header: "Categories",
multiSelect: true,
options: [
{
label: "Sessions",
description: `${manifest.summary.by_category.stale_sessions} stale workflow sessions`
},
{
label: "Documents",
description: `${manifest.summary.by_category.drifted_documents} drifted documents`
},
{
label: "Dead Code",
description: `${manifest.summary.by_category.dead_code} unused code files`
}
]
},
{
question: "Risk level to include?",
header: "Risk",
multiSelect: false,
options: [
{ label: "Low only", description: "Safest - only obviously stale items" },
{ label: "Low + Medium", description: "Recommended - includes likely unused items" },
{ label: "All", description: "Aggressive - includes high-risk items" }
]
}
]
})
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
let userSelection
if (autoYes) {
// Auto mode: Use safe defaults
console.log(`[--yes] Auto-selecting safe cleanup defaults:`)
console.log(` - Categories: Sessions only`)
console.log(` - Risk level: Low only`)
userSelection = {
categories: ["Sessions"],
risk: "Low only"
}
} else {
// Interactive mode: Ask user
userSelection = AskUserQuestion({
questions: [
{
question: "Which categories to clean?",
header: "Categories",
multiSelect: true,
options: [
{
label: "Sessions",
description: `${manifest.summary.by_category.stale_sessions} stale workflow sessions`
},
{
label: "Documents",
description: `${manifest.summary.by_category.drifted_documents} drifted documents`
},
{
label: "Dead Code",
description: `${manifest.summary.by_category.dead_code} unused code files`
}
]
},
{
question: "Risk level to include?",
header: "Risk",
multiSelect: false,
options: [
{ label: "Low only", description: "Safest - only obviously stale items" },
{ label: "Low + Medium", description: "Recommended - includes likely unused items" },
{ label: "All", description: "Aggressive - includes high-risk items" }
]
}
]
})
}
```
---
@@ -443,8 +475,8 @@ if (selectedCategories.includes('Sessions')) {
}
}
// Update project.json if features referenced deleted sessions
const projectPath = '.workflow/project.json'
// Update project-tech.json if features referenced deleted sessions
const projectPath = '.workflow/project-tech.json'
if (fileExists(projectPath)) {
const project = JSON.parse(Read(projectPath))
const deletedPaths = new Set(results.deleted)

View File

@@ -0,0 +1,670 @@
---
name: debug-with-file
description: Interactive hypothesis-driven debugging with documented exploration, understanding evolution, and Gemini-assisted correction
argument-hint: "[-y|--yes] \"bug description or error message\""
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm all decisions (hypotheses, fixes, iteration), use recommended settings.
# Workflow Debug-With-File Command (/workflow:debug-with-file)
## Overview
Enhanced evidence-based debugging with **documented exploration process**. Records understanding evolution, consolidates insights, and uses Gemini to correct misunderstandings.
**Core workflow**: Explore → Document → Log → Analyze → Correct Understanding → Fix → Verify
**Key enhancements over /workflow:debug**:
- **understanding.md**: Timeline of exploration and learning
- **Gemini-assisted correction**: Validates and corrects hypotheses
- **Consolidation**: Simplifies proven-wrong understanding to avoid clutter
- **Learning retention**: Preserves what was learned, even from failed attempts
## Usage
```bash
/workflow:debug-with-file <BUG_DESCRIPTION>
# Arguments
<bug-description> Bug description, error message, or stack trace (required)
```
## Execution Process
```
Session Detection:
├─ Check if debug session exists for this bug
├─ EXISTS + understanding.md exists → Continue mode
└─ NOT_FOUND → Explore mode
Explore Mode:
├─ Locate error source in codebase
├─ Document initial understanding in understanding.md
├─ Generate testable hypotheses with Gemini validation
├─ Add NDJSON logging instrumentation
└─ Output: Hypothesis list + await user reproduction
Analyze Mode:
├─ Parse debug.log, validate each hypothesis
├─ Use Gemini to analyze evidence and correct understanding
├─ Update understanding.md with:
│ ├─ New evidence
│ ├─ Corrected misunderstandings (strikethrough + correction)
│ └─ Consolidated current understanding
└─ Decision:
├─ Confirmed → Fix root cause
├─ Inconclusive → Add more logging, iterate
└─ All rejected → Gemini-assisted new hypotheses
Fix & Cleanup:
├─ Apply fix based on confirmed hypothesis
├─ User verifies
├─ Document final understanding + lessons learned
├─ Remove debug instrumentation
└─ If not fixed → Return to Analyze mode
```
## Implementation
### Session Setup & Mode Detection
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const bugSlug = bug_description.toLowerCase().replace(/[^a-z0-9]+/g, '-').substring(0, 30)
const dateStr = getUtc8ISOString().substring(0, 10)
const sessionId = `DBG-${bugSlug}-${dateStr}`
const sessionFolder = `.workflow/.debug/${sessionId}`
const debugLogPath = `${sessionFolder}/debug.log`
const understandingPath = `${sessionFolder}/understanding.md`
const hypothesesPath = `${sessionFolder}/hypotheses.json`
// Auto-detect mode
const sessionExists = fs.existsSync(sessionFolder)
const hasUnderstanding = sessionExists && fs.existsSync(understandingPath)
const logHasContent = sessionExists && fs.existsSync(debugLogPath) && fs.statSync(debugLogPath).size > 0
const mode = logHasContent ? 'analyze' : (hasUnderstanding ? 'continue' : 'explore')
if (!sessionExists) {
bash(`mkdir -p ${sessionFolder}`)
}
```
---
### Explore Mode
**Step 1.1: Locate Error Source**
```javascript
// Extract keywords from bug description
const keywords = extractErrorKeywords(bug_description)
// Search codebase for error locations
const searchResults = []
for (const keyword of keywords) {
const results = Grep({ pattern: keyword, path: ".", output_mode: "content", "-C": 3 })
searchResults.push({ keyword, results })
}
// Identify affected files and functions
const affectedLocations = analyzeSearchResults(searchResults)
```
**Step 1.2: Document Initial Understanding**
Create `understanding.md` with exploration timeline:
```markdown
# Understanding Document
**Session ID**: ${sessionId}
**Bug Description**: ${bug_description}
**Started**: ${getUtc8ISOString()}
---
## Exploration Timeline
### Iteration 1 - Initial Exploration (${timestamp})
#### Current Understanding
Based on bug description and initial code search:
- Error pattern: ${errorPattern}
- Affected areas: ${affectedLocations.map(l => l.file).join(', ')}
- Initial hypothesis: ${initialThoughts}
#### Evidence from Code Search
${searchResults.map(r => `
**Keyword: "${r.keyword}"**
- Found in: ${r.results.files.join(', ')}
- Key findings: ${r.insights}
`).join('\n')}
#### Next Steps
- Generate testable hypotheses
- Add instrumentation
- Await reproduction
---
## Current Consolidated Understanding
${initialConsolidatedUnderstanding}
```
**Step 1.3: Gemini-Assisted Hypothesis Generation**
```bash
ccw cli -p "
PURPOSE: Generate debugging hypotheses for: ${bug_description}
Success criteria: Testable hypotheses with clear evidence criteria
TASK:
• Analyze error pattern and code search results
• Identify 3-5 most likely root causes
• For each hypothesis, specify:
- What might be wrong
- What evidence would confirm/reject it
- Where to add instrumentation
• Rank by likelihood
MODE: analysis
CONTEXT: @${sessionFolder}/understanding.md | Search results in understanding.md
EXPECTED:
- Structured hypothesis list (JSON format)
- Each hypothesis with: id, description, testable_condition, logging_point, evidence_criteria
- Likelihood ranking (1=most likely)
CONSTRAINTS: Focus on testable conditions
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
Save Gemini output to `hypotheses.json`:
```json
{
"iteration": 1,
"timestamp": "2025-01-21T10:00:00+08:00",
"hypotheses": [
{
"id": "H1",
"description": "Data structure mismatch - expected key not present",
"testable_condition": "Check if target key exists in dict",
"logging_point": "file.py:func:42",
"evidence_criteria": {
"confirm": "data shows missing key",
"reject": "key exists with valid value"
},
"likelihood": 1,
"status": "pending"
}
],
"gemini_insights": "...",
"corrected_assumptions": []
}
```
**Step 1.4: Add NDJSON Instrumentation**
For each hypothesis, add logging (same as original debug command).
**Step 1.5: Update understanding.md**
Append hypothesis section:
```markdown
#### Hypotheses Generated (Gemini-Assisted)
${hypotheses.map(h => `
**${h.id}** (Likelihood: ${h.likelihood}): ${h.description}
- Logging at: ${h.logging_point}
- Testing: ${h.testable_condition}
- Evidence to confirm: ${h.evidence_criteria.confirm}
- Evidence to reject: ${h.evidence_criteria.reject}
`).join('\n')}
**Gemini Insights**: ${geminiInsights}
```
---
### Analyze Mode
**Step 2.1: Parse Debug Log**
```javascript
// Parse NDJSON log
const entries = Read(debugLogPath).split('\n')
.filter(l => l.trim())
.map(l => JSON.parse(l))
// Group by hypothesis
const byHypothesis = groupBy(entries, 'hid')
```
**Step 2.2: Gemini-Assisted Evidence Analysis**
```bash
ccw cli -p "
PURPOSE: Analyze debug log evidence to validate/correct hypotheses for: ${bug_description}
Success criteria: Clear verdict per hypothesis + corrected understanding
TASK:
• Parse log entries by hypothesis
• Evaluate evidence against expected criteria
• Determine verdict: confirmed | rejected | inconclusive
• Identify incorrect assumptions from previous understanding
• Suggest corrections to understanding
MODE: analysis
CONTEXT:
@${debugLogPath}
@${understandingPath}
@${hypothesesPath}
EXPECTED:
- Per-hypothesis verdict with reasoning
- Evidence summary
- List of incorrect assumptions with corrections
- Updated consolidated understanding
- Root cause if confirmed, or next investigation steps
CONSTRAINTS: Evidence-based reasoning only, no speculation
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
**Step 2.3: Update Understanding with Corrections**
Append new iteration to `understanding.md`:
```markdown
### Iteration ${n} - Evidence Analysis (${timestamp})
#### Log Analysis Results
${results.map(r => `
**${r.id}**: ${r.verdict.toUpperCase()}
- Evidence: ${JSON.stringify(r.evidence)}
- Reasoning: ${r.reason}
`).join('\n')}
#### Corrected Understanding
Previous misunderstandings identified and corrected:
${corrections.map(c => `
- ~~${c.wrong}~~ → ${c.corrected}
- Why wrong: ${c.reason}
- Evidence: ${c.evidence}
`).join('\n')}
#### New Insights
${newInsights.join('\n- ')}
#### Gemini Analysis
${geminiAnalysis}
${confirmedHypothesis ? `
#### Root Cause Identified
**${confirmedHypothesis.id}**: ${confirmedHypothesis.description}
Evidence supporting this conclusion:
${confirmedHypothesis.supportingEvidence}
` : `
#### Next Steps
${nextSteps}
`}
---
## Current Consolidated Understanding (Updated)
${consolidatedUnderstanding}
```
**Step 2.4: Consolidate Understanding**
At the bottom of `understanding.md`, update the consolidated section:
- Remove or simplify proven-wrong assumptions
- Keep them in strikethrough for reference
- Focus on current valid understanding
- Avoid repeating details from timeline
```markdown
## Current Consolidated Understanding
### What We Know
- ${validUnderstanding1}
- ${validUnderstanding2}
### What Was Disproven
- ~~Initial assumption: ${wrongAssumption}~~ (Evidence: ${disproofEvidence})
### Current Investigation Focus
${currentFocus}
### Remaining Questions
- ${openQuestion1}
- ${openQuestion2}
```
**Step 2.5: Update hypotheses.json**
```json
{
"iteration": 2,
"timestamp": "2025-01-21T10:15:00+08:00",
"hypotheses": [
{
"id": "H1",
"status": "rejected",
"verdict_reason": "Evidence shows key exists with valid value",
"evidence": {...}
},
{
"id": "H2",
"status": "confirmed",
"verdict_reason": "Log data confirms timing issue",
"evidence": {...}
}
],
"gemini_corrections": [
{
"wrong_assumption": "...",
"corrected_to": "...",
"reason": "..."
}
]
}
```
---
### Fix & Verification
**Step 3.1: Apply Fix**
(Same as original debug command)
**Step 3.2: Document Resolution**
Append to `understanding.md`:
```markdown
### Iteration ${n} - Resolution (${timestamp})
#### Fix Applied
- Modified files: ${modifiedFiles.join(', ')}
- Fix description: ${fixDescription}
- Root cause addressed: ${rootCause}
#### Verification Results
${verificationResults}
#### Lessons Learned
What we learned from this debugging session:
1. ${lesson1}
2. ${lesson2}
3. ${lesson3}
#### Key Insights for Future
- ${insight1}
- ${insight2}
```
**Step 3.3: Cleanup**
Remove debug instrumentation (same as original command).
---
## Session Folder Structure
```
.workflow/.debug/DBG-{slug}-{date}/
├── debug.log # NDJSON log (execution evidence)
├── understanding.md # NEW: Exploration timeline + consolidated understanding
├── hypotheses.json # NEW: Hypothesis history with verdicts
└── resolution.md # Optional: Final summary
```
## Understanding Document Template
```markdown
# Understanding Document
**Session ID**: DBG-xxx-2025-01-21
**Bug Description**: [original description]
**Started**: 2025-01-21T10:00:00+08:00
---
## Exploration Timeline
### Iteration 1 - Initial Exploration (2025-01-21 10:00)
#### Current Understanding
...
#### Evidence from Code Search
...
#### Hypotheses Generated (Gemini-Assisted)
...
### Iteration 2 - Evidence Analysis (2025-01-21 10:15)
#### Log Analysis Results
...
#### Corrected Understanding
- ~~[wrong]~~ → [corrected]
#### Gemini Analysis
...
---
## Current Consolidated Understanding
### What We Know
- [valid understanding points]
### What Was Disproven
- ~~[disproven assumptions]~~
### Current Investigation Focus
[current focus]
### Remaining Questions
- [open questions]
```
## Iteration Flow
```
First Call (/workflow:debug-with-file "error"):
├─ No session exists → Explore mode
├─ Extract error keywords, search codebase
├─ Document initial understanding in understanding.md
├─ Use Gemini to generate hypotheses
├─ Add logging instrumentation
└─ Await user reproduction
After Reproduction (/workflow:debug-with-file "error"):
├─ Session exists + debug.log has content → Analyze mode
├─ Parse log, use Gemini to evaluate hypotheses
├─ Update understanding.md with:
│ ├─ Evidence analysis results
│ ├─ Corrected misunderstandings (strikethrough)
│ ├─ New insights
│ └─ Updated consolidated understanding
├─ Update hypotheses.json with verdicts
└─ Decision:
├─ Confirmed → Fix → Document resolution
├─ Inconclusive → Add logging, document next steps
└─ All rejected → Gemini-assisted new hypotheses
Output:
├─ .workflow/.debug/DBG-{slug}-{date}/debug.log
├─ .workflow/.debug/DBG-{slug}-{date}/understanding.md (evolving document)
└─ .workflow/.debug/DBG-{slug}-{date}/hypotheses.json (history)
```
## Gemini Integration Points
### 1. Hypothesis Generation (Explore Mode)
**Purpose**: Generate evidence-based, testable hypotheses
**Prompt Pattern**:
```
PURPOSE: Generate debugging hypotheses + evidence criteria
TASK: Analyze error + code → testable hypotheses with clear pass/fail criteria
CONTEXT: @understanding.md (search results)
EXPECTED: JSON with hypotheses, likelihood ranking, evidence criteria
```
### 2. Evidence Analysis (Analyze Mode)
**Purpose**: Validate hypotheses and correct misunderstandings
**Prompt Pattern**:
```
PURPOSE: Analyze debug log evidence + correct understanding
TASK: Evaluate each hypothesis → identify wrong assumptions → suggest corrections
CONTEXT: @debug.log @understanding.md @hypotheses.json
EXPECTED: Verdicts + corrections + updated consolidated understanding
```
### 3. New Hypothesis Generation (After All Rejected)
**Purpose**: Generate new hypotheses based on what was disproven
**Prompt Pattern**:
```
PURPOSE: Generate new hypotheses given disproven assumptions
TASK: Review rejected hypotheses → identify knowledge gaps → new investigation angles
CONTEXT: @understanding.md (with disproven section) @hypotheses.json
EXPECTED: New hypotheses avoiding previously rejected paths
```
## Error Correction Mechanism
### Correction Format in understanding.md
```markdown
#### Corrected Understanding
- ~~Assumed dict key "config" was missing~~ → Key exists, but value is None
- Why wrong: Only checked existence, not value validity
- Evidence: H1 log shows {"config": null, "exists": true}
- ~~Thought error occurred in initialization~~ → Error happens during runtime update
- Why wrong: Stack trace misread as init code
- Evidence: H2 timestamp shows 30s after startup
```
### Consolidation Rules
When updating "Current Consolidated Understanding":
1. **Simplify disproven items**: Move to "What Was Disproven" with single-line summary
2. **Keep valid insights**: Promote confirmed findings to "What We Know"
3. **Avoid duplication**: Don't repeat timeline details in consolidated section
4. **Focus on current state**: What do we know NOW, not the journey
5. **Preserve key corrections**: Keep important wrong→right transformations for learning
**Bad (cluttered)**:
```markdown
## Current Consolidated Understanding
In iteration 1 we thought X, but in iteration 2 we found Y, then in iteration 3...
Also we checked A and found B, and then we checked C...
```
**Good (consolidated)**:
```markdown
## Current Consolidated Understanding
### What We Know
- Error occurs during runtime update, not initialization
- Config value is None (not missing key)
### What Was Disproven
- ~~Initialization error~~ (Timing evidence)
- ~~Missing key hypothesis~~ (Key exists)
### Current Investigation Focus
Why is config value None during update?
```
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
---
## Error Handling
| Situation | Action |
|-----------|--------|
| Empty debug.log | Verify reproduction triggered the code path |
| All hypotheses rejected | Use Gemini to generate new hypotheses based on disproven assumptions |
| Fix doesn't work | Document failed fix attempt, iterate with refined understanding |
| >5 iterations | Review consolidated understanding, escalate to `/workflow:lite-fix` with full context |
| Gemini unavailable | Fallback to manual hypothesis generation, document without Gemini insights |
| Understanding too long | Consolidate aggressively, archive old iterations to separate file |
## Comparison with /workflow:debug
| Feature | /workflow:debug | /workflow:debug-with-file |
|---------|-----------------|---------------------------|
| NDJSON logging | ✅ | ✅ |
| Hypothesis generation | Manual | Gemini-assisted |
| Exploration documentation | ❌ | ✅ understanding.md |
| Understanding evolution | ❌ | ✅ Timeline + corrections |
| Error correction | ❌ | ✅ Strikethrough + reasoning |
| Consolidated learning | ❌ | ✅ Current understanding section |
| Hypothesis history | ❌ | ✅ hypotheses.json |
| Gemini validation | ❌ | ✅ At key decision points |
## Usage Recommendations
Use `/workflow:debug-with-file` when:
- Complex bugs requiring multiple investigation rounds
- Learning from debugging process is valuable
- Team needs to understand debugging rationale
- Bug might recur, documentation helps prevention
Use `/workflow:debug` when:
- Simple, quick bugs
- One-off issues
- Documentation overhead not needed

View File

@@ -1,10 +1,14 @@
---
name: debug
description: Interactive hypothesis-driven debugging with NDJSON logging, iterative until resolved
argument-hint: "\"bug description or error message\""
argument-hint: "[-y|--yes] \"bug description or error message\""
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Grep(*), Glob(*), Bash(*), Edit(*), Write(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-confirm all decisions (hypotheses, fixes, iteration), use recommended settings.
# Workflow Debug Command (/workflow:debug)
## Overview
@@ -311,6 +315,12 @@ Output:
└─ .workflow/.debug/DBG-{slug}-{date}/debug.log
```
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
---
## Error Handling
| Situation | Action |

File diff suppressed because it is too large Load Diff

View File

@@ -1,7 +1,7 @@
---
name: execute
description: Coordinate agent execution for workflow tasks with automatic session discovery, parallel task processing, and status tracking
argument-hint: "[--resume-session=\"session-id\"]"
argument-hint: "[-y|--yes] [--resume-session=\"session-id\"]"
---
# Workflow Execute Command
@@ -11,6 +11,30 @@ Orchestrates autonomous workflow execution through systematic task discovery, ag
**Resume Mode**: When called with `--resume-session` flag, skips discovery phase and directly enters TodoWrite generation and agent execution for the specified session.
## Usage
```bash
# Interactive mode (with confirmations)
/workflow:execute
/workflow:execute --resume-session="WFS-auth"
# Auto mode (skip confirmations, use defaults)
/workflow:execute --yes
/workflow:execute -y
/workflow:execute -y --resume-session="WFS-auth"
```
## Auto Mode Defaults
When `--yes` or `-y` flag is used:
- **Session Selection**: Automatically selects the first (most recent) active session
- **Completion Choice**: Automatically completes session (runs `/workflow:session:complete --yes`)
**Flag Parsing**:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
```
## Performance Optimization Strategy
**Lazy Loading**: Task JSONs read **on-demand** during execution, not upfront. TODO_LIST.md + IMPL_PLAN.md provide metadata for planning.
@@ -23,7 +47,7 @@ Orchestrates autonomous workflow execution through systematic task discovery, ag
## Core Rules
**Complete entire workflow autonomously without user interruption, using TodoWrite for comprehensive progress tracking.**
**Execute all discovered pending tasks until workflow completion or blocking dependency.**
**Auto-complete session when all tasks finished: Call `/workflow:session:complete` upon workflow completion.**
**User-choice completion: When all tasks finished, ask user to choose review or complete.**
**ONE AGENT = ONE TASK JSON: Each agent instance executes exactly one task JSON file - never batch multiple tasks into single agent execution.**
## Core Responsibilities
@@ -33,7 +57,7 @@ Orchestrates autonomous workflow execution through systematic task discovery, ag
- **Agent Orchestration**: Coordinate specialized agents with complete context
- **Status Synchronization**: Update task JSON files and workflow state
- **Autonomous Completion**: Continue execution until all tasks complete or reach blocking state
- **Session Auto-Complete**: Call `/workflow:session:complete` when all workflow tasks finished
- **Session User-Choice Completion**: Ask user to choose review or complete when all tasks finished
## Execution Philosophy
- **Progress tracking**: Continuous TodoWrite updates throughout entire workflow execution
@@ -76,7 +100,9 @@ Phase 4: Execution Strategy & Task Execution
Phase 5: Completion
├─ Update task statuses in JSON files
├─ Generate summaries
└─ Auto-call /workflow:session:complete
└─ AskUserQuestion: Choose next step
├─ "Enter Review" → /workflow:review
└─ "Complete Session" → /workflow:session:complete
Resume Mode (--resume-session):
├─ Skip Phase 1 & Phase 2
@@ -117,34 +143,41 @@ Auto-select and continue to Phase 2.
List sessions with metadata and prompt user selection:
```bash
bash(for dir in .workflow/active/WFS-*/; do
session=$(basename "$dir")
project=$(jq -r '.project // "Unknown"' "$dir/workflow-session.json" 2>/dev/null)
total=$(grep -c "^- \[" "$dir/TODO_LIST.md" 2>/dev/null || echo "0")
completed=$(grep -c "^- \[x\]" "$dir/TODO_LIST.md" 2>/dev/null || echo "0")
[ "$total" -gt 0 ] && progress=$((completed * 100 / total)) || progress=0
echo "${session} | ${project} | ${completed}/${total} tasks (${progress}%)"
done)
bash(for dir in .workflow/active/WFS-*/; do [ -d "$dir" ] || continue; session=$(basename "$dir"); project=$(jq -r '.project // "Unknown"' "${dir}workflow-session.json" 2>/dev/null || echo "Unknown"); total=$(grep -c '^\- \[' "${dir}TODO_LIST.md" 2>/dev/null || echo 0); completed=$(grep -c '^\- \[x\]' "${dir}TODO_LIST.md" 2>/dev/null || echo 0); if [ "$total" -gt 0 ]; then progress=$((completed * 100 / total)); else progress=0; fi; echo "$session | $project | $completed/$total tasks ($progress%)"; done)
```
Use AskUserQuestion to present formatted options (max 4 options shown):
**Parse --yes flag**:
```javascript
// If more than 4 sessions, show most recent 4 with "Other" option for manual input
const sessions = getActiveSessions() // sorted by last modified
const displaySessions = sessions.slice(0, 4)
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
```
AskUserQuestion({
questions: [{
question: "Multiple active sessions detected. Select one:",
header: "Session",
multiSelect: false,
options: displaySessions.map(s => ({
label: s.id,
description: `${s.project} | ${s.progress}`
}))
// Note: User can select "Other" to manually enter session ID
}]
})
**Conditional Selection**:
```javascript
if (autoYes) {
// Auto mode: Select first session (most recent)
const firstSession = sessions[0]
console.log(`[--yes] Auto-selecting session: ${firstSession.id}`)
selectedSessionId = firstSession.id
// Continue to Phase 2
} else {
// Interactive mode: Use AskUserQuestion to present formatted options (max 4 options shown)
// If more than 4 sessions, show most recent 4 with "Other" option for manual input
const sessions = getActiveSessions() // sorted by last modified
const displaySessions = sessions.slice(0, 4)
AskUserQuestion({
questions: [{
question: "Multiple active sessions detected. Select one:",
header: "Session",
multiSelect: false,
options: displaySessions.map(s => ({
label: s.id,
description: `${s.project} | ${s.progress}`
}))
// Note: User can select "Other" to manually enter session ID
}]
})
}
```
**Input Validation**:
@@ -254,7 +287,45 @@ while (TODO_LIST.md has pending tasks) {
3. **Update TodoWrite**: Mark current task complete, advance to next
4. **Synchronize State**: Update session state and workflow status
5. **Check Workflow Complete**: Verify all tasks are completed
6. **Auto-Complete Session**: Call `/workflow:session:complete` when all tasks finished
6. **User Choice**: When all tasks finished, ask user to choose next step:
```javascript
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
// Auto mode: Complete session automatically
console.log(`[--yes] Auto-selecting: Complete Session`)
SlashCommand("/workflow:session:complete --yes")
} else {
// Interactive mode: Ask user
AskUserQuestion({
questions: [{
question: "All tasks completed. What would you like to do next?",
header: "Next Step",
multiSelect: false,
options: [
{
label: "Enter Review",
description: "Run specialized review (security/architecture/quality/action-items)"
},
{
label: "Complete Session",
description: "Archive session and update manifest"
}
]
}]
})
}
```
**Based on user selection**:
- **"Enter Review"**: Execute `/workflow:review`
- **"Complete Session"**: Execute `/workflow:session:complete`
### Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
## Execution Strategy (IMPL_PLAN-Driven)
@@ -330,7 +401,7 @@ blocked → skip until dependencies clear
- **Continuous Tracking**: Maintain TodoWrite throughout entire workflow execution until completion
**Rule 4: Workflow Completion Check**
- When all tasks marked `completed`, auto-call `/workflow:session:complete`
- When all tasks marked `completed`, prompt user to choose review or complete session
### TodoWrite Tool Usage
@@ -388,40 +459,40 @@ TodoWrite({
**Note**: Orchestrator does NOT execute flow control steps - Agent interprets and executes them autonomously.
### Agent Prompt Template
**Dynamic Generation**: Before agent invocation, read task JSON and extract key requirements.
**Path-Based Invocation**: Pass paths and trigger markers, let agent parse task JSON autonomously.
```bash
Task(subagent_type="{meta.agent}",
run_in_background=false,
prompt="Execute task: {task.title}
prompt="Implement task {task.id}: {task.title}
{[FLOW_CONTROL]}
[FLOW_CONTROL]
**Task Objectives** (from task JSON):
{task.context.objective}
**Expected Deliverables** (from task JSON):
{task.context.deliverables}
**Quality Standards** (from task JSON):
{task.context.acceptance_criteria}
**MANDATORY FIRST STEPS**:
1. Read complete task JSON: {session.task_json_path}
2. Load context package: {session.context_package_path}
Follow complete execution guidelines in @.claude/agents/{meta.agent}.md
**Session Paths**:
- Workflow Dir: {session.workflow_dir}
- TODO List: {session.todo_list_path}
- Summaries Dir: {session.summaries_dir}
**Input**:
- Task JSON: {session.task_json_path}
- Context Package: {session.context_package_path}
**Success Criteria**: Complete all objectives, meet all quality standards, deliver all outputs as specified above.",
description="Executing: {task.title}")
**Output Location**:
- Workflow: {session.workflow_dir}
- TODO List: {session.todo_list_path}
- Summaries: {session.summaries_dir}
**Execution**: Read task JSON → Parse flow_control → Execute implementation_approach → Update TODO_LIST.md → Generate summary",
description="Implement: {task.id}")
```
**Key Markers**:
- `Implement` keyword: Triggers tech stack detection and guidelines loading
- `[FLOW_CONTROL]`: Triggers flow_control.pre_analysis execution
**Why Path-Based**: Agent (code-developer.md) autonomously:
- Reads and parses task JSON (requirements, acceptance, flow_control)
- Loads tech stack guidelines based on detected language
- Executes pre_analysis steps and implementation_approach
- Generates structured summary with integration points
Embedding task content in prompt creates duplication and conflicts with agent's parsing logic.
### Agent Assignment Rules
```
meta.agent specified → Use specified agent

View File

@@ -10,7 +10,11 @@ examples:
# Workflow Init Command (/workflow:init)
## Overview
Initialize `.workflow/project.json` with comprehensive project understanding by delegating analysis to **cli-explore-agent**.
Initialize `.workflow/project-tech.json` and `.workflow/project-guidelines.json` with comprehensive project understanding by delegating analysis to **cli-explore-agent**.
**Dual File System**:
- `project-tech.json`: Auto-generated technical analysis (stack, architecture, components)
- `project-guidelines.json`: User-maintained rules and constraints (created as scaffold)
**Note**: This command may be called by other workflow commands. Upon completion, return immediately to continue the calling workflow without interrupting the task flow.
@@ -27,7 +31,7 @@ Input Parsing:
└─ Parse --regenerate flag → regenerate = true | false
Decision:
├─ EXISTS + no --regenerate → Exit: "Already initialized"
├─ BOTH_EXIST + no --regenerate → Exit: "Already initialized"
├─ EXISTS + --regenerate → Backup existing → Continue analysis
└─ NOT_FOUND → Continue analysis
@@ -37,11 +41,14 @@ Analysis Flow:
│ ├─ Structural scan (get_modules_by_depth.sh, find, wc)
│ ├─ Semantic analysis (Gemini CLI)
│ ├─ Synthesis and merge
│ └─ Write .workflow/project.json
│ └─ Write .workflow/project-tech.json
├─ Create guidelines scaffold (if not exists)
│ └─ Write .workflow/project-guidelines.json (empty structure)
└─ Display summary
Output:
─ .workflow/project.json (+ .backup if regenerate)
─ .workflow/project-tech.json (+ .backup if regenerate)
└─ .workflow/project-guidelines.json (scaffold if new)
```
## Implementation
@@ -56,13 +63,18 @@ const regenerate = $ARGUMENTS.includes('--regenerate')
**Check existing state**:
```bash
bash(test -f .workflow/project.json && echo "EXISTS" || echo "NOT_FOUND")
bash(test -f .workflow/project-tech.json && echo "TECH_EXISTS" || echo "TECH_NOT_FOUND")
bash(test -f .workflow/project-guidelines.json && echo "GUIDELINES_EXISTS" || echo "GUIDELINES_NOT_FOUND")
```
**If EXISTS and no --regenerate**: Exit early
**If BOTH_EXIST and no --regenerate**: Exit early
```
Project already initialized at .workflow/project.json
Use /workflow:init --regenerate to rebuild
Project already initialized:
- Tech analysis: .workflow/project-tech.json
- Guidelines: .workflow/project-guidelines.json
Use /workflow:init --regenerate to rebuild tech analysis
Use /workflow:session:solidify to add guidelines
Use /workflow:status --project to view state
```
@@ -78,7 +90,7 @@ bash(mkdir -p .workflow)
**For --regenerate**: Backup and preserve existing data
```bash
bash(cp .workflow/project.json .workflow/project.json.backup)
bash(cp .workflow/project-tech.json .workflow/project-tech.json.backup)
```
**Delegate analysis to agent**:
@@ -89,21 +101,31 @@ Task(
run_in_background=false,
description="Deep project analysis",
prompt=`
Analyze project for workflow initialization and generate .workflow/project.json.
Analyze project for workflow initialization and generate .workflow/project-tech.json.
## MANDATORY FIRST STEPS
1. Execute: cat ~/.claude/workflows/cli-templates/schemas/project-json-schema.json (get schema reference)
1. Execute: cat ~/.claude/workflows/cli-templates/schemas/project-tech-schema.json (get schema reference)
2. Execute: ccw tool exec get_modules_by_depth '{}' (get project structure)
## Task
Generate complete project.json with:
- project_name: ${projectName}
- initialized_at: current ISO timestamp
- overview: {description, technology_stack, architecture, key_components}
- features: ${regenerate ? 'preserve from backup' : '[] (empty)'}
Generate complete project-tech.json following the schema structure:
- project_name: "${projectName}"
- initialized_at: ISO 8601 timestamp
- overview: {
description: "Brief project description",
technology_stack: {
languages: [{name, file_count, primary}],
frameworks: ["string"],
build_tools: ["string"],
test_frameworks: ["string"]
},
architecture: {style, layers: [], patterns: []},
key_components: [{name, path, description, importance}]
}
- features: []
- development_index: ${regenerate ? 'preserve from backup' : '{feature: [], enhancement: [], bugfix: [], refactor: [], docs: []}'}
- statistics: ${regenerate ? 'preserve from backup' : '{total_features: 0, total_sessions: 0, last_updated}'}
- _metadata: {initialized_by: "cli-explore-agent", analysis_timestamp, analysis_mode}
- statistics: ${regenerate ? 'preserve from backup' : '{total_features: 0, total_sessions: 0, last_updated: ISO timestamp}'}
- _metadata: {initialized_by: "cli-explore-agent", analysis_timestamp: ISO timestamp, analysis_mode: "deep-scan"}
## Analysis Requirements
@@ -123,8 +145,8 @@ Generate complete project.json with:
1. Structural scan: get_modules_by_depth.sh, find, wc -l
2. Semantic analysis: Gemini for patterns/architecture
3. Synthesis: Merge findings
4. ${regenerate ? 'Merge with preserved features/development_index/statistics from .workflow/project.json.backup' : ''}
5. Write JSON: Write('.workflow/project.json', jsonContent)
4. ${regenerate ? 'Merge with preserved development_index and statistics from .workflow/project-tech.json.backup' : ''}
5. Write JSON: Write('.workflow/project-tech.json', jsonContent)
6. Report: Return brief completion summary
Project root: ${projectRoot}
@@ -132,29 +154,66 @@ Project root: ${projectRoot}
)
```
### Step 3.5: Create Guidelines Scaffold (if not exists)
```javascript
// Only create if not exists (never overwrite user guidelines)
if (!file_exists('.workflow/project-guidelines.json')) {
const guidelinesScaffold = {
conventions: {
coding_style: [],
naming_patterns: [],
file_structure: [],
documentation: []
},
constraints: {
architecture: [],
tech_stack: [],
performance: [],
security: []
},
quality_rules: [],
learnings: [],
_metadata: {
created_at: new Date().toISOString(),
version: "1.0.0"
}
};
Write('.workflow/project-guidelines.json', JSON.stringify(guidelinesScaffold, null, 2));
}
```
### Step 4: Display Summary
```javascript
const projectJson = JSON.parse(Read('.workflow/project.json'));
const projectTech = JSON.parse(Read('.workflow/project-tech.json'));
const guidelinesExists = file_exists('.workflow/project-guidelines.json');
console.log(`
✓ Project initialized successfully
## Project Overview
Name: ${projectJson.project_name}
Description: ${projectJson.overview.description}
Name: ${projectTech.project_name}
Description: ${projectTech.overview.description}
### Technology Stack
Languages: ${projectJson.overview.technology_stack.languages.map(l => l.name).join(', ')}
Frameworks: ${projectJson.overview.technology_stack.frameworks.join(', ')}
Languages: ${projectTech.overview.technology_stack.languages.map(l => l.name).join(', ')}
Frameworks: ${projectTech.overview.technology_stack.frameworks.join(', ')}
### Architecture
Style: ${projectJson.overview.architecture.style}
Components: ${projectJson.overview.key_components.length} core modules
Style: ${projectTech.overview.architecture.style}
Components: ${projectTech.overview.key_components.length} core modules
---
Project state: .workflow/project.json
${regenerate ? 'Backup: .workflow/project.json.backup' : ''}
Files created:
- Tech analysis: .workflow/project-tech.json
- Guidelines: .workflow/project-guidelines.json ${guidelinesExists ? '(scaffold)' : ''}
${regenerate ? '- Backup: .workflow/project-tech.json.backup' : ''}
Next steps:
- Use /workflow:session:solidify to add project guidelines
- Use /workflow:plan to start planning
`);
```

View File

@@ -1,7 +1,7 @@
---
name: lite-execute
description: Execute tasks based on in-memory plan, prompt description, or file content
argument-hint: "[--in-memory] [\"task description\"|file-path]"
argument-hint: "[-y|--yes] [--in-memory] [\"task description\"|file-path]"
allowed-tools: TodoWrite(*), Task(*), Bash(*)
---
@@ -62,30 +62,49 @@ Flexible task execution command supporting three input modes: in-memory plan (fr
**User Interaction**:
```javascript
AskUserQuestion({
questions: [
{
question: "Select execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: "Auto-select based on complexity" }
]
},
{
question: "Enable code review after execution?",
header: "Code Review",
multiSelect: false,
options: [
{ label: "Skip", description: "No review" },
{ label: "Gemini Review", description: "Gemini CLI tool" },
{ label: "Agent Review", description: "Current agent review" }
]
}
]
})
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
let userSelection
if (autoYes) {
// Auto mode: Use defaults
console.log(`[--yes] Auto-confirming execution:`)
console.log(` - Execution method: Auto`)
console.log(` - Code review: Skip`)
userSelection = {
execution_method: "Auto",
code_review_tool: "Skip"
}
} else {
// Interactive mode: Ask user
userSelection = AskUserQuestion({
questions: [
{
question: "Select execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: "Auto-select based on complexity" }
]
},
{
question: "Enable code review after execution?",
header: "Code Review",
multiSelect: false,
options: [
{ label: "Skip", description: "No review" },
{ label: "Gemini Review", description: "Gemini CLI tool" },
{ label: "Codex Review", description: "Git-aware review (prompt OR --uncommitted)" },
{ label: "Agent Review", description: "Current agent review" }
]
}
]
})
}
```
### Mode 3: File Content
@@ -171,10 +190,23 @@ Output:
**Operations**:
- Initialize result tracking for multi-execution scenarios
- Set up `previousExecutionResults` array for context continuity
- **In-Memory Mode**: Echo execution strategy from lite-plan for transparency
```javascript
// Initialize result tracking
previousExecutionResults = []
// In-Memory Mode: Echo execution strategy (transparency before execution)
if (executionContext) {
console.log(`
📋 Execution Strategy (from lite-plan):
Method: ${executionContext.executionMethod}
Review: ${executionContext.codeReviewTool}
Tasks: ${executionContext.planObject.tasks.length}
Complexity: ${executionContext.planObject.complexity}
${executionContext.executorAssignments ? ` Assignments: ${JSON.stringify(executionContext.executorAssignments)}` : ''}
`)
}
```
### Step 2: Task Grouping & Batch Creation
@@ -307,6 +339,85 @@ for (const call of sequential) {
}
```
### Unified Task Prompt Builder
**Task Formatting Principle**: Each task is a self-contained checklist. The executor only needs to know what THIS task requires. Same template for Agent and CLI.
```javascript
function buildExecutionPrompt(batch) {
// Task template (6 parts: Modification Points → Why → How → Reference → Risks → Done)
const formatTask = (t) => `
## ${t.title}
**Scope**: \`${t.scope}\` | **Action**: ${t.action}
### Modification Points
${t.modification_points.map(p => `- **${p.file}** → \`${p.target}\`: ${p.change}`).join('\n')}
${t.rationale ? `
### Why this approach (Medium/High)
${t.rationale.chosen_approach}
${t.rationale.decision_factors?.length > 0 ? `\nKey factors: ${t.rationale.decision_factors.join(', ')}` : ''}
${t.rationale.tradeoffs ? `\nTradeoffs: ${t.rationale.tradeoffs}` : ''}
` : ''}
### How to do it
${t.description}
${t.implementation.map(step => `- ${step}`).join('\n')}
${t.code_skeleton ? `
### Code skeleton (High)
${t.code_skeleton.interfaces?.length > 0 ? `**Interfaces**: ${t.code_skeleton.interfaces.map(i => `\`${i.name}\` - ${i.purpose}`).join(', ')}` : ''}
${t.code_skeleton.key_functions?.length > 0 ? `\n**Functions**: ${t.code_skeleton.key_functions.map(f => `\`${f.signature}\` - ${f.purpose}`).join(', ')}` : ''}
${t.code_skeleton.classes?.length > 0 ? `\n**Classes**: ${t.code_skeleton.classes.map(c => `\`${c.name}\` - ${c.purpose}`).join(', ')}` : ''}
` : ''}
### Reference
- Pattern: ${t.reference?.pattern || 'N/A'}
- Files: ${t.reference?.files?.join(', ') || 'N/A'}
${t.reference?.examples ? `- Notes: ${t.reference.examples}` : ''}
${t.risks?.length > 0 ? `
### Risk mitigations (High)
${t.risks.map(r => `- ${r.description} → **${r.mitigation}**`).join('\n')}
` : ''}
### Done when
${t.acceptance.map(c => `- [ ] ${c}`).join('\n')}
${t.verification?.success_metrics?.length > 0 ? `\n**Success metrics**: ${t.verification.success_metrics.join(', ')}` : ''}`
// Build prompt
const sections = []
if (originalUserInput) sections.push(`## Goal\n${originalUserInput}`)
sections.push(`## Tasks\n${batch.tasks.map(formatTask).join('\n\n---\n')}`)
// Context (reference only)
const context = []
if (previousExecutionResults.length > 0) {
context.push(`### Previous Work\n${previousExecutionResults.map(r => `- ${r.tasksSummary}: ${r.status}`).join('\n')}`)
}
if (clarificationContext) {
context.push(`### Clarifications\n${Object.entries(clarificationContext).map(([q, a]) => `- ${q}: ${a}`).join('\n')}`)
}
if (executionContext?.planObject?.data_flow?.diagram) {
context.push(`### Data Flow\n${executionContext.planObject.data_flow.diagram}`)
}
if (executionContext?.session?.artifacts?.plan) {
context.push(`### Artifacts\nPlan: ${executionContext.session.artifacts.plan}`)
}
// Project guidelines (user-defined constraints from /workflow:session:solidify)
context.push(`### Project Guidelines\n@.workflow/project-guidelines.json`)
if (context.length > 0) sections.push(`## Context\n${context.join('\n\n')}`)
sections.push(`Complete each task according to its "Done when" checklist.`)
return sections.join('\n\n')
}
```
**Option A: Agent Execution**
When to use:
@@ -314,113 +425,13 @@ When to use:
-`executionMethod = "Agent"` (全局 fallback)
-`executionMethod = "Auto" AND complexity = "Low"` (全局 fallback)
**Task Formatting Principle**: Each task is a self-contained checklist. The agent only needs to know what THIS task requires, not its position or relation to other tasks.
Agent call format:
```javascript
// Format single task as self-contained checklist
function formatTaskChecklist(task) {
return `
## ${task.title}
**Target**: \`${task.file}\`
**Action**: ${task.action}
### What to do
${task.description}
### How to do it
${task.implementation.map(step => `- ${step}`).join('\n')}
### Reference
- Pattern: ${task.reference.pattern}
- Examples: ${task.reference.files.join(', ')}
- Notes: ${task.reference.examples}
### Done when
${task.acceptance.map(c => `- [ ] ${c}`).join('\n')}
`
}
// For batch execution: aggregate tasks without numbering
function formatBatchPrompt(batch) {
const tasksSection = batch.tasks.map(t => formatTaskChecklist(t)).join('\n---\n')
return `
${originalUserInput ? `## Goal\n${originalUserInput}\n` : ''}
## Tasks
${tasksSection}
${batch.context ? `## Context\n${batch.context}` : ''}
Complete each task according to its "Done when" checklist.
`
}
Task(
subagent_type="code-developer",
run_in_background=false,
description=batch.taskSummary,
prompt=formatBatchPrompt({
tasks: batch.tasks,
context: buildRelevantContext(batch.tasks)
})
prompt=buildExecutionPrompt(batch)
)
// Helper: Build relevant context for batch
// Context serves as REFERENCE ONLY - helps agent understand existing state
function buildRelevantContext(tasks) {
const sections = []
// 1. Previous work completion - what's already done (reference for continuity)
if (previousExecutionResults.length > 0) {
sections.push(`### Previous Work (Reference)
Use this to understand what's already completed. Avoid duplicating work.
${previousExecutionResults.map(r => `**${r.tasksSummary}**
- Status: ${r.status}
- Outputs: ${r.keyOutputs || 'See git diff'}
${r.notes ? `- Notes: ${r.notes}` : ''}`
).join('\n\n')}`)
}
// 2. Related files - files that may need to be read/referenced
const relatedFiles = extractRelatedFiles(tasks)
if (relatedFiles.length > 0) {
sections.push(`### Related Files (Reference)
These files may contain patterns, types, or utilities relevant to your tasks:
${relatedFiles.map(f => `- \`${f}\``).join('\n')}`)
}
// 3. Clarifications from user
if (clarificationContext) {
sections.push(`### User Clarifications
${Object.entries(clarificationContext).map(([q, a]) => `- **${q}**: ${a}`).join('\n')}`)
}
// 4. Artifact files (for deeper context if needed)
if (executionContext?.session?.artifacts?.plan) {
sections.push(`### Artifacts
For detailed planning context, read: ${executionContext.session.artifacts.plan}`)
}
return sections.join('\n\n')
}
// Extract related files from task references
function extractRelatedFiles(tasks) {
const files = new Set()
tasks.forEach(task => {
// Add reference example files
if (task.reference?.files) {
task.reference.files.forEach(f => files.add(f))
}
})
return [...files]
}
```
**Result Collection**: After completion, collect result following `executionResult` structure (see Data Structures section)
@@ -432,92 +443,14 @@ When to use:
-`executionMethod = "Codex"` (全局 fallback)
-`executionMethod = "Auto" AND complexity = "Medium/High"` (全局 fallback)
**Task Formatting Principle**: Same as Agent - each task is a self-contained checklist. No task numbering or position awareness.
Command format:
```bash
// Format single task as compact checklist for CLI
function formatTaskForCLI(task) {
return `
## ${task.title}
File: ${task.file}
Action: ${task.action}
What: ${task.description}
How:
${task.implementation.map(step => `- ${step}`).join('\n')}
Reference: ${task.reference.pattern} (see ${task.reference.files.join(', ')})
Notes: ${task.reference.examples}
Done when:
${task.acceptance.map(c => `- [ ] ${c}`).join('\n')}
`
}
// Build CLI prompt for batch
// Context provides REFERENCE information - not requirements to fulfill
function buildCLIPrompt(batch) {
const tasksSection = batch.tasks.map(t => formatTaskForCLI(t)).join('\n---\n')
let prompt = `${originalUserInput ? `## Goal\n${originalUserInput}\n\n` : ''}`
prompt += `## Tasks\n\n${tasksSection}\n`
// Context section - reference information only
const contextSections = []
// 1. Previous work - what's already completed
if (previousExecutionResults.length > 0) {
contextSections.push(`### Previous Work (Reference)
Already completed - avoid duplicating:
${previousExecutionResults.map(r => `- ${r.tasksSummary}: ${r.status}${r.keyOutputs ? ` (${r.keyOutputs})` : ''}`).join('\n')}`)
}
// 2. Related files from task references
const relatedFiles = [...new Set(batch.tasks.flatMap(t => t.reference?.files || []))]
if (relatedFiles.length > 0) {
contextSections.push(`### Related Files (Reference)
Patterns and examples to follow:
${relatedFiles.map(f => `- ${f}`).join('\n')}`)
}
// 3. User clarifications
if (clarificationContext) {
contextSections.push(`### Clarifications
${Object.entries(clarificationContext).map(([q, a]) => `- ${q}: ${a}`).join('\n')}`)
}
// 4. Plan artifact for deeper context
if (executionContext?.session?.artifacts?.plan) {
contextSections.push(`### Artifacts
Detailed plan: ${executionContext.session.artifacts.plan}`)
}
if (contextSections.length > 0) {
prompt += `\n## Context\n${contextSections.join('\n\n')}\n`
}
prompt += `\nComplete each task according to its "Done when" checklist.`
return prompt
}
ccw cli -p "${buildCLIPrompt(batch)}" --tool codex --mode write
ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write
```
**Execution with fixed IDs** (predictable ID pattern):
```javascript
// Launch CLI in foreground (NOT background)
// Timeout based on complexity: Low=40min, Medium=60min, High=100min
const timeoutByComplexity = {
"Low": 2400000, // 40 minutes
"Medium": 3600000, // 60 minutes
"High": 6000000 // 100 minutes
}
// Launch CLI in background, wait for task hook callback
// Generate fixed execution ID: ${sessionId}-${groupId}
// This enables predictable ID lookup without relying on resume context chains
const sessionId = executionContext?.session?.id || 'standalone'
const fixedExecutionId = `${sessionId}-${batch.groupId}` // e.g., "implement-auth-2025-12-13-P1"
@@ -526,19 +459,15 @@ const previousCliId = batch.resumeFromCliId || null
// Build command with fixed ID (and optional resume for continuation)
const cli_command = previousCliId
? `ccw cli -p "${buildCLIPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId} --resume ${previousCliId}`
: `ccw cli -p "${buildCLIPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId}`
? `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId} --resume ${previousCliId}`
: `ccw cli -p "${buildExecutionPrompt(batch)}" --tool codex --mode write --id ${fixedExecutionId}`
bash_result = Bash(
// Execute in background, stop output and wait for task hook callback
Bash(
command=cli_command,
timeout=timeoutByComplexity[planObject.complexity] || 3600000
run_in_background=true
)
// Execution ID is now predictable: ${fixedExecutionId}
// Can also extract from output: "ID: implement-auth-2025-12-13-P1"
const cliExecutionId = fixedExecutionId
// Update TodoWrite when execution completes
// STOP HERE - CLI executes in background, task hook will notify on completion
```
**Resume on Failure** (with fixed ID):
@@ -564,8 +493,8 @@ if (bash_result.status === 'failed' || bash_result.status === 'timeout') {
When to use: `getTaskExecutor(task) === "gemini"` (分析类任务)
```bash
# 使用与 Option B 相同的 formatBatchPrompt切换 tool 和 mode
ccw cli -p "${formatBatchPrompt(batch)}" --tool gemini --mode analysis --id ${sessionId}-${batch.groupId}
# 使用统一的 buildExecutionPrompt切换 tool 和 mode
ccw cli -p "${buildExecutionPrompt(batch)}" --tool gemini --mode analysis --id ${sessionId}-${batch.groupId}
```
### Step 4: Progress Tracking
@@ -576,32 +505,41 @@ Progress tracked at batch level (not individual task level). Icons: ⚡ (paralle
**Skip Condition**: Only run if `codeReviewTool ≠ "Skip"`
**Review Focus**: Verify implementation against plan acceptance criteria
- Read plan.json for task acceptance criteria
**Review Focus**: Verify implementation against plan acceptance criteria and verification requirements
- Read plan.json for task acceptance criteria and verification checklist
- Check each acceptance criterion is fulfilled
- Verify success metrics from verification field (Medium/High complexity)
- Run unit/integration tests specified in verification field
- Validate code quality and identify issues
- Ensure alignment with planned approach
- Ensure alignment with planned approach and risk mitigations
**Operations**:
- Agent Review: Current agent performs direct review
- Gemini Review: Execute gemini CLI with review prompt
- Custom tool: Execute specified CLI tool (qwen, codex, etc.)
- Codex Review: Two options - (A) with prompt for complex reviews, (B) `--uncommitted` flag only for quick reviews
- Custom tool: Execute specified CLI tool (qwen, etc.)
**Unified Review Template** (All tools use same standard):
**Review Criteria**:
- **Acceptance Criteria**: Verify each criterion from plan.tasks[].acceptance
- **Verification Checklist** (Medium/High): Check unit_tests, integration_tests, success_metrics from plan.tasks[].verification
- **Code Quality**: Analyze quality, identify issues, suggest improvements
- **Plan Alignment**: Validate implementation matches planned approach
- **Plan Alignment**: Validate implementation matches planned approach and risk mitigations
**Shared Prompt Template** (used by all CLI tools):
```
PURPOSE: Code review for implemented changes against plan acceptance criteria
TASK: • Verify plan acceptance criteria fulfillment • Analyze code quality • Identify issues • Suggest improvements • Validate plan adherence
PURPOSE: Code review for implemented changes against plan acceptance criteria and verification requirements
TASK: • Verify plan acceptance criteria fulfillment • Check verification requirements (unit tests, success metrics) • Analyze code quality • Identify issues • Suggest improvements • Validate plan adherence and risk mitigations
MODE: analysis
CONTEXT: @**/* @{plan.json} [@{exploration.json}] | Memory: Review lite-execute changes against plan requirements
EXPECTED: Quality assessment with acceptance criteria verification, issue identification, and recommendations. Explicitly check each acceptance criterion from plan.json tasks.
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-review-code-quality.txt) | Focus on plan acceptance criteria and plan adherence | analysis=READ-ONLY
CONTEXT: @**/* @{plan.json} [@{exploration.json}] | Memory: Review lite-execute changes against plan requirements including verification checklist
EXPECTED: Quality assessment with:
- Acceptance criteria verification (all tasks)
- Verification checklist validation (Medium/High: unit_tests, integration_tests, success_metrics)
- Issue identification
- Recommendations
Explicitly check each acceptance criterion and verification item from plan.json tasks.
CONSTRAINTS: Focus on plan acceptance criteria, verification requirements, and plan adherence | analysis=READ-ONLY
```
**Tool-Specific Execution** (Apply shared prompt template above):
@@ -620,8 +558,17 @@ ccw cli -p "[Shared Prompt Template with artifacts]" --tool gemini --mode analys
ccw cli -p "[Shared Prompt Template with artifacts]" --tool qwen --mode analysis
# Same prompt as Gemini, different execution engine
# Method 4: Codex Review (autonomous)
ccw cli -p "[Verify plan acceptance criteria at ${plan.json}]" --tool codex --mode write
# Method 4: Codex Review (git-aware) - Two mutually exclusive options:
# Option A: With custom prompt (reviews uncommitted by default)
ccw cli -p "[Shared Prompt Template with artifacts]" --tool codex --mode review
# Use for complex reviews with specific focus areas
# Option B: Target flag only (no prompt allowed)
ccw cli --tool codex --mode review --uncommitted
# Quick review of uncommitted changes without custom instructions
# ⚠️ IMPORTANT: -p prompt and target flags (--uncommitted/--base/--commit) are MUTUALLY EXCLUSIVE
```
**Multi-Round Review with Fixed IDs**:
@@ -647,11 +594,11 @@ if (hasUnresolvedIssues(reviewResult)) {
**Trigger**: After all executions complete (regardless of code review)
**Skip Condition**: Skip if `.workflow/project.json` does not exist
**Skip Condition**: Skip if `.workflow/project-tech.json` does not exist
**Operations**:
```javascript
const projectJsonPath = '.workflow/project.json'
const projectJsonPath = '.workflow/project-tech.json'
if (!fileExists(projectJsonPath)) return // Silent skip
const projectJson = JSON.parse(Read(projectJsonPath))
@@ -780,6 +727,10 @@ Collected after each execution call completes:
Appended to `previousExecutionResults` array for context continuity in multi-execution scenarios.
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
**Fixed ID Pattern**: `${sessionId}-${groupId}` enables predictable lookup without auto-generated timestamps.
**Resume Usage**: If `status` is "partial" or "failed", use `fixedCliId` to resume:

View File

@@ -1,7 +1,7 @@
---
name: lite-fix
description: Lightweight bug diagnosis and fix workflow with intelligent severity assessment and optional hotfix mode for production incidents
argument-hint: "[--hotfix] \"bug description or issue reference\""
argument-hint: "[-y|--yes] [--hotfix] \"bug description or issue reference\""
allowed-tools: TodoWrite(*), Task(*), SlashCommand(*), AskUserQuestion(*)
---
@@ -17,7 +17,7 @@ Intelligent lightweight bug fixing command with dynamic workflow adaptation base
- Interactive clarification after diagnosis to gather missing information
- Adaptive fix planning strategy (direct Claude vs cli-lite-planning-agent) based on complexity
- Two-step confirmation: fix-plan display -> multi-dimensional input collection
- Execution dispatch with complete context handoff to lite-execute
- Execution execute with complete context handoff to lite-execute
## Usage
@@ -25,10 +25,32 @@ Intelligent lightweight bug fixing command with dynamic workflow adaptation base
/workflow:lite-fix [FLAGS] <BUG_DESCRIPTION>
# Flags
-y, --yes Skip all confirmations (auto mode)
--hotfix, -h Production hotfix mode (minimal diagnosis, fast fix)
# Arguments
<bug-description> Bug description, error message, or path to .md file (required)
# Examples
/workflow:lite-fix "用户登录失败" # Interactive mode
/workflow:lite-fix --yes "用户登录失败" # Auto mode (no confirmations)
/workflow:lite-fix -y --hotfix "生产环境数据库连接失败" # Auto + hotfix mode
```
## Auto Mode Defaults
When `--yes` or `-y` flag is used:
- **Clarification Questions**: Skipped (no clarification phase)
- **Fix Plan Confirmation**: Auto-selected "Allow"
- **Execution Method**: Auto-selected "Auto"
- **Code Review**: Auto-selected "Skip"
- **Severity**: Uses auto-detected severity (no manual override)
- **Hotfix Mode**: Respects --hotfix flag if present, otherwise normal mode
**Flag Parsing**:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const hotfixMode = $ARGUMENTS.includes('--hotfix') || $ARGUMENTS.includes('-h')
```
## Execution Process
@@ -62,7 +84,7 @@ Phase 4: Confirmation & Selection
|- Execution: Agent / Codex / Auto
+- Review: Gemini / Agent / Skip
Phase 5: Dispatch
Phase 5: Execute
|- Build executionContext (fix-plan + diagnoses + clarifications + selections)
+- SlashCommand("/workflow:lite-execute --in-memory --mode bugfix")
```
@@ -181,6 +203,8 @@ Execute **${angle}** diagnosis for bug root cause analysis. Analyze codebase fro
1. Run: ccw tool exec get_modules_by_depth '{}' (project structure)
2. Run: rg -l "{error_keyword_from_bug}" --type ts (locate relevant files)
3. Execute: cat ~/.claude/workflows/cli-templates/schemas/diagnosis-json-schema.json (get output schema reference)
4. Read: .workflow/project-tech.json (technology stack and architecture context)
5. Read: .workflow/project-guidelines.json (user-defined constraints and conventions)
## Diagnosis Strategy (${angle} focus)
@@ -330,9 +354,17 @@ function deduplicateClarifications(clarifications) {
const uniqueClarifications = deduplicateClarifications(allClarifications)
// Multi-round clarification: batch questions (max 4 per round)
// ⚠️ MUST execute ALL rounds until uniqueClarifications exhausted
if (uniqueClarifications.length > 0) {
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
// Auto mode: Skip clarification phase
console.log(`[--yes] Skipping ${uniqueClarifications.length} clarification questions`)
console.log(`Proceeding to fix planning with diagnosis results...`)
// Continue to Phase 3
} else if (uniqueClarifications.length > 0) {
// Interactive mode: Multi-round clarification
// ⚠️ MUST execute ALL rounds until uniqueClarifications exhausted
const BATCH_SIZE = 4
const totalRounds = Math.ceil(uniqueClarifications.length / BATCH_SIZE)
@@ -378,6 +410,7 @@ if (uniqueClarifications.length > 0) {
const schema = Bash(`cat ~/.claude/workflows/cli-templates/schemas/fix-plan-json-schema.json`)
// Step 2: Generate fix-plan following schema (Claude directly, no agent)
// For Medium complexity: include rationale + verification (optional, but recommended)
const fixPlan = {
summary: "...",
root_cause: "...",
@@ -387,13 +420,67 @@ const fixPlan = {
recommended_execution: "Agent",
severity: severity,
risk_level: "...",
_metadata: { timestamp: getUtc8ISOString(), source: "direct-planning", planning_mode: "direct" }
// Medium complexity fields (optional for direct planning, auto-filled for Low)
...(severity === "Medium" ? {
design_decisions: [
{
decision: "Use immediate_patch strategy for minimal risk",
rationale: "Keeps changes localized and quick to review",
tradeoff: "Defers comprehensive refactoring"
}
],
tasks_with_rationale: {
// Each task gets rationale if Medium
task_rationale_example: {
rationale: {
chosen_approach: "Direct fix approach",
alternatives_considered: ["Workaround", "Refactor"],
decision_factors: ["Minimal impact", "Quick turnaround"],
tradeoffs: "Doesn't address underlying issue"
},
verification: {
unit_tests: ["test_bug_fix_basic"],
integration_tests: [],
manual_checks: ["Reproduce issue", "Verify fix"],
success_metrics: ["Issue resolved", "No regressions"]
}
}
}
} : {}),
_metadata: {
timestamp: getUtc8ISOString(),
source: "direct-planning",
planning_mode: "direct",
complexity: severity === "Medium" ? "Medium" : "Low"
}
}
// Step 3: Write fix-plan to session folder
// Step 3: Merge task rationale into tasks array
if (severity === "Medium") {
fixPlan.tasks = fixPlan.tasks.map(task => ({
...task,
rationale: fixPlan.tasks_with_rationale[task.id]?.rationale || {
chosen_approach: "Standard fix",
alternatives_considered: [],
decision_factors: ["Correctness", "Simplicity"],
tradeoffs: "None"
},
verification: fixPlan.tasks_with_rationale[task.id]?.verification || {
unit_tests: [`test_${task.id}_basic`],
integration_tests: [],
manual_checks: ["Verify fix works"],
success_metrics: ["Test pass"]
}
}))
delete fixPlan.tasks_with_rationale // Clean up temp field
}
// Step 4: Write fix-plan to session folder
Write(`${sessionFolder}/fix-plan.json`, JSON.stringify(fixPlan, null, 2))
// Step 4: MUST continue to Phase 4 (Confirmation) - DO NOT execute code here
// Step 5: MUST continue to Phase 4 (Confirmation) - DO NOT execute code here
```
**High/Critical Severity** - Invoke cli-lite-planning-agent:
@@ -409,6 +496,12 @@ Generate fix plan and write fix-plan.json.
## Output Schema Reference
Execute: cat ~/.claude/workflows/cli-templates/schemas/fix-plan-json-schema.json (get schema reference before generating plan)
## Project Context (MANDATORY - Read Both Files)
1. Read: .workflow/project-tech.json (technology stack, architecture, key components)
2. Read: .workflow/project-guidelines.json (user-defined constraints and conventions)
**CRITICAL**: All fix tasks MUST comply with constraints in project-guidelines.json
## Bug Description
${bug_description}
@@ -443,11 +536,41 @@ Generate fix-plan.json with:
- description
- modification_points: ALL files to modify for this fix (group related changes)
- implementation (2-5 steps covering all modification_points)
- verification (test criteria)
- acceptance: Quantified acceptance criteria
- depends_on: task IDs this task depends on (use sparingly)
**High/Critical complexity fields per task** (REQUIRED):
- rationale:
- chosen_approach: Why this fix approach (not alternatives)
- alternatives_considered: Other approaches evaluated
- decision_factors: Key factors influencing choice
- tradeoffs: Known tradeoffs of this approach
- verification:
- unit_tests: Test names to add/verify
- integration_tests: Integration test names
- manual_checks: Manual verification steps
- success_metrics: Quantified success criteria
- risks:
- description: Risk description
- probability: Low|Medium|High
- impact: Low|Medium|High
- mitigation: How to mitigate
- fallback: Fallback if fix fails
- code_skeleton (optional): Key interfaces/functions to implement
- interfaces: [{name, definition, purpose}]
- key_functions: [{signature, purpose, returns}]
**Top-level High/Critical fields** (REQUIRED):
- data_flow: How data flows through affected code
- diagram: "A → B → C" style flow
- stages: [{stage, input, output, component}]
- design_decisions: Global fix decisions
- [{decision, rationale, tradeoff}]
- estimated_time, recommended_execution, severity, risk_level
- _metadata:
- timestamp, source, planning_mode
- complexity: "High" | "Critical"
- diagnosis_angles: ${JSON.stringify(manifest.diagnoses.map(d => d.angle))}
## Task Grouping Rules
@@ -459,11 +582,21 @@ Generate fix-plan.json with:
## Execution
1. Read ALL diagnosis files for comprehensive context
2. Execute CLI planning using Gemini (Qwen fallback)
2. Execute CLI planning using Gemini (Qwen fallback) with --rule planning-fix-strategy template
3. Synthesize findings from multiple diagnosis angles
4. Parse output and structure fix-plan
5. Write JSON: Write('${sessionFolder}/fix-plan.json', jsonContent)
6. Return brief completion summary
4. Generate fix-plan with:
- For High/Critical: REQUIRED new fields (rationale, verification, risks, code_skeleton, data_flow, design_decisions)
- Each task MUST have rationale (why this fix), verification (how to verify success), and risks (potential issues)
5. Parse output and structure fix-plan
6. Write JSON: Write('${sessionFolder}/fix-plan.json', jsonContent)
7. Return brief completion summary
## Output Format for CLI
Include these sections in your fix-plan output:
- Summary, Root Cause, Strategy (existing)
- Data Flow: Diagram showing affected code paths
- Design Decisions: Key architectural choices in the fix
- Tasks: Each with rationale (Medium/High), verification (Medium/High), risks (High), code_skeleton (High)
`
)
```
@@ -497,45 +630,65 @@ ${fixPlan.tasks.map((t, i) => `${i+1}. ${t.title} (${t.scope})`).join('\n')}
**Step 4.2: Collect Confirmation**
```javascript
AskUserQuestion({
questions: [
{
question: `Confirm fix plan? (${fixPlan.tasks.length} tasks, ${fixPlan.severity} severity)`,
header: "Confirm",
multiSelect: true,
options: [
{ label: "Allow", description: "Proceed as-is" },
{ label: "Modify", description: "Adjust before execution" },
{ label: "Cancel", description: "Abort workflow" }
]
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: `Auto: ${fixPlan.severity === 'Low' ? 'Agent' : 'Codex'}` }
]
},
{
question: "Code review after fix?",
header: "Review",
multiSelect: false,
options: [
{ label: "Gemini Review", description: "Gemini CLI" },
{ label: "Agent Review", description: "@code-reviewer" },
{ label: "Skip", description: "No review" }
]
}
]
})
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
let userSelection
if (autoYes) {
// Auto mode: Use defaults
console.log(`[--yes] Auto-confirming fix plan:`)
console.log(` - Confirmation: Allow`)
console.log(` - Execution: Auto`)
console.log(` - Review: Skip`)
userSelection = {
confirmation: "Allow",
execution_method: "Auto",
code_review_tool: "Skip"
}
} else {
// Interactive mode: Ask user
userSelection = AskUserQuestion({
questions: [
{
question: `Confirm fix plan? (${fixPlan.tasks.length} tasks, ${fixPlan.severity} severity)`,
header: "Confirm",
multiSelect: false,
options: [
{ label: "Allow", description: "Proceed as-is" },
{ label: "Modify", description: "Adjust before execution" },
{ label: "Cancel", description: "Abort workflow" }
]
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: `Auto: ${fixPlan.severity === 'Low' ? 'Agent' : 'Codex'}` }
]
},
{
question: "Code review after fix?",
header: "Review",
multiSelect: false,
options: [
{ label: "Gemini Review", description: "Gemini CLI" },
{ label: "Agent Review", description: "@code-reviewer" },
{ label: "Skip", description: "No review" }
]
}
]
})
}
```
---
### Phase 5: Dispatch to Execution
### Phase 5: Execute to Execution
**CRITICAL**: lite-fix NEVER executes code directly. ALL execution MUST go through lite-execute.
@@ -557,7 +710,11 @@ const fixPlan = JSON.parse(Read(`${sessionFolder}/fix-plan.json`))
executionContext = {
mode: "bugfix",
severity: fixPlan.severity,
planObject: fixPlan,
planObject: {
...fixPlan,
// Ensure complexity is set based on severity for new field consumption
complexity: fixPlan.complexity || (fixPlan.severity === 'Critical' ? 'High' : (fixPlan.severity === 'High' ? 'High' : 'Medium'))
},
diagnosisContext: diagnoses,
diagnosisAngles: manifest.diagnoses.map(d => d.angle),
diagnosisManifest: manifest,
@@ -580,7 +737,7 @@ executionContext = {
}
```
**Step 5.2: Dispatch**
**Step 5.2: Execute**
```javascript
SlashCommand(command="/workflow:lite-execute --in-memory --mode bugfix")

View File

@@ -0,0 +1,465 @@
---
name: workflow:lite-lite-lite
description: Ultra-lightweight multi-tool analysis and direct execution. No artifacts for simple tasks; auto-creates planning docs in .workflow/.scratchpad/ for complex tasks. Auto tool selection based on task analysis, user-driven iteration via AskUser.
argument-hint: "[-y|--yes] <task description>"
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), Write(*), mcp__ace-tool__search_context(*), mcp__ccw-tools__write_file(*)
---
## Auto Mode
When `--yes` or `-y`: Skip clarification questions, auto-select tools, execute directly with recommended settings.
# Ultra-Lite Multi-Tool Workflow
## Quick Start
```bash
/workflow:lite-lite-lite "Fix the login bug"
/workflow:lite-lite-lite "Refactor payment module for multi-gateway support"
```
**Core Philosophy**: Minimal friction, maximum velocity. Simple tasks = no artifacts. Complex tasks = lightweight planning doc in `.workflow/.scratchpad/`.
## Overview
**Complexity-aware workflow**: Clarify → Assess Complexity → Select Tools → Multi-Mode Analysis → Decision → Direct Execution
**vs multi-cli-plan**: No IMPL_PLAN.md, plan.json, synthesis.json - state in memory or lightweight scratchpad doc for complex tasks.
## Execution Flow
```
Phase 1: Clarify Requirements → AskUser for missing details
Phase 1.5: Assess Complexity → Determine if planning doc needed
Phase 2: Select Tools (CLI → Mode → Agent) → 3-step selection
Phase 3: Multi-Mode Analysis → Execute with --resume chaining
Phase 4: User Decision → Execute / Refine / Change / Cancel
Phase 5: Direct Execution → No plan files (simple) or scratchpad doc (complex)
```
## Phase 1: Clarify Requirements
```javascript
const taskDescription = $ARGUMENTS
if (taskDescription.length < 20 || isAmbiguous(taskDescription)) {
AskUserQuestion({
questions: [{
question: "Please provide more details: target files/modules, expected behavior, constraints?",
header: "Details",
options: [
{ label: "I'll provide more", description: "Add more context" },
{ label: "Continue analysis", description: "Let tools explore autonomously" }
],
multiSelect: false
}]
})
}
// Optional: Quick ACE Context for complex tasks
mcp__ace-tool__search_context({
project_root_path: process.cwd(),
query: `${taskDescription} implementation patterns`
})
```
## Phase 1.5: Assess Complexity
| Level | Creates Plan Doc | Trigger Keywords |
|-------|------------------|------------------|
| **simple** | ❌ | (default) |
| **moderate** | ✅ | module, system, service, integration, multiple |
| **complex** | ✅ | refactor, migrate, security, auth, payment, database |
```javascript
// Complexity detection (after ACE query)
const isComplex = /refactor|migrate|security|auth|payment|database/i.test(taskDescription)
const isModerate = /module|system|service|integration|multiple/i.test(taskDescription) || aceContext?.relevant_files?.length > 2
if (isComplex || isModerate) {
const planPath = `.workflow/.scratchpad/lite3-${taskSlug}-${dateStr}.md`
// Create planning doc with: Task, Status, Complexity, Analysis Summary, Execution Plan, Progress Log
}
```
## Phase 2: Select Tools
### Tool Definitions
**CLI Tools** (from cli-tools.json):
```javascript
const cliConfig = JSON.parse(Read("~/.claude/cli-tools.json"))
const cliTools = Object.entries(cliConfig.tools)
.filter(([_, config]) => config.enabled)
.map(([name, config]) => ({
name, type: 'cli',
tags: config.tags || [],
model: config.primaryModel,
toolType: config.type // builtin, cli-wrapper, api-endpoint
}))
```
**Sub Agents**:
| Agent | Strengths | canExecute |
|-------|-----------|------------|
| **code-developer** | Code implementation, test writing | ✅ |
| **Explore** | Fast code exploration, pattern discovery | ❌ |
| **cli-explore-agent** | Dual-source analysis (Bash+CLI) | ❌ |
| **cli-discuss-agent** | Multi-CLI collaboration, cross-verification | ❌ |
| **debug-explore-agent** | Hypothesis-driven debugging | ❌ |
| **context-search-agent** | Multi-layer file discovery, dependency analysis | ❌ |
| **test-fix-agent** | Test execution, failure diagnosis, code fixing | ✅ |
| **universal-executor** | General execution, multi-domain adaptation | ✅ |
**Analysis Modes**:
| Mode | Pattern | Use Case | minCLIs |
|------|---------|----------|---------|
| **Parallel** | `A \|\| B \|\| C → Aggregate` | Fast multi-perspective | 1+ |
| **Sequential** | `A → B(resume) → C(resume)` | Incremental deepening | 2+ |
| **Collaborative** | `A → B → A → B → Synthesize` | Multi-round refinement | 2+ |
| **Debate** | `A(propose) → B(challenge) → A(defend)` | Adversarial validation | 2 |
| **Challenge** | `A(analyze) → B(challenge)` | Find flaws and risks | 2 |
### Three-Step Selection Flow
```javascript
// Step 1: Select CLIs (multiSelect)
AskUserQuestion({
questions: [{
question: "Select CLI tools for analysis (1-3 for collaboration modes)",
header: "CLI Tools",
options: cliTools.map(cli => ({
label: cli.name,
description: cli.tags.length > 0 ? cli.tags.join(', ') : cli.model || 'general'
})),
multiSelect: true
}]
})
// Step 2: Select Mode (filtered by CLI count)
const availableModes = analysisModes.filter(m => selectedCLIs.length >= m.minCLIs)
AskUserQuestion({
questions: [{
question: "Select analysis mode",
header: "Mode",
options: availableModes.map(m => ({
label: m.label,
description: `${m.description} [${m.pattern}]`
})),
multiSelect: false
}]
})
// Step 3: Select Agent for execution
AskUserQuestion({
questions: [{
question: "Select Sub Agent for execution",
header: "Agent",
options: agents.map(a => ({ label: a.name, description: a.strength })),
multiSelect: false
}]
})
// Confirm selection
AskUserQuestion({
questions: [{
question: "Confirm selection?",
header: "Confirm",
options: [
{ label: "Confirm and continue", description: `${selectedMode.label} with ${selectedCLIs.length} CLIs` },
{ label: "Re-select CLIs", description: "Choose different CLI tools" },
{ label: "Re-select Mode", description: "Choose different analysis mode" },
{ label: "Re-select Agent", description: "Choose different Sub Agent" }
],
multiSelect: false
}]
})
```
## Phase 3: Multi-Mode Analysis
### Universal CLI Prompt Template
```javascript
// Unified prompt builder - used by all modes
function buildPrompt({ purpose, tasks, expected, rules, taskDescription }) {
return `
PURPOSE: ${purpose}: ${taskDescription}
TASK: ${tasks.map(t => `${t}`).join(' ')}
MODE: analysis
CONTEXT: @**/*
EXPECTED: ${expected}
CONSTRAINTS: ${rules}
`
}
// Execute CLI with prompt
function execCLI(cli, prompt, options = {}) {
const { resume, background = false } = options
const resumeFlag = resume ? `--resume ${resume}` : ''
return Bash({
command: `ccw cli -p "${prompt}" --tool ${cli.name} --mode analysis ${resumeFlag}`,
run_in_background: background
})
}
```
### Prompt Presets by Role
| Role | PURPOSE | TASKS | EXPECTED | RULES |
|------|---------|-------|----------|-------|
| **initial** | Initial analysis | Identify files, Analyze approach, List changes | Root cause, files, changes, risks | Focus on actionable insights |
| **extend** | Build on previous | Review previous, Extend, Add insights | Extended analysis building on findings | Build incrementally, avoid repetition |
| **synthesize** | Refine and synthesize | Review, Identify gaps, Synthesize | Refined synthesis with new perspectives | Add value not repetition |
| **propose** | Propose comprehensive analysis | Analyze thoroughly, Propose solution, State assumptions | Well-reasoned proposal with trade-offs | Be clear about assumptions |
| **challenge** | Challenge and stress-test | Identify weaknesses, Question assumptions, Suggest alternatives | Critique with counter-arguments | Be adversarial but constructive |
| **defend** | Respond to challenges | Address challenges, Defend valid aspects, Propose refined solution | Refined proposal incorporating feedback | Be open to criticism, synthesize |
| **criticize** | Find flaws ruthlessly | Find logical flaws, Identify edge cases, Rate criticisms | Critique with severity: [CRITICAL]/[HIGH]/[MEDIUM]/[LOW] | Be ruthlessly critical |
```javascript
const PROMPTS = {
initial: { purpose: 'Initial analysis', tasks: ['Identify affected files', 'Analyze implementation approach', 'List specific changes'], expected: 'Root cause, files to modify, key changes, risks', rules: 'Focus on actionable insights' },
extend: { purpose: 'Build on previous analysis', tasks: ['Review previous findings', 'Extend analysis', 'Add new insights'], expected: 'Extended analysis building on previous', rules: 'Build incrementally, avoid repetition' },
synthesize: { purpose: 'Refine and synthesize', tasks: ['Review previous', 'Identify gaps', 'Add insights', 'Synthesize findings'], expected: 'Refined synthesis with new perspectives', rules: 'Build collaboratively, add value' },
propose: { purpose: 'Propose comprehensive analysis', tasks: ['Analyze thoroughly', 'Propose solution', 'State assumptions clearly'], expected: 'Well-reasoned proposal with trade-offs', rules: 'Be clear about assumptions' },
challenge: { purpose: 'Challenge and stress-test', tasks: ['Identify weaknesses', 'Question assumptions', 'Suggest alternatives', 'Highlight overlooked risks'], expected: 'Constructive critique with counter-arguments', rules: 'Be adversarial but constructive' },
defend: { purpose: 'Respond to challenges', tasks: ['Address each challenge', 'Defend valid aspects', 'Acknowledge valid criticisms', 'Propose refined solution'], expected: 'Refined proposal incorporating alternatives', rules: 'Be open to criticism, synthesize best ideas' },
criticize: { purpose: 'Stress-test and find weaknesses', tasks: ['Find logical flaws', 'Identify missed edge cases', 'Propose alternatives', 'Rate criticisms (High/Medium/Low)'], expected: 'Detailed critique with severity ratings', rules: 'Be ruthlessly critical, find every flaw' }
}
```
### Mode Implementations
```javascript
// Parallel: All CLIs run simultaneously
async function executeParallel(clis, task) {
return await Promise.all(clis.map(cli =>
execCLI(cli, buildPrompt({ ...PROMPTS.initial, taskDescription: task }), { background: true })
))
}
// Sequential: Each CLI builds on previous via --resume
async function executeSequential(clis, task) {
const results = []
let prevId = null
for (const cli of clis) {
const preset = prevId ? PROMPTS.extend : PROMPTS.initial
const result = await execCLI(cli, buildPrompt({ ...preset, taskDescription: task }), { resume: prevId })
results.push(result)
prevId = extractSessionId(result)
}
return results
}
// Collaborative: Multi-round synthesis
async function executeCollaborative(clis, task, rounds = 2) {
const results = []
let prevId = null
for (let r = 0; r < rounds; r++) {
for (const cli of clis) {
const preset = !prevId ? PROMPTS.initial : PROMPTS.synthesize
const result = await execCLI(cli, buildPrompt({ ...preset, taskDescription: task }), { resume: prevId })
results.push({ cli: cli.name, round: r, result })
prevId = extractSessionId(result)
}
}
return results
}
// Debate: Propose → Challenge → Defend
async function executeDebate(clis, task) {
const [cliA, cliB] = clis
const results = []
const propose = await execCLI(cliA, buildPrompt({ ...PROMPTS.propose, taskDescription: task }))
results.push({ phase: 'propose', cli: cliA.name, result: propose })
const challenge = await execCLI(cliB, buildPrompt({ ...PROMPTS.challenge, taskDescription: task }), { resume: extractSessionId(propose) })
results.push({ phase: 'challenge', cli: cliB.name, result: challenge })
const defend = await execCLI(cliA, buildPrompt({ ...PROMPTS.defend, taskDescription: task }), { resume: extractSessionId(challenge) })
results.push({ phase: 'defend', cli: cliA.name, result: defend })
return results
}
// Challenge: Analyze → Criticize
async function executeChallenge(clis, task) {
const [cliA, cliB] = clis
const results = []
const analyze = await execCLI(cliA, buildPrompt({ ...PROMPTS.initial, taskDescription: task }))
results.push({ phase: 'analyze', cli: cliA.name, result: analyze })
const criticize = await execCLI(cliB, buildPrompt({ ...PROMPTS.criticize, taskDescription: task }), { resume: extractSessionId(analyze) })
results.push({ phase: 'challenge', cli: cliB.name, result: criticize })
return results
}
```
### Mode Router & Result Aggregation
```javascript
async function executeAnalysis(mode, clis, taskDescription) {
switch (mode.name) {
case 'parallel': return await executeParallel(clis, taskDescription)
case 'sequential': return await executeSequential(clis, taskDescription)
case 'collaborative': return await executeCollaborative(clis, taskDescription)
case 'debate': return await executeDebate(clis, taskDescription)
case 'challenge': return await executeChallenge(clis, taskDescription)
}
}
function aggregateResults(mode, results) {
const base = { mode: mode.name, pattern: mode.pattern, tools_used: results.map(r => r.cli || 'unknown') }
switch (mode.name) {
case 'parallel':
return { ...base, findings: results.map(parseOutput), consensus: findCommonPoints(results), divergences: findDifferences(results) }
case 'sequential':
return { ...base, evolution: results.map((r, i) => ({ step: i + 1, analysis: parseOutput(r) })), finalAnalysis: parseOutput(results.at(-1)) }
case 'collaborative':
return { ...base, rounds: groupByRound(results), synthesis: extractSynthesis(results.at(-1)) }
case 'debate':
return { ...base, proposal: parseOutput(results.find(r => r.phase === 'propose')?.result),
challenges: parseOutput(results.find(r => r.phase === 'challenge')?.result),
resolution: parseOutput(results.find(r => r.phase === 'defend')?.result), confidence: calculateDebateConfidence(results) }
case 'challenge':
return { ...base, originalAnalysis: parseOutput(results.find(r => r.phase === 'analyze')?.result),
critiques: parseCritiques(results.find(r => r.phase === 'challenge')?.result), riskScore: calculateRiskScore(results) }
}
}
// If planPath exists: update Analysis Summary & Execution Plan sections
```
## Phase 4: User Decision
```javascript
function presentSummary(analysis) {
console.log(`## Analysis Result\n**Mode**: ${analysis.mode} (${analysis.pattern})\n**Tools**: ${analysis.tools_used.join(' → ')}`)
switch (analysis.mode) {
case 'parallel':
console.log(`### Consensus\n${analysis.consensus.map(c => `- ${c}`).join('\n')}\n### Divergences\n${analysis.divergences.map(d => `- ${d}`).join('\n')}`)
break
case 'sequential':
console.log(`### Evolution\n${analysis.evolution.map(e => `**Step ${e.step}**: ${e.analysis.summary}`).join('\n')}\n### Final\n${analysis.finalAnalysis.summary}`)
break
case 'collaborative':
console.log(`### Rounds\n${Object.entries(analysis.rounds).map(([r, a]) => `**Round ${r}**: ${a.map(x => x.cli).join(' + ')}`).join('\n')}\n### Synthesis\n${analysis.synthesis}`)
break
case 'debate':
console.log(`### Debate\n**Proposal**: ${analysis.proposal.summary}\n**Challenges**: ${analysis.challenges.points?.length || 0} points\n**Resolution**: ${analysis.resolution.summary}\n**Confidence**: ${analysis.confidence}%`)
break
case 'challenge':
console.log(`### Challenge\n**Original**: ${analysis.originalAnalysis.summary}\n**Critiques**: ${analysis.critiques.length} issues\n${analysis.critiques.map(c => `- [${c.severity}] ${c.description}`).join('\n')}\n**Risk Score**: ${analysis.riskScore}/100`)
break
}
}
AskUserQuestion({
questions: [{
question: "How to proceed?",
header: "Next Step",
options: [
{ label: "Execute directly", description: "Implement immediately" },
{ label: "Refine analysis", description: "Add constraints, re-analyze" },
{ label: "Change tools", description: "Different tool combination" },
{ label: "Cancel", description: "End workflow" }
],
multiSelect: false
}]
})
// If planPath exists: record decision to Decisions Made table
// Routing: Execute → Phase 5 | Refine → Phase 3 | Change → Phase 2 | Cancel → End
```
## Phase 5: Direct Execution
```javascript
// Simple tasks: No artifacts | Complex tasks: Update scratchpad doc
const executionAgents = agents.filter(a => a.canExecute)
const executionTool = selectedAgent.canExecute ? selectedAgent : selectedCLIs[0]
if (executionTool.type === 'agent') {
Task({
subagent_type: executionTool.name,
run_in_background: false,
description: `Execute: ${taskDescription.slice(0, 30)}`,
prompt: `## Task\n${taskDescription}\n\n## Analysis Results\n${JSON.stringify(aggregatedAnalysis, null, 2)}\n\n## Instructions\n1. Apply changes to identified files\n2. Follow recommended approach\n3. Handle identified risks\n4. Verify changes work correctly`
})
} else {
Bash({
command: `ccw cli -p "
PURPOSE: Implement solution: ${taskDescription}
TASK: ${extractedTasks.join(' • ')}
MODE: write
CONTEXT: @${affectedFiles.join(' @')}
EXPECTED: Working implementation with all changes applied
CONSTRAINTS: Follow existing patterns
" --tool ${executionTool.name} --mode write`,
run_in_background: false
})
}
// If planPath exists: update Status to completed/failed, append to Progress Log
```
## TodoWrite Structure
```javascript
TodoWrite({ todos: [
{ content: "Phase 1: Clarify requirements", status: "in_progress", activeForm: "Clarifying requirements" },
{ content: "Phase 1.5: Assess complexity", status: "pending", activeForm: "Assessing complexity" },
{ content: "Phase 2: Select tools", status: "pending", activeForm: "Selecting tools" },
{ content: "Phase 3: Multi-mode analysis", status: "pending", activeForm: "Running analysis" },
{ content: "Phase 4: User decision", status: "pending", activeForm: "Awaiting decision" },
{ content: "Phase 5: Direct execution", status: "pending", activeForm: "Executing" }
]})
```
## Iteration Patterns
| Pattern | Flow |
|---------|------|
| **Direct** | Phase 1 → 2 → 3 → 4(execute) → 5 |
| **Refinement** | Phase 3 → 4(refine) → 3 → 4 → 5 |
| **Tool Adjust** | Phase 2(adjust) → 3 → 4 → 5 |
## Error Handling
| Error | Resolution |
|-------|------------|
| CLI timeout | Retry with secondary model |
| No enabled tools | Ask user to enable tools in cli-tools.json |
| Task unclear | Default to first CLI + code-developer |
| Ambiguous task | Force clarification via AskUser |
| Execution fails | Present error, ask user for direction |
| Plan doc write fails | Continue without doc (degrade to zero-artifact mode) |
| Scratchpad dir missing | Auto-create `.workflow/.scratchpad/` |
## Comparison with multi-cli-plan
| Aspect | lite-lite-lite | multi-cli-plan |
|--------|----------------|----------------|
| **Artifacts** | Conditional (scratchpad doc for complex tasks) | Always (IMPL_PLAN.md, plan.json, synthesis.json) |
| **Session** | Stateless (--resume chaining) | Persistent session folder |
| **Tool Selection** | 3-step (CLI → Mode → Agent) | Config-driven fixed tools |
| **Analysis Modes** | 5 modes with --resume | Fixed synthesis rounds |
| **Complexity** | Auto-detected (simple/moderate/complex) | Assumed complex |
| **Best For** | Quick analysis, simple-to-moderate tasks | Complex multi-step implementations |
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
## Related Commands
```bash
/workflow:multi-cli-plan "complex task" # Full planning workflow
/workflow:lite-plan "task" # Single CLI planning
/workflow:lite-execute --in-memory # Direct execution
```

View File

@@ -1,7 +1,7 @@
---
name: lite-plan
description: Lightweight interactive planning workflow with in-memory planning, code exploration, and execution dispatch to lite-execute after user confirmation
argument-hint: "[-e|--explore] \"task description\"|file.md"
description: Lightweight interactive planning workflow with in-memory planning, code exploration, and execution execute to lite-execute after user confirmation
argument-hint: "[-y|--yes] [-e|--explore] \"task description\"|file.md"
allowed-tools: TodoWrite(*), Task(*), SlashCommand(*), AskUserQuestion(*)
---
@@ -17,7 +17,7 @@ Intelligent lightweight planning command with dynamic workflow adaptation based
- Interactive clarification after exploration to gather missing information
- Adaptive planning: Low complexity → Direct Claude; Medium/High → cli-lite-planning-agent
- Two-step confirmation: plan display → multi-dimensional input collection
- Execution dispatch with complete context handoff to lite-execute
- Execution execute with complete context handoff to lite-execute
## Usage
@@ -25,10 +25,30 @@ Intelligent lightweight planning command with dynamic workflow adaptation based
/workflow:lite-plan [FLAGS] <TASK_DESCRIPTION>
# Flags
-y, --yes Skip all confirmations (auto mode)
-e, --explore Force code exploration phase (overrides auto-detection)
# Arguments
<task-description> Task description or path to .md file (required)
# Examples
/workflow:lite-plan "实现JWT认证" # Interactive mode
/workflow:lite-plan --yes "实现JWT认证" # Auto mode (no confirmations)
/workflow:lite-plan -y -e "优化数据库查询性能" # Auto mode + force exploration
```
## Auto Mode Defaults
When `--yes` or `-y` flag is used:
- **Clarification Questions**: Skipped (no clarification phase)
- **Plan Confirmation**: Auto-selected "Allow"
- **Execution Method**: Auto-selected "Auto"
- **Code Review**: Auto-selected "Skip"
**Flag Parsing**:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
const forceExplore = $ARGUMENTS.includes('--explore') || $ARGUMENTS.includes('-e')
```
## Execution Process
@@ -62,7 +82,7 @@ Phase 4: Confirmation & Selection
├─ Execution: Agent / Codex / Auto
└─ Review: Gemini / Agent / Skip
Phase 5: Dispatch
Phase 5: Execute
├─ Build executionContext (plan + explorations + clarifications + selections)
└─ SlashCommand("/workflow:lite-execute --in-memory")
```
@@ -184,6 +204,8 @@ Execute **${angle}** exploration for task planning context. Analyze codebase fro
1. Run: ccw tool exec get_modules_by_depth '{}' (project structure)
2. Run: rg -l "{keyword_from_task}" --type ts (locate relevant files)
3. Execute: cat ~/.claude/workflows/cli-templates/schemas/explore-json-schema.json (get output schema reference)
4. Read: .workflow/project-tech.json (technology stack and architecture context)
5. Read: .workflow/project-guidelines.json (user-defined constraints and conventions)
## Exploration Strategy (${angle} focus)
@@ -321,8 +343,16 @@ explorations.forEach(exp => {
// - Produce dedupedClarifications with unique intents only
const dedupedClarifications = intelligentMerge(allClarifications)
// Multi-round clarification: batch questions (max 4 per round)
if (dedupedClarifications.length > 0) {
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
// Auto mode: Skip clarification phase
console.log(`[--yes] Skipping ${dedupedClarifications.length} clarification questions`)
console.log(`Proceeding to planning with exploration results...`)
// Continue to Phase 3
} else if (dedupedClarifications.length > 0) {
// Interactive mode: Multi-round clarification
const BATCH_SIZE = 4
const totalRounds = Math.ceil(dedupedClarifications.length / BATCH_SIZE)
@@ -416,6 +446,12 @@ Generate implementation plan and write plan.json.
## Output Schema Reference
Execute: cat ~/.claude/workflows/cli-templates/schemas/plan-json-schema.json (get schema reference before generating plan)
## Project Context (MANDATORY - Read Both Files)
1. Read: .workflow/project-tech.json (technology stack, architecture, key components)
2. Read: .workflow/project-guidelines.json (user-defined constraints and conventions)
**CRITICAL**: All generated tasks MUST comply with constraints in project-guidelines.json
## Task Description
${task_description}
@@ -489,45 +525,67 @@ ${plan.tasks.map((t, i) => `${i+1}. ${t.title} (${t.file})`).join('\n')}
**Step 4.2: Collect Confirmation**
```javascript
AskUserQuestion({
questions: [
{
question: `Confirm plan? (${plan.tasks.length} tasks, ${plan.complexity})`,
header: "Confirm",
multiSelect: true,
options: [
{ label: "Allow", description: "Proceed as-is" },
{ label: "Modify", description: "Adjust before execution" },
{ label: "Cancel", description: "Abort workflow" }
]
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: `Auto: ${plan.complexity === 'Low' ? 'Agent' : 'Codex'}` }
]
},
{
question: "Code review after execution?",
header: "Review",
multiSelect: false,
options: [
{ label: "Gemini Review", description: "Gemini CLI" },
{ label: "Agent Review", description: "@code-reviewer" },
{ label: "Skip", description: "No review" }
]
}
]
})
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
let userSelection
if (autoYes) {
// Auto mode: Use defaults
console.log(`[--yes] Auto-confirming plan:`)
console.log(` - Confirmation: Allow`)
console.log(` - Execution: Auto`)
console.log(` - Review: Skip`)
userSelection = {
confirmation: "Allow",
execution_method: "Auto",
code_review_tool: "Skip"
}
} else {
// Interactive mode: Ask user
// Note: Execution "Other" option allows specifying CLI tools from ~/.claude/cli-tools.json
userSelection = AskUserQuestion({
questions: [
{
question: `Confirm plan? (${plan.tasks.length} tasks, ${plan.complexity})`,
header: "Confirm",
multiSelect: false,
options: [
{ label: "Allow", description: "Proceed as-is" },
{ label: "Modify", description: "Adjust before execution" },
{ label: "Cancel", description: "Abort workflow" }
]
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: `Auto: ${plan.complexity === 'Low' ? 'Agent' : 'Codex'}` }
]
},
{
question: "Code review after execution?",
header: "Review",
multiSelect: false,
options: [
{ label: "Gemini Review", description: "Gemini CLI review" },
{ label: "Codex Review", description: "Git-aware review (prompt OR --uncommitted)" },
{ label: "Agent Review", description: "@code-reviewer agent" },
{ label: "Skip", description: "No review" }
]
}
]
})
}
```
---
### Phase 5: Dispatch to Execution
### Phase 5: Execute to Execution
**CRITICAL**: lite-plan NEVER executes code directly. ALL execution MUST go through lite-execute.
@@ -574,7 +632,7 @@ executionContext = {
}
```
**Step 5.2: Dispatch**
**Step 5.2: Execute**
```javascript
SlashCommand(command="/workflow:lite-execute --in-memory")

View File

@@ -0,0 +1,572 @@
---
name: workflow:multi-cli-plan
description: Multi-CLI collaborative planning workflow with ACE context gathering and iterative cross-verification. Uses cli-discuss-agent for Gemini+Codex+Claude analysis to converge on optimal execution plan.
argument-hint: "[-y|--yes] <task description> [--max-rounds=3] [--tools=gemini,codex] [--mode=parallel|serial]"
allowed-tools: TodoWrite(*), Task(*), AskUserQuestion(*), Read(*), Bash(*), Write(*), mcp__ace-tool__search_context(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-approve plan, use recommended solution and execution method (Agent, Skip review).
# Multi-CLI Collaborative Planning Command
## Quick Start
```bash
# Basic usage
/workflow:multi-cli-plan "Implement user authentication"
# With options
/workflow:multi-cli-plan "Add dark mode support" --max-rounds=3
/workflow:multi-cli-plan "Refactor payment module" --tools=gemini,codex,claude
/workflow:multi-cli-plan "Fix memory leak" --mode=serial
```
**Context Source**: ACE semantic search + Multi-CLI analysis
**Output Directory**: `.workflow/.multi-cli-plan/{session-id}/`
**Default Max Rounds**: 3 (convergence may complete earlier)
**CLI Tools**: @cli-discuss-agent (analysis), @cli-lite-planning-agent (plan generation)
**Execution**: Auto-hands off to `/workflow:lite-execute --in-memory` after plan approval
## What & Why
### Core Concept
Multi-CLI collaborative planning with **three-phase architecture**: ACE context gathering → Iterative multi-CLI discussion → Plan generation. Orchestrator delegates analysis to agents, only handles user decisions and session management.
**Process**:
- **Phase 1**: ACE semantic search gathers codebase context
- **Phase 2**: cli-discuss-agent orchestrates Gemini/Codex/Claude for cross-verified analysis
- **Phase 3-5**: User decision → Plan generation → Execution handoff
**vs Single-CLI Planning**:
- **Single**: One model perspective, potential blind spots
- **Multi-CLI**: Cross-verification catches inconsistencies, builds consensus on solutions
### Value Proposition
1. **Multi-Perspective Analysis**: Gemini + Codex + Claude analyze from different angles
2. **Cross-Verification**: Identify agreements/disagreements, build confidence
3. **User-Driven Decisions**: Every round ends with user decision point
4. **Iterative Convergence**: Progressive refinement until consensus reached
### Orchestrator Boundary (CRITICAL)
- **ONLY command** for multi-CLI collaborative planning
- Manages: Session state, user decisions, agent delegation, phase transitions
- Delegates: CLI execution to @cli-discuss-agent, plan generation to @cli-lite-planning-agent
### Execution Flow
```
Phase 1: Context Gathering
└─ ACE semantic search, extract keywords, build context package
Phase 2: Multi-CLI Discussion (Iterative, via @cli-discuss-agent)
├─ Round N: Agent executes Gemini + Codex + Claude
├─ Cross-verify findings, synthesize solutions
├─ Write synthesis.json to rounds/{N}/
└─ Loop until convergence or max rounds
Phase 3: Present Options
└─ Display solutions with trade-offs from agent output
Phase 4: User Decision
├─ Select solution approach
├─ Select execution method (Agent/Codex/Auto)
├─ Select code review tool (Skip/Gemini/Codex/Agent)
└─ Route:
├─ Approve → Phase 5
├─ Need More Analysis → Return to Phase 2
└─ Cancel → Save session
Phase 5: Plan Generation & Execution Handoff
├─ Generate plan.json (via @cli-lite-planning-agent)
├─ Build executionContext with user selections
└─ Execute to /workflow:lite-execute --in-memory
```
### Agent Roles
| Agent | Responsibility |
|-------|---------------|
| **Orchestrator** | Session management, ACE context, user decisions, phase transitions, executionContext assembly |
| **@cli-discuss-agent** | Multi-CLI execution (Gemini/Codex/Claude), cross-verification, solution synthesis, synthesis.json output |
| **@cli-lite-planning-agent** | Task decomposition, plan.json generation following schema |
## Core Responsibilities
### Phase 1: Context Gathering
**Session Initialization**:
```javascript
const sessionId = `MCP-${taskSlug}-${date}`
const sessionFolder = `.workflow/.multi-cli-plan/${sessionId}`
Bash(`mkdir -p ${sessionFolder}/rounds`)
```
**ACE Context Queries**:
```javascript
const aceQueries = [
`Project architecture related to ${keywords}`,
`Existing implementations of ${keywords[0]}`,
`Code patterns for ${keywords} features`,
`Integration points for ${keywords[0]}`
]
// Execute via mcp__ace-tool__search_context
```
**Context Package** (passed to agent):
- `relevant_files[]` - Files identified by ACE
- `detected_patterns[]` - Code patterns found
- `architecture_insights` - Structure understanding
### Phase 2: Agent Delegation
**Core Principle**: Orchestrator only delegates and reads output - NO direct CLI execution.
**Agent Invocation**:
```javascript
Task({
subagent_type: "cli-discuss-agent",
run_in_background: false,
description: `Discussion round ${currentRound}`,
prompt: `
## Input Context
- task_description: ${taskDescription}
- round_number: ${currentRound}
- session: { id: "${sessionId}", folder: "${sessionFolder}" }
- ace_context: ${JSON.stringify(contextPackageage)}
- previous_rounds: ${JSON.stringify(analysisResults)}
- user_feedback: ${userFeedback || 'None'}
- cli_config: { tools: ["gemini", "codex"], mode: "parallel", fallback_chain: ["gemini", "codex", "claude"] }
## Execution Process
1. Parse input context (handle JSON strings)
2. Check if ACE supplementary search needed
3. Build CLI prompts with context
4. Execute CLIs (parallel or serial per cli_config.mode)
5. Parse CLI outputs, handle failures with fallback
6. Perform cross-verification between CLI results
7. Synthesize solutions, calculate scores
8. Calculate convergence, generate clarification questions
9. Write synthesis.json
## Output
Write: ${sessionFolder}/rounds/${currentRound}/synthesis.json
## Completion Checklist
- [ ] All configured CLI tools executed (or fallback triggered)
- [ ] Cross-verification completed with agreements/disagreements
- [ ] 2-3 solutions generated with file:line references
- [ ] Convergence score calculated (0.0-1.0)
- [ ] synthesis.json written with all Primary Fields
`
})
```
**Read Agent Output**:
```javascript
const synthesis = JSON.parse(Read(`${sessionFolder}/rounds/${round}/synthesis.json`))
// Access top-level fields: solutions, convergence, cross_verification, clarification_questions
```
**Convergence Decision**:
```javascript
if (synthesis.convergence.recommendation === 'converged') {
// Proceed to Phase 3
} else if (synthesis.convergence.recommendation === 'user_input_needed') {
// Collect user feedback, return to Phase 2
} else {
// Continue to next round if new_insights && round < maxRounds
}
```
### Phase 3: Present Options
**Display from Agent Output** (no processing):
```javascript
console.log(`
## Solution Options
${synthesis.solutions.map((s, i) => `
**Option ${i+1}: ${s.name}**
Source: ${s.source_cli.join(' + ')}
Effort: ${s.effort} | Risk: ${s.risk}
Pros: ${s.pros.join(', ')}
Cons: ${s.cons.join(', ')}
Files: ${s.affected_files.slice(0,3).map(f => `${f.file}:${f.line}`).join(', ')}
`).join('\n')}
## Cross-Verification
Agreements: ${synthesis.cross_verification.agreements.length}
Disagreements: ${synthesis.cross_verification.disagreements.length}
`)
```
### Phase 4: User Decision
**Decision Options**:
```javascript
AskUserQuestion({
questions: [
{
question: "Which solution approach?",
header: "Solution",
multiSelect: false,
options: solutions.map((s, i) => ({
label: `Option ${i+1}: ${s.name}`,
description: `${s.effort} effort, ${s.risk} risk`
})).concat([
{ label: "Need More Analysis", description: "Return to Phase 2" }
])
},
{
question: "Execution method:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent", description: "@code-developer agent" },
{ label: "Codex", description: "codex CLI tool" },
{ label: "Auto", description: "Auto-select based on complexity" }
]
},
{
question: "Code review after execution?",
header: "Review",
multiSelect: false,
options: [
{ label: "Skip", description: "No review" },
{ label: "Gemini Review", description: "Gemini CLI tool" },
{ label: "Codex Review", description: "codex review --uncommitted" },
{ label: "Agent Review", description: "Current agent review" }
]
}
]
})
```
**Routing**:
- Approve + execution method → Phase 5
- Need More Analysis → Phase 2 with feedback
- Cancel → Save session for resumption
### Phase 5: Plan Generation & Execution Handoff
**Step 1: Build Context-Package** (Orchestrator responsibility):
```javascript
// Extract key information from user decision and synthesis
const contextPackage = {
// Core solution details
solution: {
name: selectedSolution.name,
source_cli: selectedSolution.source_cli,
feasibility: selectedSolution.feasibility,
effort: selectedSolution.effort,
risk: selectedSolution.risk,
summary: selectedSolution.summary
},
// Implementation plan (tasks, flow, milestones)
implementation_plan: selectedSolution.implementation_plan,
// Dependencies
dependencies: selectedSolution.dependencies || { internal: [], external: [] },
// Technical concerns
technical_concerns: selectedSolution.technical_concerns || [],
// Consensus from cross-verification
consensus: {
agreements: synthesis.cross_verification.agreements,
resolved_conflicts: synthesis.cross_verification.resolution
},
// User constraints (from Phase 4 feedback)
constraints: userConstraints || [],
// Task context
task_description: taskDescription,
session_id: sessionId
}
// Write context-package for traceability
Write(`${sessionFolder}/context-package.json`, JSON.stringify(contextPackage, null, 2))
```
**Context-Package Schema**:
| Field | Type | Description |
|-------|------|-------------|
| `solution` | object | User-selected solution from synthesis |
| `solution.name` | string | Solution identifier |
| `solution.feasibility` | number | Viability score (0-1) |
| `solution.summary` | string | Brief analysis summary |
| `implementation_plan` | object | Task breakdown with flow and dependencies |
| `implementation_plan.approach` | string | High-level technical strategy |
| `implementation_plan.tasks[]` | array | Discrete tasks with id, name, depends_on, files |
| `implementation_plan.execution_flow` | string | Task sequence (e.g., "T1 → T2 → T3") |
| `implementation_plan.milestones` | string[] | Key checkpoints |
| `dependencies` | object | Module and package dependencies |
| `technical_concerns` | string[] | Risks and blockers |
| `consensus` | object | Cross-verified agreements from multi-CLI |
| `constraints` | string[] | User-specified constraints from Phase 4 |
```json
{
"solution": {
"name": "Strategy Pattern Refactoring",
"source_cli": ["gemini", "codex"],
"feasibility": 0.88,
"effort": "medium",
"risk": "low",
"summary": "Extract payment gateway interface, implement strategy pattern for multi-gateway support"
},
"implementation_plan": {
"approach": "Define interface → Create concrete strategies → Implement factory → Migrate existing code",
"tasks": [
{"id": "T1", "name": "Define PaymentGateway interface", "depends_on": [], "files": [{"file": "src/types/payment.ts", "line": 1, "action": "create"}], "key_point": "Include all existing Stripe methods"},
{"id": "T2", "name": "Implement StripeGateway", "depends_on": ["T1"], "files": [{"file": "src/payment/stripe.ts", "line": 1, "action": "create"}], "key_point": "Wrap existing logic"},
{"id": "T3", "name": "Create GatewayFactory", "depends_on": ["T1"], "files": [{"file": "src/payment/factory.ts", "line": 1, "action": "create"}], "key_point": null},
{"id": "T4", "name": "Migrate processor to use factory", "depends_on": ["T2", "T3"], "files": [{"file": "src/payment/processor.ts", "line": 45, "action": "modify"}], "key_point": "Backward compatible"}
],
"execution_flow": "T1 → (T2 | T3) → T4",
"milestones": ["Interface defined", "Gateway implementations complete", "Migration done"]
},
"dependencies": {
"internal": ["@/lib/payment-gateway", "@/types/payment"],
"external": ["stripe@^14.0.0"]
},
"technical_concerns": ["Existing tests must pass", "No breaking API changes"],
"consensus": {
"agreements": ["Use strategy pattern", "Keep existing API"],
"resolved_conflicts": "Factory over DI for simpler integration"
},
"constraints": ["backward compatible", "no breaking changes to PaymentResult type"],
"task_description": "Refactor payment processing for multi-gateway support",
"session_id": "MCP-payment-refactor-2026-01-14"
}
```
**Step 2: Invoke Planning Agent**:
```javascript
Task({
subagent_type: "cli-lite-planning-agent",
run_in_background: false,
description: "Generate implementation plan",
prompt: `
## Schema Reference
Execute: cat ~/.claude/workflows/cli-templates/schemas/plan-json-schema.json
## Context-Package (from orchestrator)
${JSON.stringify(contextPackage, null, 2)}
## Execution Process
1. Read plan-json-schema.json for output structure
2. Read project-tech.json and project-guidelines.json
3. Parse context-package fields:
- solution: name, feasibility, summary
- implementation_plan: tasks[], execution_flow, milestones
- dependencies: internal[], external[]
- technical_concerns: risks/blockers
- consensus: agreements, resolved_conflicts
- constraints: user requirements
4. Use implementation_plan.tasks[] as task foundation
5. Preserve task dependencies (depends_on) and execution_flow
6. Expand tasks with detailed acceptance criteria
7. Generate plan.json following schema exactly
## Output
- ${sessionFolder}/plan.json
## Completion Checklist
- [ ] plan.json preserves task dependencies from implementation_plan
- [ ] Task execution order follows execution_flow
- [ ] Key_points reflected in task descriptions
- [ ] User constraints applied to implementation
- [ ] Acceptance criteria are testable
- [ ] Schema fields match plan-json-schema.json exactly
`
})
```
**Step 3: Build executionContext**:
```javascript
// After plan.json is generated by cli-lite-planning-agent
const plan = JSON.parse(Read(`${sessionFolder}/plan.json`))
// Build executionContext (same structure as lite-plan)
executionContext = {
planObject: plan,
explorationsContext: null, // Multi-CLI doesn't use exploration files
explorationAngles: [], // No exploration angles
explorationManifest: null, // No manifest
clarificationContext: null, // Store user feedback from Phase 2 if exists
executionMethod: userSelection.execution_method, // From Phase 4
codeReviewTool: userSelection.code_review_tool, // From Phase 4
originalUserInput: taskDescription,
// Optional: Task-level executor assignments
executorAssignments: null, // Could be enhanced in future
session: {
id: sessionId,
folder: sessionFolder,
artifacts: {
explorations: [], // No explorations in multi-CLI workflow
explorations_manifest: null,
plan: `${sessionFolder}/plan.json`,
synthesis_rounds: Array.from({length: currentRound}, (_, i) =>
`${sessionFolder}/rounds/${i+1}/synthesis.json`
),
context_package: `${sessionFolder}/context-package.json`
}
}
}
```
**Step 4: Hand off to Execution**:
```javascript
// Execute to lite-execute with in-memory context
SlashCommand("/workflow:lite-execute --in-memory")
```
## Output File Structure
```
.workflow/.multi-cli-plan/{MCP-task-slug-YYYY-MM-DD}/
├── session-state.json # Session tracking (orchestrator)
├── rounds/
│ ├── 1/synthesis.json # Round 1 analysis (cli-discuss-agent)
│ ├── 2/synthesis.json # Round 2 analysis (cli-discuss-agent)
│ └── .../
├── context-package.json # Extracted context for planning (orchestrator)
└── plan.json # Structured plan (cli-lite-planning-agent)
```
**File Producers**:
| File | Producer | Content |
|------|----------|---------|
| `session-state.json` | Orchestrator | Session metadata, rounds, decisions |
| `rounds/*/synthesis.json` | cli-discuss-agent | Solutions, convergence, cross-verification |
| `context-package.json` | Orchestrator | Extracted solution, dependencies, consensus for planning |
| `plan.json` | cli-lite-planning-agent | Structured tasks for lite-execute |
## synthesis.json Schema
```json
{
"round": 1,
"solutions": [{
"name": "Solution Name",
"source_cli": ["gemini", "codex"],
"feasibility": 0.85,
"effort": "low|medium|high",
"risk": "low|medium|high",
"summary": "Brief analysis summary",
"implementation_plan": {
"approach": "High-level technical approach",
"tasks": [
{"id": "T1", "name": "Task", "depends_on": [], "files": [], "key_point": "..."}
],
"execution_flow": "T1 → T2 → T3",
"milestones": ["Checkpoint 1", "Checkpoint 2"]
},
"dependencies": {"internal": [], "external": []},
"technical_concerns": ["Risk 1", "Blocker 2"]
}],
"convergence": {
"score": 0.85,
"new_insights": false,
"recommendation": "converged|continue|user_input_needed"
},
"cross_verification": {
"agreements": [],
"disagreements": [],
"resolution": "..."
},
"clarification_questions": []
}
```
**Key Planning Fields**:
| Field | Purpose |
|-------|---------|
| `feasibility` | Viability score (0-1) |
| `implementation_plan.tasks[]` | Discrete tasks with dependencies |
| `implementation_plan.execution_flow` | Task sequence visualization |
| `implementation_plan.milestones` | Key checkpoints |
| `technical_concerns` | Risks and blockers |
**Note**: Solutions ranked by internal scoring (array order = priority)
## TodoWrite Structure
**Initialization**:
```javascript
TodoWrite({ todos: [
{ content: "Phase 1: Context Gathering", status: "in_progress", activeForm: "Gathering context" },
{ content: "Phase 2: Multi-CLI Discussion", status: "pending", activeForm: "Running discussion" },
{ content: "Phase 3: Present Options", status: "pending", activeForm: "Presenting options" },
{ content: "Phase 4: User Decision", status: "pending", activeForm: "Awaiting decision" },
{ content: "Phase 5: Plan Generation", status: "pending", activeForm: "Generating plan" }
]})
```
**During Discussion Rounds**:
```javascript
TodoWrite({ todos: [
{ content: "Phase 1: Context Gathering", status: "completed", activeForm: "Gathering context" },
{ content: "Phase 2: Multi-CLI Discussion", status: "in_progress", activeForm: "Running discussion" },
{ content: " → Round 1: Initial analysis", status: "completed", activeForm: "Analyzing" },
{ content: " → Round 2: Deep verification", status: "in_progress", activeForm: "Verifying" },
{ content: "Phase 3: Present Options", status: "pending", activeForm: "Presenting options" },
// ...
]})
```
## Error Handling
| Error | Resolution |
|-------|------------|
| ACE search fails | Fall back to Glob/Grep for file discovery |
| Agent fails | Retry once, then present partial results |
| CLI timeout (in agent) | Agent uses fallback: gemini → codex → claude |
| No convergence | Present best options, flag uncertainty |
| synthesis.json parse error | Request agent retry |
| User cancels | Save session for later resumption |
## Configuration
| Flag | Default | Description |
|------|---------|-------------|
| `--max-rounds` | 3 | Maximum discussion rounds |
| `--tools` | gemini,codex | CLI tools for analysis |
| `--mode` | parallel | Execution mode: parallel or serial |
| `--auto-execute` | false | Auto-execute after approval |
## Best Practices
1. **Be Specific**: Detailed task descriptions improve ACE context quality
2. **Provide Feedback**: Use clarification rounds to refine requirements
3. **Trust Cross-Verification**: Multi-CLI consensus indicates high confidence
4. **Review Trade-offs**: Consider pros/cons before selecting solution
5. **Check synthesis.json**: Review agent output for detailed analysis
6. **Iterate When Needed**: Don't hesitate to request more analysis
## Related Commands
```bash
# Simpler single-round planning
/workflow:lite-plan "task description"
# Issue-driven discovery
/issue:discover-by-prompt "find issues"
# View session files
cat .workflow/.multi-cli-plan/{session-id}/plan.json
cat .workflow/.multi-cli-plan/{session-id}/rounds/1/synthesis.json
cat .workflow/.multi-cli-plan/{session-id}/context-package.json
# Direct execution (if you have plan.json)
/workflow:lite-execute plan.json
```

View File

@@ -0,0 +1,527 @@
---
name: plan-verify
description: Perform READ-ONLY verification analysis between IMPL_PLAN.md, task JSONs, and brainstorming artifacts. Generates structured report with quality gate recommendation. Does NOT modify any files.
argument-hint: "[optional: --session session-id]"
allowed-tools: Read(*), Write(*), Glob(*), Bash(*)
---
## User Input
```text
$ARGUMENTS
```
You **MUST** consider the user input before proceeding (if not empty).
## Goal
Generate a comprehensive verification report that identifies inconsistencies, duplications, ambiguities, and underspecified items between action planning artifacts (`IMPL_PLAN.md`, `task.json`) and brainstorming artifacts (`role analysis documents`). This command MUST run only after `/workflow:plan` has successfully produced complete `IMPL_PLAN.md` and task JSON files.
**Output**: A structured Markdown report saved to `.workflow/active/WFS-{session}/.process/PLAN_VERIFICATION.md` containing:
- Executive summary with quality gate recommendation
- Detailed findings by severity (CRITICAL/HIGH/MEDIUM/LOW)
- Requirements coverage analysis
- Dependency integrity check
- Synthesis alignment validation
- Actionable remediation recommendations
## Operating Constraints
**STRICTLY READ-ONLY FOR SOURCE ARTIFACTS**:
- **MUST NOT** modify `IMPL_PLAN.md`, any `task.json` files, or brainstorming artifacts
- **MUST NOT** create or delete task files
- **MUST ONLY** write the verification report to `.process/PLAN_VERIFICATION.md`
**Synthesis Authority**: The `role analysis documents` are **authoritative** for requirements and design decisions. Any conflicts between IMPL_PLAN/tasks and synthesis are automatically CRITICAL and require adjustment of the plan/tasks—not reinterpretation of requirements.
**Quality Gate Authority**: The verification report provides a binding recommendation (BLOCK_EXECUTION / PROCEED_WITH_FIXES / PROCEED_WITH_CAUTION / PROCEED) based on objective severity criteria. User MUST review critical/high issues before proceeding with implementation.
## Execution Steps
### 1. Initialize Analysis Context
```bash
# Detect active workflow session
IF --session parameter provided:
session_id = provided session
ELSE:
# Auto-detect active session
active_sessions = bash(find .workflow/active/ -name "WFS-*" -type d 2>/dev/null)
IF active_sessions is empty:
ERROR: "No active workflow session found. Use --session <session-id>"
EXIT
ELSE IF active_sessions has multiple entries:
# Use most recently modified session
session_id = bash(ls -td .workflow/active/WFS-*/ 2>/dev/null | head -1 | xargs basename)
ELSE:
session_id = basename(active_sessions[0])
# Derive absolute paths
session_dir = .workflow/active/WFS-{session}
brainstorm_dir = session_dir/.brainstorming
task_dir = session_dir/.task
process_dir = session_dir/.process
session_file = session_dir/workflow-session.json
# Create .process directory if not exists (report output location)
IF NOT EXISTS(process_dir):
bash(mkdir -p "{process_dir}")
# Validate required artifacts
# Note: "role analysis documents" refers to [role]/analysis.md files (e.g., product-manager/analysis.md)
SYNTHESIS_DIR = brainstorm_dir # Contains role analysis files: */analysis.md
IMPL_PLAN = session_dir/IMPL_PLAN.md
TASK_FILES = Glob(task_dir/*.json)
# Abort if missing - in order of dependency
SESSION_FILE_EXISTS = EXISTS(session_file)
IF NOT SESSION_FILE_EXISTS:
WARNING: "workflow-session.json not found. User intent alignment verification will be skipped."
# Continue execution - this is optional context, not blocking
SYNTHESIS_FILES = Glob(brainstorm_dir/*/analysis.md)
IF SYNTHESIS_FILES.count == 0:
ERROR: "No role analysis documents found in .brainstorming/*/analysis.md. Run /workflow:brainstorm:synthesis first"
EXIT
IF NOT EXISTS(IMPL_PLAN):
ERROR: "IMPL_PLAN.md not found. Run /workflow:plan first"
EXIT
IF TASK_FILES.count == 0:
ERROR: "No task JSON files found. Run /workflow:plan first"
EXIT
```
### 2. Load Artifacts (Progressive Disclosure)
Load only minimal necessary context from each artifact:
**From workflow-session.json** (OPTIONAL - Primary Reference for User Intent):
- **ONLY IF EXISTS**: Load user intent context
- Original user prompt/intent (project or description field)
- User's stated goals and objectives
- User's scope definition
- **IF MISSING**: Set user_intent_analysis = "SKIPPED: workflow-session.json not found"
**From role analysis documents** (AUTHORITATIVE SOURCE):
- Functional Requirements (IDs, descriptions, acceptance criteria)
- Non-Functional Requirements (IDs, targets)
- Business Requirements (IDs, success metrics)
- Key Architecture Decisions
- Risk factors and mitigation strategies
- Implementation Roadmap (high-level phases)
**From IMPL_PLAN.md**:
- Summary and objectives
- Context Analysis
- Implementation Strategy
- Task Breakdown Summary
- Success Criteria
- Brainstorming Artifacts References (if present)
**From task.json files**:
- Task IDs
- Titles and descriptions
- Status
- Dependencies (depends_on, blocks)
- Context (requirements, focus_paths, acceptance, artifacts)
- Flow control (pre_analysis, implementation_approach)
- Meta (complexity, priority)
### 3. Build Semantic Models
Create internal representations (do not include raw artifacts in output):
**Requirements inventory**:
- Each functional/non-functional/business requirement with stable ID
- Requirement text, acceptance criteria, priority
**Architecture decisions inventory**:
- ADRs from synthesis
- Technology choices
- Data model references
**Task coverage mapping**:
- Map each task to one or more requirements (by ID reference or keyword inference)
- Map each requirement to covering tasks
**Dependency graph**:
- Task-to-task dependencies (depends_on, blocks)
- Requirement-level dependencies (from synthesis)
### 4. Detection Passes (Token-Efficient Analysis)
**Token Budget Strategy**:
- **Total Limit**: 50 findings maximum (aggregate remainder in overflow summary)
- **Priority Allocation**: CRITICAL (unlimited) → HIGH (15) → MEDIUM (20) → LOW (15)
- **Early Exit**: If CRITICAL findings > 0 in User Intent/Requirements Coverage, skip LOW/MEDIUM priority checks
**Execution Order** (Process in sequence; skip if token budget exhausted):
1. **Tier 1 (CRITICAL Path)**: A, B, C - User intent, coverage, consistency (process fully)
2. **Tier 2 (HIGH Priority)**: D, E - Dependencies, synthesis alignment (limit 15 findings total)
3. **Tier 3 (MEDIUM Priority)**: F - Specification quality (limit 20 findings)
4. **Tier 4 (LOW Priority)**: G, H - Duplication, feasibility (limit 15 findings total)
---
#### A. User Intent Alignment (CRITICAL - Tier 1)
- **Goal Alignment**: IMPL_PLAN objectives match user's original intent
- **Scope Drift**: Plan covers user's stated scope without unauthorized expansion
- **Success Criteria Match**: Plan's success criteria reflect user's expectations
- **Intent Conflicts**: Tasks contradicting user's original objectives
#### B. Requirements Coverage Analysis
- **Orphaned Requirements**: Requirements in synthesis with zero associated tasks
- **Unmapped Tasks**: Tasks with no clear requirement linkage
- **NFR Coverage Gaps**: Non-functional requirements (performance, security, scalability) not reflected in tasks
#### C. Consistency Validation
- **Requirement Conflicts**: Tasks contradicting synthesis requirements
- **Architecture Drift**: IMPL_PLAN architecture not matching synthesis ADRs
- **Terminology Drift**: Same concept named differently across IMPL_PLAN and tasks
- **Data Model Inconsistency**: Tasks referencing entities/fields not in synthesis data model
#### D. Dependency Integrity
- **Circular Dependencies**: Task A depends on B, B depends on C, C depends on A
- **Missing Dependencies**: Task requires outputs from another task but no explicit dependency
- **Broken Dependencies**: Task depends on non-existent task ID
- **Logical Ordering Issues**: Implementation tasks before foundational setup without dependency note
#### E. Synthesis Alignment
- **Priority Conflicts**: High-priority synthesis requirements mapped to low-priority tasks
- **Success Criteria Mismatch**: IMPL_PLAN success criteria not covering synthesis acceptance criteria
- **Risk Mitigation Gaps**: Critical risks in synthesis without corresponding mitigation tasks
#### F. Task Specification Quality
- **Ambiguous Focus Paths**: Tasks with vague or missing focus_paths
- **Underspecified Acceptance**: Tasks without clear acceptance criteria
- **Missing Artifacts References**: Tasks not referencing relevant brainstorming artifacts in context.artifacts
- **Weak Flow Control**: Tasks without clear implementation_approach or pre_analysis steps
- **Missing Target Files**: Tasks without flow_control.target_files specification
#### G. Duplication Detection
- **Overlapping Task Scope**: Multiple tasks with nearly identical descriptions
- **Redundant Requirements Coverage**: Same requirement covered by multiple tasks without clear partitioning
#### H. Feasibility Assessment
- **Complexity Misalignment**: Task marked "simple" but requires multiple file modifications
- **Resource Conflicts**: Parallel tasks requiring same resources/files
- **Skill Gap Risks**: Tasks requiring skills not in team capability assessment (from synthesis)
### 5. Severity Assignment
Use this heuristic to prioritize findings:
- **CRITICAL**:
- Violates user's original intent (goal misalignment, scope drift)
- Violates synthesis authority (requirement conflict)
- Core requirement with zero coverage
- Circular dependencies
- Broken dependencies
- **HIGH**:
- NFR coverage gaps
- Priority conflicts
- Missing risk mitigation tasks
- Ambiguous acceptance criteria
- **MEDIUM**:
- Terminology drift
- Missing artifacts references
- Weak flow control
- Logical ordering issues
- **LOW**:
- Style/wording improvements
- Minor redundancy not affecting execution
### 6. Produce Compact Analysis Report
**Report Generation**: Generate report content and save to file.
Output a Markdown report with the following structure:
```markdown
# Plan Verification Report
**Session**: WFS-{session-id}
**Generated**: {timestamp}
**Artifacts Analyzed**: role analysis documents, IMPL_PLAN.md, {N} task files
**User Intent Analysis**: {user_intent_analysis or "SKIPPED: workflow-session.json not found"}
---
## Executive Summary
### Quality Gate Decision
| Metric | Value | Status |
|--------|-------|--------|
| Overall Risk Level | CRITICAL \| HIGH \| MEDIUM \| LOW | {status_emoji} |
| Critical Issues | {count} | 🔴 |
| High Issues | {count} | 🟠 |
| Medium Issues | {count} | 🟡 |
| Low Issues | {count} | 🟢 |
### Recommendation
**{RECOMMENDATION}**
**Decision Rationale**:
{brief explanation based on severity criteria}
**Quality Gate Criteria**:
- **BLOCK_EXECUTION**: Critical issues > 0 (must fix before proceeding)
- **PROCEED_WITH_FIXES**: Critical = 0, High > 0 (fix recommended before execution)
- **PROCEED_WITH_CAUTION**: Critical = 0, High = 0, Medium > 0 (proceed with awareness)
- **PROCEED**: Only Low issues or None (safe to execute)
---
## Findings Summary
| ID | Category | Severity | Location(s) | Summary | Recommendation |
|----|----------|----------|-------------|---------|----------------|
| C1 | Coverage | CRITICAL | synthesis:FR-03 | Requirement "User auth" has zero task coverage | Add authentication implementation task |
| H1 | Consistency | HIGH | IMPL-1.2 vs synthesis:ADR-02 | Task uses REST while synthesis specifies GraphQL | Align task with ADR-02 decision |
| M1 | Specification | MEDIUM | IMPL-2.1 | Missing context.artifacts reference | Add @synthesis reference |
| L1 | Duplication | LOW | IMPL-3.1, IMPL-3.2 | Similar scope | Consider merging |
(Generate stable IDs prefixed by severity initial: C/H/M/L + number)
---
## User Intent Alignment Analysis
{IF user_intent_analysis != "SKIPPED"}
### Goal Alignment
- **User Intent**: {user_original_intent}
- **IMPL_PLAN Objectives**: {plan_objectives}
- **Alignment Status**: {ALIGNED/MISALIGNED/PARTIAL}
- **Findings**: {specific alignment issues}
### Scope Verification
- **User Scope**: {user_defined_scope}
- **Plan Scope**: {plan_actual_scope}
- **Drift Detection**: {NONE/MINOR/MAJOR}
- **Findings**: {specific scope issues}
{ELSE}
> ⚠️ User intent alignment analysis was skipped because workflow-session.json was not found.
{END IF}
---
## Requirements Coverage Analysis
### Functional Requirements
| Requirement ID | Requirement Summary | Has Task? | Task IDs | Priority Match | Notes |
|----------------|---------------------|-----------|----------|----------------|-------|
| FR-01 | User authentication | Yes | IMPL-1.1, IMPL-1.2 | Match | Complete |
| FR-02 | Data export | Yes | IMPL-2.3 | Mismatch | High req → Med priority task |
| FR-03 | Profile management | No | - | - | **CRITICAL: Zero coverage** |
### Non-Functional Requirements
| Requirement ID | Requirement Summary | Has Task? | Task IDs | Notes |
|----------------|---------------------|-----------|----------|-------|
| NFR-01 | Response time <200ms | No | - | **HIGH: No performance tasks** |
| NFR-02 | Security compliance | Yes | IMPL-4.1 | Complete |
### Business Requirements
| Requirement ID | Requirement Summary | Has Task? | Task IDs | Notes |
|----------------|---------------------|-----------|----------|-------|
| BR-01 | Launch by Q2 | Yes | IMPL-1.* through IMPL-5.* | Timeline realistic |
### Coverage Metrics
| Requirement Type | Total | Covered | Coverage % |
|------------------|-------|---------|------------|
| Functional | {count} | {count} | {percent}% |
| Non-Functional | {count} | {count} | {percent}% |
| Business | {count} | {count} | {percent}% |
| **Overall** | **{total}** | **{covered}** | **{percent}%** |
---
## Dependency Integrity
### Dependency Graph Analysis
**Circular Dependencies**: {None or List}
**Broken Dependencies**:
- IMPL-2.3 depends on "IMPL-2.4" (non-existent)
**Missing Dependencies**:
- IMPL-5.1 (integration test) has no dependency on IMPL-1.* (implementation tasks)
**Logical Ordering Issues**:
{List or "None detected"}
---
## Synthesis Alignment Issues
| Issue Type | Synthesis Reference | IMPL_PLAN/Task | Impact | Recommendation |
|------------|---------------------|----------------|--------|----------------|
| Architecture Conflict | synthesis:ADR-01 (JWT auth) | IMPL_PLAN uses session cookies | HIGH | Update IMPL_PLAN to use JWT |
| Priority Mismatch | synthesis:FR-02 (High) | IMPL-2.3 (Medium) | MEDIUM | Elevate task priority |
| Missing Risk Mitigation | synthesis:Risk-03 (API rate limits) | No mitigation tasks | HIGH | Add rate limiting implementation task |
---
## Task Specification Quality
### Aggregate Statistics
| Quality Dimension | Tasks Affected | Percentage |
|-------------------|----------------|------------|
| Missing Artifacts References | {count} | {percent}% |
| Weak Flow Control | {count} | {percent}% |
| Missing Target Files | {count} | {percent}% |
| Ambiguous Focus Paths | {count} | {percent}% |
### Sample Issues
- **IMPL-1.2**: No context.artifacts reference to synthesis
- **IMPL-3.1**: Missing flow_control.target_files specification
- **IMPL-4.2**: Vague focus_paths ["src/"] - needs refinement
---
## Feasibility Concerns
| Concern | Tasks Affected | Issue | Recommendation |
|---------|----------------|-------|----------------|
| Skill Gap | IMPL-6.1, IMPL-6.2 | Requires Kubernetes expertise not in team | Add training task or external consultant |
| Resource Conflict | IMPL-3.1, IMPL-3.2 | Both modify src/auth/service.ts in parallel | Add dependency or serialize |
---
## Detailed Findings by Severity
### CRITICAL Issues ({count})
{Detailed breakdown of each critical issue with location, impact, and recommendation}
### HIGH Issues ({count})
{Detailed breakdown of each high issue with location, impact, and recommendation}
### MEDIUM Issues ({count})
{Detailed breakdown of each medium issue with location, impact, and recommendation}
### LOW Issues ({count})
{Detailed breakdown of each low issue with location, impact, and recommendation}
---
## Metrics Summary
| Metric | Value |
|--------|-------|
| Total Requirements | {count} ({functional} functional, {nonfunctional} non-functional, {business} business) |
| Total Tasks | {count} |
| Overall Coverage | {percent}% ({covered}/{total} requirements with ≥1 task) |
| Critical Issues | {count} |
| High Issues | {count} |
| Medium Issues | {count} |
| Low Issues | {count} |
| Total Findings | {total_findings} |
---
## Remediation Recommendations
### Priority Order
1. **CRITICAL** - Must fix before proceeding
2. **HIGH** - Fix before execution
3. **MEDIUM** - Fix during or after implementation
4. **LOW** - Optional improvements
### Next Steps
Based on the quality gate recommendation ({RECOMMENDATION}):
{IF BLOCK_EXECUTION}
**🛑 BLOCK EXECUTION**
You must resolve all CRITICAL issues before proceeding with implementation:
1. Review each critical issue in detail
2. Determine remediation approach (modify IMPL_PLAN.md, update task.json, or add new tasks)
3. Apply fixes systematically
4. Re-run verification to confirm resolution
{ELSE IF PROCEED_WITH_FIXES}
**⚠️ PROCEED WITH FIXES RECOMMENDED**
No critical issues detected, but HIGH issues exist. Recommended workflow:
1. Review high-priority issues
2. Apply fixes before execution for optimal results
3. Re-run verification (optional)
{ELSE IF PROCEED_WITH_CAUTION}
**✅ PROCEED WITH CAUTION**
Only MEDIUM issues detected. You may proceed with implementation:
- Address medium issues during or after implementation
- Maintain awareness of identified concerns
{ELSE}
**✅ PROCEED**
No significant issues detected. Safe to execute implementation workflow.
{END IF}
---
**Report End**
```
### 7. Save and Display Report
**Step 7.1: Save Report**:
```bash
report_path = ".workflow/active/WFS-{session}/.process/PLAN_VERIFICATION.md"
Write(report_path, full_report_content)
```
**Step 7.2: Display Summary to User**:
```bash
# Display executive summary in terminal
echo "=== Plan Verification Complete ==="
echo "Report saved to: {report_path}"
echo ""
echo "Quality Gate: {RECOMMENDATION}"
echo "Critical: {count} | High: {count} | Medium: {count} | Low: {count}"
echo ""
echo "Next: Review full report for detailed findings and recommendations"
```
**Step 7.3: Completion**:
- Report is saved to `.process/PLAN_VERIFICATION.md`
- User can review findings and decide on remediation approach
- No automatic modifications are made to source artifacts
- User can manually apply fixes or use separate remediation command (if available)

View File

@@ -1,15 +1,19 @@
---
name: plan
description: 5-phase planning workflow with action-planning-agent task generation, outputs IMPL_PLAN.md and task JSONs
argument-hint: "\"text description\"|file.md"
argument-hint: "[-y|--yes] \"text description\"|file.md"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
---
## Auto Mode
When `--yes` or `-y`: Auto-continue all phases (skip confirmations), use recommended conflict resolutions.
# Workflow Plan Command (/workflow:plan)
## Coordinator Role
**This command is a pure orchestrator**: Dispatch 5 slash commands in sequence (including a quality gate), parse their outputs, pass context between them, and ensure complete execution through **automatic continuation**.
**This command is a pure orchestrator**: Execute 5 slash commands in sequence (including a quality gate), parse their outputs, pass context between them, and ensure complete execution through **automatic continuation**.
**Execution Model - Auto-Continue Workflow with Quality Gate**:
@@ -17,14 +21,14 @@ This workflow runs **fully autonomously** once triggered. Phase 3 (conflict reso
1. **User triggers**: `/workflow:plan "task"`
2. **Phase 1 dispatches** → Session discovery → Auto-continues
3. **Phase 2 dispatches** → Context gathering → Auto-continues
4. **Phase 3 dispatches** (optional, if conflict_risk ≥ medium) → Conflict resolution → Auto-continues
5. **Phase 4 dispatches** → Task generation (task-generate-agent) → Reports final summary
2. **Phase 1 executes** → Session discovery → Auto-continues
3. **Phase 2 executes** → Context gathering → Auto-continues
4. **Phase 3 executes** (optional, if conflict_risk ≥ medium) → Conflict resolution → Auto-continues
5. **Phase 4 executes** → Task generation (task-generate-agent) → Reports final summary
**Task Attachment Model**:
- SlashCommand dispatch **expands workflow** by attaching sub-tasks to current TodoWrite
- When a sub-command is dispatched (e.g., `/workflow:tools:context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- SlashCommand execute **expands workflow** by attaching sub-tasks to current TodoWrite
- When a sub-command is executed (e.g., `/workflow:tools:context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- Orchestrator **executes these attached tasks** sequentially
- After completion, attached tasks are **collapsed** back to high-level phase summary
- This is **task expansion**, not external delegation
@@ -43,7 +47,7 @@ This workflow runs **fully autonomously** once triggered. Phase 3 (conflict reso
3. **Parse Every Output**: Extract required data from each command/agent output for next phase
4. **Auto-Continue via TodoList**: Check TodoList status to execute next pending phase automatically
5. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
6. **Task Attachment Model**: SlashCommand dispatch **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
6. **Task Attachment Model**: SlashCommand execute **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
7. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
## Execution Process
@@ -80,7 +84,7 @@ Return:
### Phase 1: Session Discovery
**Step 1.1: Dispatch** - Create or discover workflow session
**Step 1.1: Execute** - Create or discover workflow session
```javascript
SlashCommand(command="/workflow:session:start --auto \"[structured-task-description]\"")
@@ -117,7 +121,7 @@ CONTEXT: Existing user database schema, REST API endpoints
### Phase 2: Context Gathering
**Step 2.1: Dispatch** - Gather project context and analyze codebase
**Step 2.1: Execute** - Gather project context and analyze codebase
```javascript
SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"[structured-task-description]\"")
@@ -135,9 +139,9 @@ SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"[st
- Context package path extracted
- File exists and is valid JSON
<!-- TodoWrite: When context-gather dispatched, INSERT 3 context-gather tasks, mark first as in_progress -->
<!-- TodoWrite: When context-gather executed, INSERT 3 context-gather tasks, mark first as in_progress -->
**TodoWrite Update (Phase 2 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 2 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -149,7 +153,7 @@ SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"[st
]
```
**Note**: SlashCommand dispatch **attaches** context-gather's 3 tasks. Orchestrator **executes** these tasks sequentially.
**Note**: SlashCommand execute **attaches** context-gather's 3 tasks. Orchestrator **executes** these tasks sequentially.
<!-- TodoWrite: After Phase 2 tasks complete, REMOVE Phase 2.1-2.3, restore to orchestrator view -->
@@ -172,7 +176,7 @@ SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"[st
**Trigger**: Only execute when context-package.json indicates conflict_risk is "medium" or "high"
**Step 3.1: Dispatch** - Detect and resolve conflicts with CLI analysis
**Step 3.1: Execute** - Detect and resolve conflicts with CLI analysis
```javascript
SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId] --context [contextPath]")
@@ -196,7 +200,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
<!-- TodoWrite: If conflict_risk ≥ medium, INSERT 3 conflict-resolution tasks -->
**TodoWrite Update (Phase 3 SlashCommand dispatched - tasks attached, if conflict_risk ≥ medium)**:
**TodoWrite Update (Phase 3 SlashCommand executed - tasks attached, if conflict_risk ≥ medium)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -209,7 +213,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
]
```
**Note**: SlashCommand dispatch **attaches** conflict-resolution's 3 tasks. Orchestrator **executes** these tasks sequentially.
**Note**: SlashCommand execute **attaches** conflict-resolution's 3 tasks. Orchestrator **executes** these tasks sequentially.
<!-- TodoWrite: After Phase 3 tasks complete, REMOVE Phase 3.1-3.3, restore to orchestrator view -->
@@ -231,7 +235,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
- Evaluate current context window usage and memory state
- If memory usage is high (>120K tokens or approaching context limits):
**Step 3.2: Dispatch** - Optimize memory before proceeding
**Step 3.2: Execute** - Optimize memory before proceeding
```javascript
SlashCommand(command="/compact")
@@ -270,7 +274,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
- Task generation translates high-level role analyses into concrete, actionable work items
- **Intent priority**: Current user prompt > role analysis.md files > guidance-specification.md
**Step 4.1: Dispatch** - Generate implementation plan and task JSONs
**Step 4.1: Execute** - Generate implementation plan and task JSONs
```javascript
SlashCommand(command="/workflow:tools:task-generate-agent --session [sessionId]")
@@ -285,9 +289,9 @@ SlashCommand(command="/workflow:tools:task-generate-agent --session [sessionId]"
- `.workflow/active/[sessionId]/.task/IMPL-*.json` exists (at least one)
- `.workflow/active/[sessionId]/TODO_LIST.md` exists
<!-- TodoWrite: When task-generate-agent dispatched, ATTACH 1 agent task -->
<!-- TodoWrite: When task-generate-agent executed, ATTACH 1 agent task -->
**TodoWrite Update (Phase 4 SlashCommand dispatched - agent task attached)**:
**TodoWrite Update (Phase 4 SlashCommand executed - agent task attached)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -318,11 +322,11 @@ Tasks generated: [count]
Plan: .workflow/active/[sessionId]/IMPL_PLAN.md
Recommended Next Steps:
1. /workflow:action-plan-verify --session [sessionId] # Verify plan quality before execution
1. /workflow:plan-verify --session [sessionId] # Verify plan quality before execution
2. /workflow:status # Review task breakdown
3. /workflow:execute # Start implementation (after verification)
Quality Gate: Consider running /workflow:action-plan-verify to catch issues early
Quality Gate: Consider running /workflow:plan-verify to catch issues early
```
## TodoWrite Pattern
@@ -331,7 +335,7 @@ Quality Gate: Consider running /workflow:action-plan-verify to catch issues earl
### Key Principles
1. **Task Attachment** (when SlashCommand dispatched):
1. **Task Attachment** (when SlashCommand executed):
- Sub-command's internal tasks are **attached** to orchestrator's TodoWrite
- **Phase 2, 3**: Multiple sub-tasks attached (e.g., Phase 2.1, 2.2, 2.3)
- **Phase 4**: Single agent task attached (e.g., "Execute task-generate-agent")
@@ -350,7 +354,7 @@ Quality Gate: Consider running /workflow:action-plan-verify to catch issues earl
- No user intervention required between phases
- TodoWrite dynamically reflects current execution state
**Lifecycle Summary**: Initial pending tasks → Phase dispatched (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary for Phase 2/3, or marked completed for Phase 4) → Next phase begins → Repeat until all phases complete.
**Lifecycle Summary**: Initial pending tasks → Phase executed (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary for Phase 2/3, or marked completed for Phase 4) → Next phase begins → Repeat until all phases complete.
@@ -442,7 +446,7 @@ User triggers: /workflow:plan "Build authentication system"
Phase 1: Session Discovery
→ sessionId extracted
Phase 2: Context Gathering (SlashCommand dispatched)
Phase 2: Context Gathering (SlashCommand executed)
→ ATTACH 3 sub-tasks: ← ATTACHED
- → Analyze codebase structure
- → Identify integration points
@@ -453,7 +457,7 @@ Phase 2: Context Gathering (SlashCommand dispatched)
Conditional Branch: Check conflict_risk
├─ IF conflict_risk ≥ medium:
│ Phase 3: Conflict Resolution (SlashCommand dispatched)
│ Phase 3: Conflict Resolution (SlashCommand executed)
│ → ATTACH 3 sub-tasks: ← ATTACHED
│ - → Detect conflicts with CLI analysis
│ - → Present conflicts to user
@@ -463,7 +467,7 @@ Conditional Branch: Check conflict_risk
└─ ELSE: Skip Phase 3, proceed to Phase 4
Phase 4: Task Generation (SlashCommand dispatched)
Phase 4: Task Generation (SlashCommand executed)
→ Single agent task (no sub-tasks)
→ Agent autonomously completes internally:
(discovery → planning → output)
@@ -473,12 +477,12 @@ Return summary to user
```
**Key Points**:
- **← ATTACHED**: Tasks attached to TodoWrite when SlashCommand dispatched
- **← ATTACHED**: Tasks attached to TodoWrite when SlashCommand executed
- Phase 2, 3: Multiple sub-tasks
- Phase 4: Single agent task
- **← COLLAPSED**: Sub-tasks collapsed to summary after completion (Phase 2, 3 only)
- **Phase 4**: Single agent task, no collapse (just mark completed)
- **Conditional Branch**: Phase 3 only dispatches if conflict_risk ≥ medium
- **Conditional Branch**: Phase 3 only executes if conflict_risk ≥ medium
- **Continuous Flow**: No user intervention between phases
## Error Handling
@@ -546,6 +550,6 @@ CONSTRAINTS: [Limitations or boundaries]
- `/workflow:tools:task-generate-agent` - Phase 4: Generate task JSON files with agent-driven approach
**Follow-up Commands**:
- `/workflow:action-plan-verify` - Recommended: Verify plan quality and catch issues before execution
- `/workflow:plan-verify` - Recommended: Verify plan quality and catch issues before execution
- `/workflow:status` - Review task breakdown and current progress
- `/workflow:execute` - Begin implementation of generated tasks

View File

@@ -1,7 +1,7 @@
---
name: replan
description: Interactive workflow replanning with session-level artifact updates and boundary clarification through guided questioning
argument-hint: "[--session session-id] [task-id] \"requirements\"|file.md [--interactive]"
argument-hint: "[-y|--yes] [--session session-id] [task-id] \"requirements\"|file.md [--interactive]"
allowed-tools: Read(*), Write(*), Edit(*), TodoWrite(*), Glob(*), Bash(*)
---
@@ -117,10 +117,48 @@ const taskId = taskIdMatch?.[1]
---
### Auto Mode Support
When `--yes` or `-y` flag is used, the command skips interactive clarification and uses safe defaults:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
```
**Auto Mode Defaults**:
- **Modification Scope**: `tasks_only` (safest - only update task details)
- **Affected Modules**: All modules related to the task
- **Task Changes**: `update_only` (no structural changes)
- **Dependency Changes**: `no` (preserve existing dependencies)
- **User Confirmation**: Auto-confirm execution
**Note**: `--interactive` flag overrides `--yes` flag (forces interactive mode).
---
### Phase 2: Interactive Requirement Clarification
**Purpose**: Define modification scope through guided questioning
**Auto Mode Check**:
```javascript
if (autoYes && !interactive) {
// Use defaults and skip to Phase 3
console.log(`[--yes] Using safe defaults for replan:`)
console.log(` - Scope: tasks_only`)
console.log(` - Changes: update_only`)
console.log(` - Dependencies: preserve existing`)
userSelections = {
scope: 'tasks_only',
modules: 'all_affected',
task_changes: 'update_only',
dependency_changes: false
}
// Proceed to Phase 3
}
```
#### Session Mode Questions
**Q1: Modification Scope**
@@ -228,10 +266,29 @@ interface ImpactAnalysis {
**Step 3.3: User Confirmation**
```javascript
Options:
- 确认执行: 开始应用所有修改
- 调整计划: 重新回答问题调整范围
- 取消操作: 放弃本次重规划
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
// Auto mode: Auto-confirm execution
console.log(`[--yes] Auto-confirming replan execution`)
userConfirmation = '确认执行'
// Proceed to Phase 4
} else {
// Interactive mode: Ask user
AskUserQuestion({
questions: [{
question: "修改计划已生成,请确认操作:",
header: "Confirm",
options: [
{ label: "确认执行", description: "开始应用所有修改" },
{ label: "调整计划", description: "重新回答问题调整范围" },
{ label: "取消操作", description: "放弃本次重规划" }
],
multiSelect: false
}]
})
}
```
**Output**: Modification plan confirmed or adjusted

View File

@@ -585,6 +585,10 @@ TodoWrite({
- Mark completed immediately after each group finishes
- Update parent phase status when all child items complete
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
## Best Practices
1. **Trust AI Planning**: Planning agent's grouping and execution strategy are based on dependency analysis
@@ -601,6 +605,4 @@ Use `ccw view` to open the workflow dashboard in browser:
```bash
ccw view
```
```

View File

@@ -409,6 +409,8 @@ Task(
2. Get target files: Read resolved_files from review-state.json
3. Validate file access: bash(ls -la ${targetFiles.join(' ')})
4. Execute: cat ~/.claude/workflows/cli-templates/schemas/review-dimension-results-schema.json (get output schema reference)
5. Read: .workflow/project-tech.json (technology stack and architecture context)
6. Read: .workflow/project-guidelines.json (user-defined constraints and conventions to validate against)
## Review Context
- Review Type: module (independent)
@@ -511,6 +513,8 @@ Task(
3. Identify related code: bash(grep -r "import.*${basename(file)}" ${projectDir}/src --include="*.ts")
4. Read test files: bash(find ${projectDir}/tests -name "*${basename(file, '.ts')}*" -type f)
5. Execute: cat ~/.claude/workflows/cli-templates/schemas/review-deep-dive-results-schema.json (get output schema reference)
6. Read: .workflow/project-tech.json (technology stack and architecture context)
7. Read: .workflow/project-guidelines.json (user-defined constraints for remediation compliance)
## CLI Configuration
- Tool Priority: gemini → qwen → codex

View File

@@ -420,6 +420,8 @@ Task(
3. Get changed files: bash(cd ${workflowDir} && git log --since="${sessionCreatedAt}" --name-only --pretty=format: | sort -u)
4. Read review state: ${reviewStateJsonPath}
5. Execute: cat ~/.claude/workflows/cli-templates/schemas/review-dimension-results-schema.json (get output schema reference)
6. Read: .workflow/project-tech.json (technology stack and architecture context)
7. Read: .workflow/project-guidelines.json (user-defined constraints and conventions to validate against)
## Session Context
- Session ID: ${sessionId}
@@ -522,6 +524,8 @@ Task(
3. Identify related code: bash(grep -r "import.*${basename(file)}" ${workflowDir}/src --include="*.ts")
4. Read test files: bash(find ${workflowDir}/tests -name "*${basename(file, '.ts')}*" -type f)
5. Execute: cat ~/.claude/workflows/cli-templates/schemas/review-deep-dive-results-schema.json (get output schema reference)
6. Read: .workflow/project-tech.json (technology stack and architecture context)
7. Read: .workflow/project-guidelines.json (user-defined constraints for remediation compliance)
## CLI Configuration
- Tool Priority: gemini → qwen → codex

View File

@@ -1,7 +1,7 @@
---
name: review
description: Post-implementation review with specialized types (security/architecture/action-items/quality) using analysis agents and Gemini
argument-hint: "[--type=security|architecture|action-items|quality] [optional: session-id]"
argument-hint: "[--type=security|architecture|action-items|quality] [--archived] [optional: session-id]"
---
## Command Overview: /workflow:review
@@ -34,15 +34,17 @@ argument-hint: "[--type=security|architecture|action-items|quality] [optional: s
```
Input Parsing:
├─ Parse --type flag (default: quality)
├─ Parse --archived flag (search in archives)
└─ Parse session-id argument (optional)
Step 1: Session Resolution
└─ Decision:
├─ session-id provided → Use provided session
├─ session-id provided + --archived → Search .workflow/archives/
├─ session-id provided → Search .workflow/active/ first, then archives
└─ Not provided → Auto-detect from .workflow/active/
Step 2: Validation
├─ Check session directory exists
├─ Check session directory exists (active or archived)
└─ Check for completed implementation (.summaries/IMPL-*.md exists)
Step 3: Type Check
@@ -68,21 +70,29 @@ Step 5: Generate Report
#!/bin/bash
# Optional specialized review for completed implementation
# Step 1: Session ID resolution
# Step 1: Session ID resolution and location detection
if [ -n "$SESSION_ARG" ]; then
sessionId="$SESSION_ARG"
else
sessionId=$(find .workflow/active/ -name "WFS-*" -type d | head -1 | xargs basename)
fi
# Step 2: Validation
if [ ! -d ".workflow/active/${sessionId}" ]; then
echo "Session ${sessionId} not found"
# Step 2: Resolve session path (active or archived)
# Priority: --archived flag → active → archives
if [ -n "$ARCHIVED_FLAG" ]; then
sessionPath=".workflow/archives/${sessionId}"
elif [ -d ".workflow/active/${sessionId}" ]; then
sessionPath=".workflow/active/${sessionId}"
elif [ -d ".workflow/archives/${sessionId}" ]; then
sessionPath=".workflow/archives/${sessionId}"
echo "Note: Session found in archives, running review on archived session"
else
echo "Session ${sessionId} not found in active or archives"
exit 1
fi
# Check for completed tasks
if [ ! -d ".workflow/active/${sessionId}/.summaries" ] || [ -z "$(find .workflow/active/${sessionId}/.summaries/ -name "IMPL-*.md" -type f 2>/dev/null)" ]; then
if [ ! -d "${sessionPath}/.summaries" ] || [ -z "$(find ${sessionPath}/.summaries/ -name "IMPL-*.md" -type f 2>/dev/null)" ]; then
echo "No completed implementation found. Complete implementation first"
exit 1
fi
@@ -113,17 +123,17 @@ After bash validation, the model takes control to:
1. **Load Context**: Read completed task summaries and changed files
```bash
# Load implementation summaries (iterate through .summaries/ directory)
for summary in .workflow/active/${sessionId}/.summaries/*.md; do
for summary in ${sessionPath}/.summaries/*.md; do
cat "$summary"
done
# Load test results (if available)
for test_summary in .workflow/active/${sessionId}/.summaries/TEST-FIX-*.md 2>/dev/null; do
for test_summary in ${sessionPath}/.summaries/TEST-FIX-*.md 2>/dev/null; do
cat "$test_summary"
done
# Get changed files
git log --since="$(cat .workflow/active/${sessionId}/workflow-session.json | jq -r .created_at)" --name-only --pretty=format: | sort -u
git log --since="$(cat ${sessionPath}/workflow-session.json | jq -r .created_at)" --name-only --pretty=format: | sort -u
```
2. **Perform Specialized Review**: Based on `review_type`
@@ -139,10 +149,10 @@ After bash validation, the model takes control to:
ccw cli -p "
PURPOSE: Security audit of completed implementation
TASK: Review code for security vulnerabilities, insecure patterns, auth/authz issues
CONTEXT: @.summaries/IMPL-*.md,../.. @../../CLAUDE.md
CONTEXT: @.summaries/IMPL-*.md,../.. @../../project-tech.json @../../project-guidelines.json
EXPECTED: Security findings report with severity levels
RULES: Focus on OWASP Top 10, authentication, authorization, data validation, injection risks
" --tool gemini --mode write --cd .workflow/active/${sessionId}
" --tool gemini --mode write --cd ${sessionPath}
```
**Architecture Review** (`--type=architecture`):
@@ -151,10 +161,10 @@ After bash validation, the model takes control to:
ccw cli -p "
PURPOSE: Architecture compliance review
TASK: Evaluate adherence to architectural patterns, identify technical debt, review design decisions
CONTEXT: @.summaries/IMPL-*.md,../.. @../../CLAUDE.md
CONTEXT: @.summaries/IMPL-*.md,../.. @../../project-tech.json @../../project-guidelines.json
EXPECTED: Architecture assessment with recommendations
RULES: Check for patterns, separation of concerns, modularity, scalability
" --tool qwen --mode write --cd .workflow/active/${sessionId}
" --tool qwen --mode write --cd ${sessionPath}
```
**Quality Review** (`--type=quality`):
@@ -163,17 +173,17 @@ After bash validation, the model takes control to:
ccw cli -p "
PURPOSE: Code quality and best practices review
TASK: Assess code readability, maintainability, adherence to best practices
CONTEXT: @.summaries/IMPL-*.md,../.. @../../CLAUDE.md
CONTEXT: @.summaries/IMPL-*.md,../.. @../../project-tech.json @../../project-guidelines.json
EXPECTED: Quality assessment with improvement suggestions
RULES: Check for code smells, duplication, complexity, naming conventions
" --tool gemini --mode write --cd .workflow/active/${sessionId}
" --tool gemini --mode write --cd ${sessionPath}
```
**Action Items Review** (`--type=action-items`):
- Verify all requirements and acceptance criteria met:
```bash
# Load task requirements and acceptance criteria
for task_file in .workflow/active/${sessionId}/.task/*.json; do
for task_file in ${sessionPath}/.task/*.json; do
cat "$task_file" | jq -r '
"Task: " + .id + "\n" +
"Requirements: " + (.context.requirements | join(", ")) + "\n" +
@@ -185,7 +195,7 @@ After bash validation, the model takes control to:
ccw cli -p "
PURPOSE: Verify all requirements and acceptance criteria are met
TASK: Cross-check implementation summaries against original requirements
CONTEXT: @.task/IMPL-*.json,.summaries/IMPL-*.md,../.. @../../CLAUDE.md
CONTEXT: @.task/IMPL-*.json,.summaries/IMPL-*.md,../.. @../../project-tech.json @../../project-guidelines.json
EXPECTED:
- Requirements coverage matrix
- Acceptance criteria verification
@@ -196,7 +206,7 @@ After bash validation, the model takes control to:
- Verify all acceptance criteria are met
- Flag any incomplete or missing action items
- Assess deployment readiness
" --tool gemini --mode write --cd .workflow/active/${sessionId}
" --tool gemini --mode write --cd ${sessionPath}
```
@@ -234,7 +244,7 @@ After bash validation, the model takes control to:
4. **Output Files**:
```bash
# Save review report
Write(.workflow/active/${sessionId}/REVIEW-${review_type}.md)
Write(${sessionPath}/REVIEW-${review_type}.md)
# Update session metadata
# (optional) Update workflow-session.json with review status
@@ -261,6 +271,12 @@ After bash validation, the model takes control to:
# Architecture review for specific session
/workflow:review --type=architecture WFS-payment-integration
# Review an archived session (auto-detects if not in active)
/workflow:review --type=security WFS-old-feature
# Explicitly review archived session
/workflow:review --archived --type=quality WFS-completed-feature
# Documentation review
/workflow:review --type=docs
```
@@ -270,6 +286,7 @@ After bash validation, the model takes control to:
- **Simple Validation**: Check session exists and has completed tasks
- **No Complex Orchestration**: Direct analysis, no multi-phase pipeline
- **Specialized Reviews**: Different prompts and tools for different review types
- **Archived Session Support**: Review archived sessions with `--archived` flag or auto-detection
- **MCP Integration**: Fast code search for security and architecture patterns
- **CLI Tool Integration**: Gemini for analysis, Qwen for architecture
- **Structured Output**: Markdown reports with severity levels and action items
@@ -295,3 +312,11 @@ Optional Review (when needed):
- Regular development (tests are sufficient)
- Simple bug fixes (test-fix-agent handles it)
- Minor changes (update-memory-related is enough)
## Post-Review Action
After review completion, prompt user:
```
Review complete. Would you like to complete and archive this session?
→ Run /workflow:session:complete to archive with lessons learned
```

View File

@@ -1,8 +1,10 @@
---
name: complete
description: Mark active workflow session as complete, archive with lessons learned, update manifest, remove active flag
argument-hint: "[-y|--yes] [--detailed]"
examples:
- /workflow:session:complete
- /workflow:session:complete --yes
- /workflow:session:complete --detailed
---
@@ -107,13 +109,13 @@ rm -f .workflow/archives/$SESSION_ID/.archiving
Manifest: Updated with N total sessions
```
### Phase 4: Update project.json (Optional)
### Phase 4: Update project-tech.json (Optional)
**Skip if**: `.workflow/project.json` doesn't exist
**Skip if**: `.workflow/project-tech.json` doesn't exist
```bash
# Check
test -f .workflow/project.json || echo "SKIP"
test -f .workflow/project-tech.json || echo "SKIP"
```
**If exists**, add feature entry:
@@ -134,6 +136,53 @@ test -f .workflow/project.json || echo "SKIP"
✓ Feature added to project registry
```
### Phase 5: Ask About Solidify (Always)
After successful archival, prompt user to capture learnings:
```javascript
// Parse --yes flag
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
// Auto mode: Skip solidify
console.log(`[--yes] Auto-selecting: Skip solidify`)
console.log(`Session archived successfully.`)
// Done - no solidify
} else {
// Interactive mode: Ask user
AskUserQuestion({
questions: [{
question: "Would you like to solidify learnings from this session into project guidelines?",
header: "Solidify",
options: [
{ label: "Yes, solidify now", description: "Extract learnings and update project-guidelines.json" },
{ label: "Skip", description: "Archive complete, no learnings to capture" }
],
multiSelect: false
}]
})
// **If "Yes, solidify now"**: Execute `/workflow:session:solidify` with the archived session ID.
}
```
## Auto Mode Defaults
When `--yes` or `-y` flag is used:
- **Solidify Learnings**: Auto-selected "Skip" (archive only, no solidify)
**Flag Parsing**:
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
```
**Output**:
```
Session archived successfully.
→ Run /workflow:session:solidify to capture learnings (recommended)
```
## Error Recovery
| Phase | Symptom | Recovery |
@@ -149,5 +198,6 @@ test -f .workflow/project.json || echo "SKIP"
Phase 1: find session → create .archiving marker
Phase 2: read key files → build manifest entry (no writes)
Phase 3: mkdir → mv → update manifest.json → rm marker
Phase 4: update project.json features array (optional)
Phase 4: update project-tech.json features array (optional)
Phase 5: ask user → solidify learnings (optional)
```

View File

@@ -0,0 +1,303 @@
---
name: solidify
description: Crystallize session learnings and user-defined constraints into permanent project guidelines
argument-hint: "[-y|--yes] [--type <convention|constraint|learning>] [--category <category>] \"rule or insight\""
examples:
- /workflow:session:solidify "Use functional components for all React code" --type convention
- /workflow:session:solidify -y "No direct DB access from controllers" --type constraint --category architecture
- /workflow:session:solidify "Cache invalidation requires event sourcing" --type learning --category architecture
- /workflow:session:solidify --interactive
---
## Auto Mode
When `--yes` or `-y`: Auto-categorize and add guideline without confirmation.
# Session Solidify Command (/workflow:session:solidify)
## Overview
Crystallizes ephemeral session context (insights, decisions, constraints) into permanent project guidelines stored in `.workflow/project-guidelines.json`. This ensures valuable learnings persist across sessions and inform future planning.
## Use Cases
1. **During Session**: Capture important decisions as they're made
2. **After Session**: Reflect on lessons learned before archiving
3. **Proactive**: Add team conventions or architectural rules
## Parameters
| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `rule` | string | ✅ (unless --interactive) | The rule, convention, or insight to solidify |
| `--type` | enum | ❌ | Type: `convention`, `constraint`, `learning` (default: auto-detect) |
| `--category` | string | ❌ | Category for organization (see categories below) |
| `--interactive` | flag | ❌ | Launch guided wizard for adding rules |
### Type Categories
**convention** → Coding style preferences (goes to `conventions` section)
- Subcategories: `coding_style`, `naming_patterns`, `file_structure`, `documentation`
**constraint** → Hard rules that must not be violated (goes to `constraints` section)
- Subcategories: `architecture`, `tech_stack`, `performance`, `security`
**learning** → Session-specific insights (goes to `learnings` array)
- Subcategories: `architecture`, `performance`, `security`, `testing`, `process`, `other`
## Execution Process
```
Input Parsing:
├─ Parse: rule text (required unless --interactive)
├─ Parse: --type (convention|constraint|learning)
├─ Parse: --category (subcategory)
└─ Parse: --interactive (flag)
Step 1: Ensure Guidelines File Exists
└─ If not exists → Create with empty structure
Step 2: Auto-detect Type (if not specified)
└─ Analyze rule text for keywords
Step 3: Validate and Format Entry
└─ Build entry object based on type
Step 4: Update Guidelines File
└─ Add entry to appropriate section
Step 5: Display Confirmation
└─ Show what was added and where
```
## Implementation
### Step 1: Ensure Guidelines File Exists
```bash
bash(test -f .workflow/project-guidelines.json && echo "EXISTS" || echo "NOT_FOUND")
```
**If NOT_FOUND**, create scaffold:
```javascript
const scaffold = {
conventions: {
coding_style: [],
naming_patterns: [],
file_structure: [],
documentation: []
},
constraints: {
architecture: [],
tech_stack: [],
performance: [],
security: []
},
quality_rules: [],
learnings: [],
_metadata: {
created_at: new Date().toISOString(),
version: "1.0.0"
}
};
Write('.workflow/project-guidelines.json', JSON.stringify(scaffold, null, 2));
```
### Step 2: Auto-detect Type (if not specified)
```javascript
function detectType(ruleText) {
const text = ruleText.toLowerCase();
// Constraint indicators
if (/\b(no|never|must not|forbidden|prohibited|always must)\b/.test(text)) {
return 'constraint';
}
// Learning indicators
if (/\b(learned|discovered|realized|found that|turns out)\b/.test(text)) {
return 'learning';
}
// Default to convention
return 'convention';
}
function detectCategory(ruleText, type) {
const text = ruleText.toLowerCase();
if (type === 'constraint' || type === 'learning') {
if (/\b(architecture|layer|module|dependency|circular)\b/.test(text)) return 'architecture';
if (/\b(security|auth|permission|sanitize|xss|sql)\b/.test(text)) return 'security';
if (/\b(performance|cache|lazy|async|sync|slow)\b/.test(text)) return 'performance';
if (/\b(test|coverage|mock|stub)\b/.test(text)) return 'testing';
}
if (type === 'convention') {
if (/\b(name|naming|prefix|suffix|camel|pascal)\b/.test(text)) return 'naming_patterns';
if (/\b(file|folder|directory|structure|organize)\b/.test(text)) return 'file_structure';
if (/\b(doc|comment|jsdoc|readme)\b/.test(text)) return 'documentation';
return 'coding_style';
}
return type === 'constraint' ? 'tech_stack' : 'other';
}
```
### Step 3: Build Entry
```javascript
function buildEntry(rule, type, category, sessionId) {
if (type === 'learning') {
return {
date: new Date().toISOString().split('T')[0],
session_id: sessionId || null,
insight: rule,
category: category,
context: null
};
}
// For conventions and constraints, just return the rule string
return rule;
}
```
### Step 4: Update Guidelines File
```javascript
const guidelines = JSON.parse(Read('.workflow/project-guidelines.json'));
if (type === 'convention') {
if (!guidelines.conventions[category]) {
guidelines.conventions[category] = [];
}
if (!guidelines.conventions[category].includes(rule)) {
guidelines.conventions[category].push(rule);
}
} else if (type === 'constraint') {
if (!guidelines.constraints[category]) {
guidelines.constraints[category] = [];
}
if (!guidelines.constraints[category].includes(rule)) {
guidelines.constraints[category].push(rule);
}
} else if (type === 'learning') {
guidelines.learnings.push(buildEntry(rule, type, category, sessionId));
}
guidelines._metadata.updated_at = new Date().toISOString();
guidelines._metadata.last_solidified_by = sessionId;
Write('.workflow/project-guidelines.json', JSON.stringify(guidelines, null, 2));
```
### Step 5: Display Confirmation
```
✓ Guideline solidified
Type: ${type}
Category: ${category}
Rule: "${rule}"
Location: .workflow/project-guidelines.json → ${type}s.${category}
Total ${type}s in ${category}: ${count}
```
## Interactive Mode
When `--interactive` flag is provided:
```javascript
AskUserQuestion({
questions: [
{
question: "What type of guideline are you adding?",
header: "Type",
multiSelect: false,
options: [
{ label: "Convention", description: "Coding style preference (e.g., use functional components)" },
{ label: "Constraint", description: "Hard rule that must not be violated (e.g., no direct DB access)" },
{ label: "Learning", description: "Insight from this session (e.g., cache invalidation needs events)" }
]
}
]
});
// Follow-up based on type selection...
```
## Examples
### Add a Convention
```bash
/workflow:session:solidify "Use async/await instead of callbacks" --type convention --category coding_style
```
Result in `project-guidelines.json`:
```json
{
"conventions": {
"coding_style": ["Use async/await instead of callbacks"]
}
}
```
### Add an Architectural Constraint
```bash
/workflow:session:solidify "No direct DB access from controllers" --type constraint --category architecture
```
Result:
```json
{
"constraints": {
"architecture": ["No direct DB access from controllers"]
}
}
```
### Capture a Session Learning
```bash
/workflow:session:solidify "Cache invalidation requires event sourcing for consistency" --type learning
```
Result:
```json
{
"learnings": [
{
"date": "2024-12-28",
"session_id": "WFS-auth-feature",
"insight": "Cache invalidation requires event sourcing for consistency",
"category": "architecture"
}
]
}
```
## Integration with Planning
The `project-guidelines.json` is consumed by:
1. **`/workflow:tools:context-gather`**: Loads guidelines into context-package.json
2. **`/workflow:plan`**: Passes guidelines to task generation agent
3. **`task-generate-agent`**: Includes guidelines as "CRITICAL CONSTRAINTS" in system prompt
This ensures all future planning respects solidified rules without users needing to re-state them.
## Error Handling
- **Duplicate Rule**: Warn and skip if exact rule already exists
- **Invalid Category**: Suggest valid categories for the type
- **File Corruption**: Backup existing file before modification
## Related Commands
- `/workflow:session:start` - Start a session (may prompt for solidify at end)
- `/workflow:session:complete` - Complete session (prompts for learnings to solidify)
- `/workflow:init` - Creates project-guidelines.json scaffold if missing

View File

@@ -16,7 +16,7 @@ examples:
Manages workflow sessions with three operation modes: discovery (manual), auto (intelligent), and force-new.
**Dual Responsibility**:
1. **Project-level initialization** (first-time only): Creates `.workflow/project.json` for feature registry
1. **Project-level initialization** (first-time only): Creates `.workflow/project-tech.json` for feature registry
2. **Session-level initialization** (always): Creates session directory structure
## Session Types
@@ -38,26 +38,29 @@ ERROR: Invalid session type. Valid types: workflow, review, tdd, test, docs
## Step 0: Initialize Project State (First-time Only)
**Executed before all modes** - Ensures project-level state file exists by calling `/workflow:init`.
**Executed before all modes** - Ensures project-level state files exist by calling `/workflow:init`.
### Check and Initialize
```bash
# Check if project state exists
bash(test -f .workflow/project.json && echo "EXISTS" || echo "NOT_FOUND")
# Check if project state exists (both files required)
bash(test -f .workflow/project-tech.json && echo "TECH_EXISTS" || echo "TECH_NOT_FOUND")
bash(test -f .workflow/project-guidelines.json && echo "GUIDELINES_EXISTS" || echo "GUIDELINES_NOT_FOUND")
```
**If NOT_FOUND**, delegate to `/workflow:init`:
**If either NOT_FOUND**, delegate to `/workflow:init`:
```javascript
// Call workflow:init for intelligent project analysis
SlashCommand({command: "/workflow:init"});
// Wait for init completion
// project.json will be created with comprehensive project overview
// project-tech.json and project-guidelines.json will be created
```
**Output**:
- If EXISTS: `PROJECT_STATE: initialized`
- If NOT_FOUND: Calls `/workflow:init` → creates `.workflow/project.json` with full project analysis
- If BOTH_EXIST: `PROJECT_STATE: initialized`
- If NOT_FOUND: Calls `/workflow:init` → creates:
- `.workflow/project-tech.json` with full technical analysis
- `.workflow/project-guidelines.json` with empty scaffold
**Note**: `/workflow:init` uses cli-explore-agent to build comprehensive project understanding (technology stack, architecture, key components). This step runs once per project. Subsequent executions skip initialization.

View File

@@ -9,39 +9,77 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
## Coordinator Role
**This command is a pure orchestrator**: Dispatches 6 slash commands in sequence, parse outputs, pass context, and ensure complete TDD workflow creation with Red-Green-Refactor task generation.
**This command is a pure orchestrator**: Executes 6 slash commands in sequence, parse outputs, pass context, and ensure complete TDD workflow creation with Red-Green-Refactor task generation.
**CLI Tool Selection**: CLI tool usage is determined semantically from user's task description. Include "use Codex/Gemini/Qwen" in your request for CLI execution.
**Task Attachment Model**:
- SlashCommand dispatch **expands workflow** by attaching sub-tasks to current TodoWrite
- When dispatching a sub-command (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- SlashCommand execute **expands workflow** by attaching sub-tasks to current TodoWrite
- When executing a sub-command (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- Orchestrator **executes these attached tasks** sequentially
- After completion, attached tasks are **collapsed** back to high-level phase summary
- This is **task expansion**, not external delegation
**Auto-Continue Mechanism**:
- TodoList tracks current phase status and dynamically manages task attachment/collapse
- When each phase finishes executing, automatically dispatch next pending phase
- When each phase finishes executing, automatically execute next pending phase
- All phases run autonomously without user interaction
- **⚠️ CONTINUOUS EXECUTION** - Do not stop until all phases complete
## Core Rules
1. **Start Immediately**: First action is TodoWrite initialization, second action is dispatch Phase 1
1. **Start Immediately**: First action is TodoWrite initialization, second action is execute Phase 1
2. **No Preliminary Analysis**: Do not read files before Phase 1
3. **Parse Every Output**: Extract required data for next phase
4. **Auto-Continue via TodoList**: Check TodoList status to dispatch next pending phase automatically
4. **Auto-Continue via TodoList**: Check TodoList status to execute next pending phase automatically
5. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
6. **TDD Context**: All descriptions include "TDD:" prefix
7. **Task Attachment Model**: SlashCommand dispatch **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
8. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and dispatch next phase
7. **Task Attachment Model**: SlashCommand execute **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
8. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
## TDD Compliance Requirements
### The Iron Law
```
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
```
**Enforcement Method**:
- Phase 5: `implementation_approach` 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
| Checkpoint | Validation Phase | Evidence Required |
|------------|------------------|-------------------|
| Test-first structure | Phase 5 | `implementation_approach` 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"` |
### Core TDD Principles (from ref skills)
**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
## 6-Phase Execution (with Conflict Resolution)
### Phase 1: Session Discovery
**Step 1.1: Dispatch** - Session discovery and initialization
**Step 1.1: Execute** - Session discovery and initialization
```javascript
SlashCommand(command="/workflow:session:start --type tdd --auto \"TDD: [structured-description]\"")
@@ -66,7 +104,7 @@ TEST_FOCUS: [Test scenarios]
### Phase 2: Context Gathering
**Step 2.1: Dispatch** - Context gathering and analysis
**Step 2.1: Execute** - Context gathering and analysis
```javascript
SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"TDD: [structured-description]\"")
@@ -92,7 +130,7 @@ SlashCommand(command="/workflow:tools:context-gather --session [sessionId] \"TDD
### Phase 3: Test Coverage Analysis
**Step 3.1: Dispatch** - Test coverage analysis and framework detection
**Step 3.1: Execute** - Test coverage analysis and framework detection
```javascript
SlashCommand(command="/workflow:tools:test-context-gather --session [sessionId]")
@@ -108,9 +146,9 @@ SlashCommand(command="/workflow:tools:test-context-gather --session [sessionId]"
<!-- TodoWrite: When test-context-gather dispatched, INSERT 3 test-context-gather tasks -->
<!-- TodoWrite: When test-context-gather executed, INSERT 3 test-context-gather tasks -->
**TodoWrite Update (Phase 3 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 3 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -124,7 +162,7 @@ SlashCommand(command="/workflow:tools:test-context-gather --session [sessionId]"
]
```
**Note**: SlashCommand dispatch **attaches** test-context-gather's 3 tasks. Orchestrator **executes** these tasks.
**Note**: SlashCommand execute **attaches** test-context-gather's 3 tasks. Orchestrator **executes** these tasks.
**Next Action**: Tasks attached → **Execute Phase 3.1-3.3** sequentially
@@ -151,7 +189,7 @@ SlashCommand(command="/workflow:tools:test-context-gather --session [sessionId]"
**Trigger**: Only execute when context-package.json indicates conflict_risk is "medium" or "high"
**Step 4.1: Dispatch** - Conflict detection and resolution
**Step 4.1: Execute** - Conflict detection and resolution
```javascript
SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId] --context [contextPath]")
@@ -173,9 +211,9 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
- If conflict_risk is "none" or "low", skip directly to Phase 5
- Display: "No significant conflicts detected, proceeding to TDD task generation"
<!-- TodoWrite: If conflict_risk ≥ medium, INSERT 3 conflict-resolution tasks when dispatched -->
<!-- TodoWrite: If conflict_risk ≥ medium, INSERT 3 conflict-resolution tasks when executed -->
**TodoWrite Update (Phase 4 SlashCommand dispatched - tasks attached, if conflict_risk ≥ medium)**:
**TodoWrite Update (Phase 4 SlashCommand executed - tasks attached, if conflict_risk ≥ medium)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -183,14 +221,14 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
{"content": "Phase 3: Test Coverage Analysis", "status": "completed", "activeForm": "Executing test coverage analysis"},
{"content": "Phase 4: Conflict Resolution", "status": "in_progress", "activeForm": "Executing conflict resolution"},
{"content": " → Detect conflicts with CLI analysis", "status": "in_progress", "activeForm": "Detecting conflicts"},
{"content": " → Present conflicts to user", "status": "pending", "activeForm": "Presenting conflicts"},
{"content": " → Log and analyze detected conflicts", "status": "pending", "activeForm": "Analyzing conflicts"},
{"content": " → Apply resolution strategies", "status": "pending", "activeForm": "Applying resolution strategies"},
{"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**: SlashCommand dispatch **attaches** conflict-resolution's 3 tasks. Orchestrator **executes** these tasks.
**Note**: SlashCommand execute **attaches** conflict-resolution's 3 tasks. Orchestrator **executes** these tasks.
**Next Action**: Tasks attached → **Execute Phase 4.1-4.3** sequentially
@@ -216,7 +254,7 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
- Evaluate current context window usage and memory state
- If memory usage is high (>110K tokens or approaching context limits):
**Step 4.5: Dispatch** - Memory compaction
**Step 4.5: Execute** - Memory compaction
```javascript
SlashCommand(command="/compact")
@@ -230,15 +268,19 @@ SlashCommand(command="/workflow:tools:conflict-resolution --session [sessionId]
### Phase 5: TDD Task Generation
**Step 5.1: Dispatch** - TDD task generation via action-planning-agent
**Step 5.1: Execute** - TDD task generation via action-planning-agent with Phase 0 user configuration
```javascript
SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
```
**Note**: CLI tool usage is determined semantically from user's task description.
**Note**: Phase 0 now includes:
- Supplementary materials collection (file paths or inline content)
- Execution method preference (Agent/Hybrid/CLI)
- CLI tool preference (Codex/Gemini/Qwen/Auto)
- These preferences are passed to agent for task generation
**Parse**: Extract feature count, task count (not chain count - tasks now contain internal TDD cycles)
**Parse**: Extract feature count, task count (not chain count - tasks now contain internal TDD cycles), CLI execution IDs assigned
**Validate**:
- IMPL_PLAN.md exists (unified plan with TDD Implementation Tasks section)
@@ -246,14 +288,30 @@ SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
- TODO_LIST.md exists with internal TDD phase indicators
- Each IMPL task includes:
- `meta.tdd_workflow: true`
- `flow_control.implementation_approach` with 3 steps (red/green/refactor)
- `meta.cli_execution_id: {session_id}-{task_id}`
- `meta.cli_execution: { "strategy": "new|resume|fork|merge_fork", ... }`
- `flow_control.implementation_approach` with exactly 3 steps (red/green/refactor)
- Green phase includes test-fix-cycle configuration
- `context.focus_paths`: absolute or clear relative paths (enhanced with exploration critical_files)
- `flow_control.pre_analysis`: includes exploration integration_points analysis
- IMPL_PLAN.md contains workflow_type: "tdd" in frontmatter
- Task count ≤10 (compliance with task limit)
- User configuration applied:
- If executionMethod == "cli" or "hybrid": command field added to steps
- CLI tool preference reflected in execution guidance
- Task count ≤18 (compliance with hard limit)
<!-- TodoWrite: When task-generate-tdd dispatched, INSERT 3 task-generate-tdd tasks -->
**Red Flag Detection** (Non-Blocking Warnings):
- Task count >18: `⚠️ Task count exceeds hard limit - request re-scope`
- Missing cli_execution_id: `⚠️ Task lacks CLI execution ID for resume support`
- Missing test-fix-cycle: `⚠️ Green phase lacks auto-revert configuration`
- Generic task names: `⚠️ Vague task names suggest unclear TDD cycles`
- Missing focus_paths: `⚠️ Task lacks clear file scope for implementation`
**TodoWrite Update (Phase 5 SlashCommand dispatched - tasks attached)**:
**Action**: Log warnings to `.workflow/active/[sessionId]/.process/tdd-warnings.log` (non-blocking)
<!-- TodoWrite: When task-generate-tdd executed, INSERT 3 task-generate-tdd tasks -->
**TodoWrite Update (Phase 5 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Phase 1: Session Discovery", "status": "completed", "activeForm": "Executing session discovery"},
@@ -267,7 +325,7 @@ SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
]
```
**Note**: SlashCommand dispatch **attaches** task-generate-tdd's 3 tasks. Orchestrator **executes** these tasks. Each generated IMPL task will contain internal Red-Green-Refactor cycle.
**Note**: SlashCommand execute **attaches** task-generate-tdd's 3 tasks. Orchestrator **executes** these tasks. Each generated IMPL task will contain internal Red-Green-Refactor cycle.
**Next Action**: Tasks attached → **Execute Phase 5.1-5.3** sequentially
@@ -293,14 +351,59 @@ SlashCommand(command="/workflow:tools:task-generate-tdd --session [sessionId]")
1. Each task contains complete TDD workflow (Red-Green-Refactor internally)
2. Task structure validation:
- `meta.tdd_workflow: true` in all IMPL tasks
- `meta.cli_execution_id` present (format: {session_id}-{task_id})
- `meta.cli_execution` strategy assigned (new/resume/fork/merge_fork)
- `flow_control.implementation_approach` has exactly 3 steps
- Each step has correct `tdd_phase`: "red", "green", "refactor"
- `context.focus_paths` are absolute or clear relative paths
- `flow_control.pre_analysis` includes exploration integration analysis
3. Dependency validation:
- Sequential features: IMPL-N depends_on ["IMPL-(N-1)"] if needed
- Complex features: IMPL-N.M depends_on ["IMPL-N.(M-1)"] for subtasks
- CLI execution strategies correctly assigned based on dependency graph
4. Agent assignment: All IMPL tasks use @code-developer
5. Test-fix cycle: Green phase step includes test-fix-cycle logic with max_iterations
6. Task count: Total tasks ≤10 (simple + subtasks)
6. Task count: Total tasks ≤18 (simple + subtasks hard limit)
7. User configuration:
- Execution method choice reflected in task structure
- CLI tool preference documented in implementation guidance (if CLI selected)
**Red Flag Checklist** (from TDD best practices):
- [ ] No tasks skip Red phase (`tdd_phase: "red"` exists in step 1)
- [ ] Test files referenced in Red phase (explicit paths, not placeholders)
- [ ] Green phase has test-fix-cycle with `max_iterations` configured
- [ ] Refactor phase has clear completion criteria
**Non-Compliance Warning Format**:
```
⚠️ TDD Red Flag: [issue description]
Task: [IMPL-N]
Recommendation: [action to fix]
```
**Evidence Gathering** (Before Completion Claims):
```bash
# Verify session artifacts exist
ls -la .workflow/active/[sessionId]/{IMPL_PLAN.md,TODO_LIST.md}
ls -la .workflow/active/[sessionId]/.task/IMPL-*.json
# Count generated artifacts
echo "IMPL tasks: $(ls .workflow/active/[sessionId]/.task/IMPL-*.json 2>/dev/null | wc -l)"
# Sample task structure verification (first task)
jq '{id, tdd: .meta.tdd_workflow, cli_id: .meta.cli_execution_id, phases: [.flow_control.implementation_approach[].tdd_phase]}' \
"$(ls .workflow/active/[sessionId]/.task/IMPL-*.json | head -1)"
```
**Evidence Required Before Summary**:
| Evidence Type | Verification Method | Pass Criteria |
|---------------|---------------------|---------------|
| File existence | `ls -la` artifacts | All files present |
| Task count | Count IMPL-*.json | Count matches claims (≤18) |
| TDD structure | jq sample extraction | Shows red/green/refactor + cli_execution_id |
| CLI execution IDs | jq extraction | All tasks have cli_execution_id assigned |
| Warning log | Check tdd-warnings.log | Logged (may be empty) |
**Return Summary**:
```
@@ -312,7 +415,7 @@ Total tasks: [M] (1 task per simple feature + subtasks for complex features)
Task breakdown:
- Simple features: [K] tasks (IMPL-1 to IMPL-K)
- Complex features: [L] features with [P] subtasks
- Total task count: [M] (within 10-task limit)
- Total task count: [M] (within 18-task hard limit)
Structure:
- IMPL-1: {Feature 1 Name} (Internal: Red → Green → Refactor)
@@ -326,19 +429,31 @@ Plans generated:
- Unified Implementation Plan: .workflow/active/[sessionId]/IMPL_PLAN.md
(includes TDD Implementation Tasks section with workflow_type: "tdd")
- Task List: .workflow/active/[sessionId]/TODO_LIST.md
(with internal TDD phase indicators)
(with internal TDD phase indicators and CLI execution strategies)
- Task JSONs: .workflow/active/[sessionId]/.task/IMPL-*.json
(with cli_execution_id and execution strategies for resume support)
TDD Configuration:
- Each task contains complete Red-Green-Refactor cycle
- Green phase includes test-fix cycle (max 3 iterations)
- Auto-revert on max iterations reached
- CLI execution strategies: new/resume/fork/merge_fork based on dependency graph
User Configuration Applied:
- Execution Method: [agent|hybrid|cli]
- CLI Tool Preference: [codex|gemini|qwen|auto]
- Supplementary Materials: [included|none]
- Task generation follows cli-tools-usage.md guidelines
⚠️ ACTION REQUIRED: Before execution, ensure you understand WHY each Red phase test is expected to fail.
This is crucial for valid TDD - if you don't know why the test fails, you can't verify it tests the right thing.
Recommended Next Steps:
1. /workflow:action-plan-verify --session [sessionId] # Verify TDD plan quality and dependencies
2. /workflow:execute --session [sessionId] # Start TDD execution
1. /workflow:plan-verify --session [sessionId] # Verify TDD plan quality and dependencies
2. /workflow:execute --session [sessionId] # Start TDD execution with CLI strategies
3. /workflow:tdd-verify [sessionId] # Post-execution TDD compliance check
Quality Gate: Consider running /workflow:action-plan-verify to validate TDD task structure and dependencies
Quality Gate: Consider running /workflow:plan-verify to validate TDD task structure, dependencies, and CLI execution strategies
```
## TodoWrite Pattern
@@ -347,7 +462,7 @@ Quality Gate: Consider running /workflow:action-plan-verify to validate TDD task
### Key Principles
1. **Task Attachment** (when SlashCommand dispatched):
1. **Task Attachment** (when SlashCommand executed):
- Sub-command's internal tasks are **attached** to orchestrator's TodoWrite
- Example: `/workflow:tools:test-context-gather` attaches 3 sub-tasks (Phase 3.1, 3.2, 3.3)
- First attached task marked as `in_progress`, others as `pending`
@@ -364,7 +479,7 @@ Quality Gate: Consider running /workflow:action-plan-verify to validate TDD task
- No user intervention required between phases
- TodoWrite dynamically reflects current execution state
**Lifecycle Summary**: Initial pending tasks → Phase dispatched (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins (conditional Phase 4 if conflict_risk ≥ medium) → Repeat until all phases complete.
**Lifecycle Summary**: Initial pending tasks → Phase executed (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins (conditional Phase 4 if conflict_risk ≥ medium) → Repeat until all phases complete.
### TDD-Specific Features
@@ -400,7 +515,7 @@ TDD Workflow Orchestrator
│ IF conflict_risk ≥ medium:
│ └─ /workflow:tools:conflict-resolution ← ATTACHED (3 tasks)
│ ├─ Phase 4.1: Detect conflicts with CLI
│ ├─ Phase 4.2: Present conflicts to user
│ ├─ Phase 4.2: Log and analyze detected conflicts
│ └─ Phase 4.3: Apply resolution strategies
│ └─ Returns: conflict-resolution.json ← COLLAPSED
│ ELSE:
@@ -416,7 +531,7 @@ TDD Workflow Orchestrator
└─ Phase 6: TDD Structure Validation
└─ Internal validation + summary returned
└─ Recommend: /workflow:action-plan-verify
└─ Recommend: /workflow:plan-verify
Key Points:
• ← ATTACHED: SlashCommand attaches sub-tasks to orchestrator TodoWrite
@@ -439,6 +554,36 @@ Convert user input to TDD-structured format:
- **Command failure**: Keep phase in_progress, report error
- **TDD validation failure**: Report incomplete chains or wrong dependencies
### TDD Warning Patterns
| 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 |
### 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`
### 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 `/workflow:tools:context-gather` |
| 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 `/workflow:tools:test-context-gather` |
| 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 |
## Related Commands
**Prerequisite Commands**:
@@ -453,8 +598,33 @@ Convert user input to TDD-structured format:
- `/workflow:tools:task-generate-tdd` - Phase 5: Generate TDD tasks (CLI tool usage determined semantically)
**Follow-up Commands**:
- `/workflow:action-plan-verify` - Recommended: Verify TDD plan quality and structure before execution
- `/workflow:plan-verify` - Recommended: Verify TDD plan quality and structure before execution
- `/workflow:status` - Review TDD task breakdown
- `/workflow:execute` - Begin TDD implementation
- `/workflow:tdd-verify` - Post-execution: Verify TDD compliance and generate quality report
## Next Steps Decision Table
| Situation | Recommended Command | Purpose |
|-----------|---------------------|---------|
| First time planning | `/workflow:plan-verify` | Validate task structure before execution |
| Warnings in tdd-warnings.log | Review log, refine tasks | Address Red Flags before proceeding |
| High task count warning | Consider `/workflow:session:start` | Split into focused sub-sessions |
| Ready to implement | `/workflow:execute` | Begin TDD Red-Green-Refactor cycles |
| After implementation | `/workflow:tdd-verify` | Generate TDD compliance report |
| Need to review tasks | `/workflow:status --session [id]` | Inspect current task breakdown |
| Plan needs changes | `/task:replan` | Update task JSON with new requirements |
### TDD Workflow State Transitions
```
/workflow:tdd-plan
[Planning Complete] ──→ /workflow:plan-verify (recommended)
[Verified/Ready] ─────→ /workflow:execute
[Implementation] ─────→ /workflow:tdd-verify (post-execution)
[Quality Report] ─────→ Done or iterate
```

View File

@@ -1,214 +1,301 @@
---
name: tdd-verify
description: Verify TDD workflow compliance against Red-Green-Refactor cycles, generate quality report with coverage analysis
argument-hint: "[optional: WFS-session-id]"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(gemini:*)
description: Verify TDD workflow compliance against Red-Green-Refactor cycles. Generates quality report with coverage analysis and quality gate recommendation. Orchestrates sub-commands for comprehensive validation.
argument-hint: "[optional: --session WFS-session-id]"
allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Write(*), Bash(*), Glob(*)
---
# TDD Verification Command (/workflow:tdd-verify)
## Goal
Verify TDD workflow execution quality by validating Red-Green-Refactor cycle compliance, test coverage completeness, and task chain structure integrity. This command orchestrates multiple analysis phases and generates a comprehensive compliance report with quality gate recommendation.
**Output**: A structured Markdown report saved to `.workflow/active/WFS-{session}/TDD_COMPLIANCE_REPORT.md` containing:
- Executive summary with compliance score and quality gate recommendation
- Task chain validation (TEST → IMPL → REFACTOR structure)
- Test coverage metrics (line, branch, function)
- Red-Green-Refactor cycle verification
- Best practices adherence assessment
- Actionable improvement recommendations
## Operating Constraints
**ORCHESTRATOR MODE**:
- This command coordinates multiple sub-commands (`/workflow:tools:tdd-coverage-analysis`, `ccw cli`)
- MAY write output files: TDD_COMPLIANCE_REPORT.md (primary report), .process/*.json (intermediate artifacts)
- MUST NOT modify source task files or implementation code
- MUST NOT create or delete tasks in the workflow
**Quality Gate Authority**: The compliance report provides a binding recommendation (BLOCK_MERGE / REQUIRE_FIXES / PROCEED_WITH_CAVEATS / APPROVED) based on objective compliance criteria.
## Coordinator Role
**This command is a pure orchestrator**: Execute 4 phases to verify TDD workflow compliance, test coverage, and Red-Green-Refactor cycle execution.
## Core Responsibilities
- Verify TDD task chain structure
- Analyze test coverage
- Validate TDD cycle execution
- Generate compliance report
- Verify TDD task chain structure (TEST → IMPL → REFACTOR)
- Analyze test coverage metrics
- Validate TDD cycle execution quality
- Generate compliance report with quality gate recommendation
## Execution Process
```
Input Parsing:
└─ Decision (session argument):
├─ session-id provided → Use provided session
└─ No session-id → Auto-detect active session
├─ --session provided → Use provided session
└─ No session → Auto-detect active session
Phase 1: Session Discovery
├─ Validate session directory exists
TodoWrite: Mark phase 1 completed
Phase 1: Session Discovery & Validation
├─ Detect or validate session directory
Check required artifacts exist (.task/*.json, .summaries/*)
└─ ERROR if invalid or incomplete
Phase 2: Task Chain Validation
Phase 2: Task Chain Structure Validation
├─ Load all task JSONs from .task/
├─ Extract task IDs and group by feature
├─ Validate TDD structure:
│ ├─ TEST-N.M → IMPL-N.M → REFACTOR-N.M chain
│ ├─ Dependency verification
│ └─ Meta field validation (tdd_phase, agent)
└─ TodoWrite: Mark phase 2 completed
├─ Validate TDD structure: TEST-N.M → IMPL-N.M → REFACTOR-N.M
├─ Verify dependencies (depends_on)
├─ Validate meta fields (tdd_phase, agent)
└─ Extract chain validation data
Phase 3: Test Execution Analysis
└─ /workflow:tools:tdd-coverage-analysis
├─ Coverage metrics extraction
├─ TDD cycle verification
└─ Compliance score calculation
Phase 3: Coverage & Cycle Analysis
├─ Call: /workflow:tools:tdd-coverage-analysis
├─ Parse: test-results.json, coverage-report.json, tdd-cycle-report.md
└─ Extract coverage metrics and TDD cycle verification
Phase 4: Compliance Report Generation
├─ Gemini analysis for comprehensive report
├─ Aggregate findings from Phases 1-3
├─ Calculate compliance score (0-100)
├─ Determine quality gate recommendation
├─ Generate TDD_COMPLIANCE_REPORT.md
└─ Return summary to user
└─ Display summary to user
```
## 4-Phase Execution
### Phase 1: Session Discovery
**Auto-detect or use provided session**
### Phase 1: Session Discovery & Validation
**Step 1.1: Detect Session**
```bash
# If session-id provided
sessionId = argument
IF --session parameter provided:
session_id = provided session
ELSE:
# Auto-detect active session
active_sessions = bash(find .workflow/active/ -name "WFS-*" -type d 2>/dev/null)
IF active_sessions is empty:
ERROR: "No active workflow session found. Use --session <session-id>"
EXIT
ELSE IF active_sessions has multiple entries:
# Use most recently modified session
session_id = bash(ls -td .workflow/active/WFS-*/ 2>/dev/null | head -1 | xargs basename)
ELSE:
session_id = basename(active_sessions[0])
# Else auto-detect active session
find .workflow/active/ -name "WFS-*" -type d | head -1 | sed 's/.*\///'
# Derive paths
session_dir = .workflow/active/WFS-{session_id}
task_dir = session_dir/.task
summaries_dir = session_dir/.summaries
process_dir = session_dir/.process
```
**Extract**: sessionId
**Step 1.2: Validate Required Artifacts**
```bash
# Check task files exist
task_files = Glob(task_dir/*.json)
IF task_files.count == 0:
ERROR: "No task JSON files found. Run /workflow:tdd-plan first"
EXIT
**Validation**: Session directory exists
# Check summaries exist (optional but recommended for full analysis)
summaries_exist = EXISTS(summaries_dir)
IF NOT summaries_exist:
WARNING: "No .summaries/ directory found. Some analysis may be limited."
```
**TodoWrite**: Mark phase 1 completed, phase 2 in_progress
**Output**: session_id, session_dir, task_files list
---
### Phase 2: Task Chain Validation
**Validate TDD structure using bash commands**
### Phase 2: Task Chain Structure Validation
**Step 2.1: Load and Parse Task JSONs**
```bash
# Load all task JSONs
for task_file in .workflow/active/{sessionId}/.task/*.json; do
cat "$task_file"
done
# Single-pass JSON extraction using jq
validation_data = bash("""
# Load all tasks and extract structured data
cd '{session_dir}/.task'
# Extract task IDs
for task_file in .workflow/active/{sessionId}/.task/*.json; do
cat "$task_file" | jq -r '.id'
done
# Extract all task IDs
task_ids=$(jq -r '.id' *.json 2>/dev/null | sort)
# Check dependencies - read tasks and filter for IMPL/REFACTOR
for task_file in .workflow/active/{sessionId}/.task/IMPL-*.json; do
cat "$task_file" | jq -r '.context.depends_on[]?'
done
# Extract dependencies for IMPL tasks
impl_deps=$(jq -r 'select(.id | startswith("IMPL")) | .id + ":" + (.context.depends_on[]? // "none")' *.json 2>/dev/null)
for task_file in .workflow/active/{sessionId}/.task/REFACTOR-*.json; do
cat "$task_file" | jq -r '.context.depends_on[]?'
done
# Extract dependencies for REFACTOR tasks
refactor_deps=$(jq -r 'select(.id | startswith("REFACTOR")) | .id + ":" + (.context.depends_on[]? // "none")' *.json 2>/dev/null)
# Check meta fields
for task_file in .workflow/active/{sessionId}/.task/*.json; do
cat "$task_file" | jq -r '.meta.tdd_phase'
done
# Extract meta fields
meta_tdd=$(jq -r '.id + ":" + (.meta.tdd_phase // "missing")' *.json 2>/dev/null)
meta_agent=$(jq -r '.id + ":" + (.meta.agent // "missing")' *.json 2>/dev/null)
for task_file in .workflow/active/{sessionId}/.task/*.json; do
cat "$task_file" | jq -r '.meta.agent'
done
# Output as JSON
jq -n --arg ids "$task_ids" \\
--arg impl "$impl_deps" \\
--arg refactor "$refactor_deps" \\
--arg tdd "$meta_tdd" \\
--arg agent "$meta_agent" \\
'{ids: $ids, impl_deps: $impl, refactor_deps: $refactor, tdd: $tdd, agent: $agent}'
""")
```
**Validation**:
- For each feature N, verify TEST-N.M → IMPL-N.M → REFACTOR-N.M exists
- IMPL-N.M.context.depends_on includes TEST-N.M
- REFACTOR-N.M.context.depends_on includes IMPL-N.M
- TEST tasks have tdd_phase="red" and agent="@code-review-test-agent"
- IMPL/REFACTOR tasks have tdd_phase="green"/"refactor" and agent="@code-developer"
**Step 2.2: Validate TDD Chain Structure**
```
Parse validation_data JSON and validate:
**Extract**: Chain validation report
For each feature N (extracted from task IDs):
1. TEST-N.M exists?
2. IMPL-N.M exists?
3. REFACTOR-N.M exists? (optional but recommended)
4. IMPL-N.M.context.depends_on contains TEST-N.M?
5. REFACTOR-N.M.context.depends_on contains IMPL-N.M?
6. TEST-N.M.meta.tdd_phase == "red"?
7. TEST-N.M.meta.agent == "@code-review-test-agent"?
8. IMPL-N.M.meta.tdd_phase == "green"?
9. IMPL-N.M.meta.agent == "@code-developer"?
10. REFACTOR-N.M.meta.tdd_phase == "refactor"?
**TodoWrite**: Mark phase 2 completed, phase 3 in_progress
Calculate:
- chain_completeness_score = (complete_chains / total_chains) * 100
- dependency_accuracy = (correct_deps / total_deps) * 100
- meta_field_accuracy = (correct_meta / total_meta) * 100
```
**Output**: chain_validation_report (JSON structure with validation results)
---
### Phase 3: Test Execution Analysis
**Command**: `SlashCommand(command="/workflow:tools:tdd-coverage-analysis --session [sessionId]")`
### Phase 3: Coverage & Cycle Analysis
**Input**: sessionId from Phase 1
**Step 3.1: Call Coverage Analysis Sub-command**
```bash
SlashCommand(command="/workflow:tools:tdd-coverage-analysis --session {session_id}")
```
**Parse Output**:
- Coverage metrics (line, branch, function percentages)
- TDD cycle verification results
- Compliance score
**Step 3.2: Parse Output Files**
```bash
# Check required outputs exist
IF NOT EXISTS(process_dir/test-results.json):
WARNING: "test-results.json not found. Coverage analysis incomplete."
coverage_data = null
ELSE:
coverage_data = Read(process_dir/test-results.json)
**Validation**:
- `.workflow/active/{sessionId}/.process/test-results.json` exists
- `.workflow/active/{sessionId}/.process/coverage-report.json` exists
- `.workflow/active/{sessionId}/.process/tdd-cycle-report.md` exists
IF NOT EXISTS(process_dir/coverage-report.json):
WARNING: "coverage-report.json not found. Coverage metrics incomplete."
metrics = null
ELSE:
metrics = Read(process_dir/coverage-report.json)
**TodoWrite**: Mark phase 3 completed, phase 4 in_progress
IF NOT EXISTS(process_dir/tdd-cycle-report.md):
WARNING: "tdd-cycle-report.md not found. Cycle validation incomplete."
cycle_data = null
ELSE:
cycle_data = Read(process_dir/tdd-cycle-report.md)
```
**Step 3.3: Extract Coverage Metrics**
```
If coverage_data exists:
- line_coverage_percent
- branch_coverage_percent
- function_coverage_percent
- uncovered_files (list)
- uncovered_lines (map: file -> line ranges)
If cycle_data exists:
- red_phase_compliance (tests failed initially?)
- green_phase_compliance (tests pass after impl?)
- refactor_phase_compliance (tests stay green during refactor?)
- minimal_implementation_score (was impl minimal?)
```
**Output**: coverage_analysis, cycle_analysis
---
### Phase 4: Compliance Report Generation
**Gemini analysis for comprehensive TDD compliance report**
**Step 4.1: Calculate Compliance Score**
```
Base Score: 100 points
Deductions:
Chain Structure:
- Missing TEST task: -30 points per feature
- Missing IMPL task: -30 points per feature
- Missing REFACTOR task: -10 points per feature
- Wrong dependency: -15 points per error
- Wrong agent: -5 points per error
- Wrong tdd_phase: -5 points per error
TDD Cycle Compliance:
- Test didn't fail initially: -10 points per feature
- Tests didn't pass after IMPL: -20 points per feature
- Tests broke during REFACTOR: -15 points per feature
- Over-engineered IMPL: -10 points per feature
Coverage Quality:
- Line coverage < 80%: -5 points
- Branch coverage < 70%: -5 points
- Function coverage < 80%: -5 points
- Critical paths uncovered: -10 points
Final Score: Max(0, Base Score - Total Deductions)
```
**Step 4.2: Determine Quality Gate**
```
IF score >= 90 AND no_critical_violations:
recommendation = "APPROVED"
ELSE IF score >= 70 AND critical_violations == 0:
recommendation = "PROCEED_WITH_CAVEATS"
ELSE IF score >= 50:
recommendation = "REQUIRE_FIXES"
ELSE:
recommendation = "BLOCK_MERGE"
```
**Step 4.3: Generate Report**
```bash
ccw cli -p "
PURPOSE: Generate TDD compliance report
TASK: Analyze TDD workflow execution and generate quality report
CONTEXT: @{.workflow/active/{sessionId}/.task/*.json,.workflow/active/{sessionId}/.summaries/*,.workflow/active/{sessionId}/.process/tdd-cycle-report.md}
EXPECTED:
- TDD compliance score (0-100)
- Chain completeness verification
- Test coverage analysis summary
- Quality recommendations
- Red-Green-Refactor cycle validation
- Best practices adherence assessment
RULES: Focus on TDD best practices and workflow adherence. Be specific about violations and improvements.
" --tool gemini --mode analysis --cd project-root > .workflow/active/{sessionId}/TDD_COMPLIANCE_REPORT.md
report_content = Generate markdown report (see structure below)
report_path = "{session_dir}/TDD_COMPLIANCE_REPORT.md"
Write(report_path, report_content)
```
**Output**: TDD_COMPLIANCE_REPORT.md
**TodoWrite**: Mark phase 4 completed
**Return to User**:
```
TDD Verification Report - Session: {sessionId}
## Chain Validation
[COMPLETE] Feature 1: TEST-1.1 → IMPL-1.1 → REFACTOR-1.1 (Complete)
[COMPLETE] Feature 2: TEST-2.1 → IMPL-2.1 → REFACTOR-2.1 (Complete)
[INCOMPLETE] Feature 3: TEST-3.1 → IMPL-3.1 (Missing REFACTOR phase)
## Test Execution
All TEST tasks produced failing tests
All IMPL tasks made tests pass
All REFACTOR tasks maintained green tests
## Coverage Metrics
Line Coverage: {percentage}%
Branch Coverage: {percentage}%
Function Coverage: {percentage}%
## Compliance Score: {score}/100
Detailed report: .workflow/active/{sessionId}/TDD_COMPLIANCE_REPORT.md
Recommendations:
- Complete missing REFACTOR-3.1 task
- Consider additional edge case tests for Feature 2
- Improve test failure message clarity in Feature 1
**Step 4.4: Display Summary to User**
```bash
echo "=== TDD Verification Complete ==="
echo "Session: {session_id}"
echo "Report: {report_path}"
echo ""
echo "Quality Gate: {recommendation}"
echo "Compliance Score: {score}/100"
echo ""
echo "Chain Validation: {chain_completeness_score}%"
echo "Line Coverage: {line_coverage}%"
echo "Branch Coverage: {branch_coverage}%"
echo ""
echo "Next: Review full report for detailed findings"
```
## TodoWrite Pattern
## TodoWrite Pattern (Optional)
**Note**: As an orchestrator command, TodoWrite tracking is optional and primarily useful for long-running verification processes. For most cases, the 4-phase execution is fast enough that progress tracking adds noise without value.
```javascript
// Initialize (before Phase 1)
TodoWrite({todos: [
{"content": "Identify target session", "status": "in_progress", "activeForm": "Identifying target session"},
{"content": "Validate task chain structure", "status": "pending", "activeForm": "Validating task chain structure"},
{"content": "Analyze test execution", "status": "pending", "activeForm": "Analyzing test execution"},
{"content": "Generate compliance report", "status": "pending", "activeForm": "Generating compliance report"}
]})
// After Phase 1
TodoWrite({todos: [
{"content": "Identify target session", "status": "completed", "activeForm": "Identifying target session"},
{"content": "Validate task chain structure", "status": "in_progress", "activeForm": "Validating task chain structure"},
{"content": "Analyze test execution", "status": "pending", "activeForm": "Analyzing test execution"},
{"content": "Generate compliance report", "status": "pending", "activeForm": "Generating compliance report"}
]})
// Continue pattern for Phase 2, 3, 4...
// Only use TodoWrite for complex multi-session verification
// Skip for single-session verification
```
## Validation Logic
@@ -229,27 +316,24 @@ TodoWrite({todos: [
5. Report incomplete or invalid chains
```
### Compliance Scoring
```
Base Score: 100 points
### Quality Gate Criteria
Deductions:
- Missing TEST task: -30 points per feature
- Missing IMPL task: -30 points per feature
- Missing REFACTOR task: -10 points per feature
- Wrong dependency: -15 points per error
- Wrong agent: -5 points per error
- Wrong tdd_phase: -5 points per error
- Test didn't fail initially: -10 points per feature
- Tests didn't pass after IMPL: -20 points per feature
- Tests broke during REFACTOR: -15 points per feature
| Recommendation | Score Range | Critical Violations | Action |
|----------------|-------------|---------------------|--------|
| **APPROVED** | ≥90 | 0 | Safe to merge |
| **PROCEED_WITH_CAVEATS** | ≥70 | 0 | Can proceed, address minor issues |
| **REQUIRE_FIXES** | ≥50 | Any | Must fix before merge |
| **BLOCK_MERGE** | <50 | Any | Block merge until resolved |
Final Score: Max(0, Base Score - Deductions)
```
**Critical Violations**:
- Missing TEST or IMPL task for any feature
- Tests didn't fail initially (Red phase violation)
- Tests didn't pass after IMPL (Green phase violation)
- Tests broke during REFACTOR (Refactor phase violation)
## Output Files
```
.workflow/active/{session-id}/
.workflow/active/WFS-{session-id}/
├── TDD_COMPLIANCE_REPORT.md # Comprehensive compliance report ⭐
└── .process/
├── test-results.json # From tdd-coverage-analysis
@@ -262,14 +346,14 @@ Final Score: Max(0, Base Score - Deductions)
### Session Discovery Errors
| Error | Cause | Resolution |
|-------|-------|------------|
| No active session | No WFS-* directories | Provide session-id explicitly |
| Multiple active sessions | Multiple WFS-* directories | Provide session-id explicitly |
| No active session | No WFS-* directories | Provide --session explicitly |
| Multiple active sessions | Multiple WFS-* directories | Provide --session explicitly |
| Session not found | Invalid session-id | Check available sessions |
### Validation Errors
| Error | Cause | Resolution |
|-------|-------|------------|
| Task files missing | Incomplete planning | Run tdd-plan first |
| Task files missing | Incomplete planning | Run /workflow:tdd-plan first |
| Invalid JSON | Corrupted task files | Regenerate tasks |
| Missing summaries | Tasks not executed | Execute tasks before verify |
@@ -278,13 +362,13 @@ Final Score: Max(0, Base Score - Deductions)
|-------|-------|------------|
| Coverage tool missing | No test framework | Configure testing first |
| Tests fail to run | Code errors | Fix errors before verify |
| Gemini analysis fails | Token limit / API error | Retry or reduce context |
| Sub-command fails | tdd-coverage-analysis error | Check sub-command logs |
## Integration & Usage
### Command Chain
- **Called After**: `/workflow:execute` (when TDD tasks completed)
- **Calls**: `/workflow:tools:tdd-coverage-analysis`, Gemini CLI
- **Calls**: `/workflow:tools:tdd-coverage-analysis`
- **Related**: `/workflow:tdd-plan`, `/workflow:status`
### Basic Usage
@@ -293,7 +377,7 @@ Final Score: Max(0, Base Score - Deductions)
/workflow:tdd-verify
# Specify session
/workflow:tdd-verify WFS-auth
/workflow:tdd-verify --session WFS-auth
```
### When to Use
@@ -308,61 +392,125 @@ Final Score: Max(0, Base Score - Deductions)
# TDD Compliance Report - {Session ID}
**Generated**: {timestamp}
**Session**: {sessionId}
**Session**: WFS-{sessionId}
**Workflow Type**: TDD
---
## Executive Summary
Overall Compliance Score: {score}/100
Status: {EXCELLENT | GOOD | NEEDS IMPROVEMENT | FAILED}
### Quality Gate Decision
| Metric | Value | Status |
|--------|-------|--------|
| Compliance Score | {score}/100 | {status_emoji} |
| Chain Completeness | {percentage}% | {status} |
| Line Coverage | {percentage}% | {status} |
| Branch Coverage | {percentage}% | {status} |
| Function Coverage | {percentage}% | {status} |
### Recommendation
**{RECOMMENDATION}**
**Decision Rationale**:
{brief explanation based on score and violations}
**Quality Gate Criteria**:
- **APPROVED**: Score ≥90, no critical violations
- **PROCEED_WITH_CAVEATS**: Score ≥70, no critical violations
- **REQUIRE_FIXES**: Score ≥50 or critical violations exist
- **BLOCK_MERGE**: Score <50
---
## Chain Analysis
### Feature 1: {Feature Name}
**Status**: Complete
**Status**: Complete
**Chain**: TEST-1.1 → IMPL-1.1 → REFACTOR-1.1
- **Red Phase**: Test created and failed with clear message
- **Green Phase**: Minimal implementation made test pass
- **Refactor Phase**: Code improved, tests remained green
| Phase | Task | Status | Details |
|-------|------|--------|---------|
| Red | TEST-1.1 | ✅ Pass | Test created and failed with clear message |
| Green | IMPL-1.1 | ✅ Pass | Minimal implementation made test pass |
| Refactor | REFACTOR-1.1 | ✅ Pass | Code improved, tests remained green |
### Feature 2: {Feature Name}
**Status**: Incomplete
**Status**: ⚠️ Incomplete
**Chain**: TEST-2.1 → IMPL-2.1 (Missing REFACTOR-2.1)
- **Red Phase**: Test created and failed
- **Green Phase**: Implementation seems over-engineered
- **Refactor Phase**: Missing
| Phase | Task | Status | Details |
|-------|------|--------|---------|
| Red | TEST-2.1 | ✅ Pass | Test created and failed |
| Green | IMPL-2.1 | ⚠️ Warning | Implementation seems over-engineered |
| Refactor | REFACTOR-2.1 | ❌ Missing | Task not completed |
**Issues**:
- REFACTOR-2.1 task not completed
- IMPL-2.1 implementation exceeded minimal scope
- REFACTOR-2.1 task not completed (-10 points)
- IMPL-2.1 implementation exceeded minimal scope (-10 points)
[Repeat for all features]
### Chain Validation Summary
| Metric | Value |
|--------|-------|
| Total Features | {count} |
| Complete Chains | {count} ({percent}%) |
| Incomplete Chains | {count} |
| Missing TEST | {count} |
| Missing IMPL | {count} |
| Missing REFACTOR | {count} |
| Dependency Errors | {count} |
| Meta Field Errors | {count} |
---
## Test Coverage Analysis
### Coverage Metrics
- Line Coverage: {percentage}% {status}
- Branch Coverage: {percentage}% {status}
- Function Coverage: {percentage}% {status}
| Metric | Coverage | Target | Status |
|--------|----------|--------|--------|
| Line Coverage | {percentage}% | ≥80% | {status} |
| Branch Coverage | {percentage}% | ≥70% | {status} |
| Function Coverage | {percentage}% | ≥80% | {status} |
### Coverage Gaps
- {file}:{lines} - Uncovered error handling
- {file}:{lines} - Uncovered edge case
| File | Lines | Issue | Priority |
|------|-------|-------|----------|
| src/auth/service.ts | 45-52 | Uncovered error handling | HIGH |
| src/utils/parser.ts | 78-85 | Uncovered edge case | MEDIUM |
---
## TDD Cycle Validation
### Red Phase (Write Failing Test)
- {N}/{total} features had failing tests initially
- Feature 3: No evidence of initial test failure
- {N}/{total} features had failing tests initially ({percent}%)
- ✅ Compliant features: {list}
- ❌ Non-compliant features: {list}
**Violations**:
- Feature 3: No evidence of initial test failure (-10 points)
### Green Phase (Make Test Pass)
- {N}/{total} implementations made tests pass
- All implementations minimal and focused
- {N}/{total} implementations made tests pass ({percent}%)
- ✅ Compliant features: {list}
- ❌ Non-compliant features: {list}
**Violations**:
- Feature 2: Implementation over-engineered (-10 points)
### Refactor Phase (Improve Quality)
- {N}/{total} features completed refactoring
- Feature 2, 4: Refactoring step skipped
- {N}/{total} features completed refactoring ({percent}%)
- ✅ Compliant features: {list}
- ❌ Non-compliant features: {list}
**Violations**:
- Feature 2, 4: Refactoring step skipped (-20 points total)
---
## Best Practices Assessment
@@ -377,24 +525,61 @@ Status: {EXCELLENT | GOOD | NEEDS IMPROVEMENT | FAILED}
- Missing refactoring steps
- Test failure messages could be more descriptive
---
## Detailed Findings by Severity
### Critical Issues ({count})
{List of critical issues with impact and remediation}
### High Priority Issues ({count})
{List of high priority issues with impact and remediation}
### Medium Priority Issues ({count})
{List of medium priority issues with impact and remediation}
### Low Priority Issues ({count})
{List of low priority issues with impact and remediation}
---
## Recommendations
### High Priority
### Required Fixes (Before Merge)
1. Complete missing REFACTOR tasks (Features 2, 4)
2. Verify initial test failures for Feature 3
3. Simplify over-engineered implementations
3. Fix tests that broke during refactoring
### Medium Priority
1. Add edge case tests for Features 1, 3
2. Improve test failure message clarity
3. Increase branch coverage to >85%
### Recommended Improvements
1. Simplify over-engineered implementations
2. Add edge case tests for Features 1, 3
3. Improve test failure message clarity
4. Increase branch coverage to >85%
### Low Priority
### Optional Enhancements
1. Add more descriptive test names
2. Consider parameterized tests for similar scenarios
3. Document TDD process learnings
## Conclusion
{Summary of compliance status and next steps}
---
## Metrics Summary
| Metric | Value |
|--------|-------|
| Total Features | {count} |
| Complete Chains | {count} ({percent}%) |
| Compliance Score | {score}/100 |
| Critical Issues | {count} |
| High Issues | {count} |
| Medium Issues | {count} |
| Low Issues | {count} |
| Line Coverage | {percent}% |
| Branch Coverage | {percent}% |
| Function Coverage | {percent}% |
---
**Report End**
```

View File

@@ -491,6 +491,10 @@ The orchestrator automatically creates git commits at key checkpoints to enable
**Note**: Final session completion creates additional commit with full summary.
## Post-Completion Expansion
完成后询问用户是否扩展为issue(test/enhance/refactor/doc),选中项调用 `/issue:new "{summary} - {dimension}"`
## Best Practices
1. **Default Settings Work**: 10 iterations sufficient for most cases

View File

@@ -59,8 +59,8 @@ This command is a **pure planning coordinator**:
- **All execution delegated to `/workflow:test-cycle-execute`**
**Task Attachment Model**:
- SlashCommand dispatch **expands workflow** by attaching sub-tasks to current TodoWrite
- When dispatching a sub-command (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- SlashCommand execute **expands workflow** by attaching sub-tasks to current TodoWrite
- When executing a sub-command (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- Orchestrator **executes these attached tasks** sequentially
- After completion, attached tasks are **collapsed** back to high-level phase summary
- This is **task expansion**, not external delegation
@@ -128,7 +128,7 @@ This command is a **pure planning coordinator**:
### Core Execution Rules
1. **Start Immediately**: First action is TodoWrite, second is dispatch Phase 1 session creation
1. **Start Immediately**: First action is TodoWrite, second is execute Phase 1 session creation
2. **No Preliminary Analysis**: Do not read files before Phase 1
3. **Parse Every Output**: Extract required data from each phase for next phase
4. **Sequential Execution**: Each phase depends on previous phase's output
@@ -136,7 +136,7 @@ This command is a **pure planning coordinator**:
6. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
7. **Automatic Detection**: Mode auto-detected from input pattern
8. **Semantic CLI Detection**: CLI tool usage determined from user's task description for Phase 4
9. **Task Attachment Model**: SlashCommand dispatch **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
9. **Task Attachment Model**: SlashCommand execute **attaches** sub-tasks to current workflow. Orchestrator **executes** these attached tasks itself, then **collapses** them after completion
10. **⚠️ CRITICAL: DO NOT STOP**: Continuous multi-phase workflow. After executing all attached tasks, immediately collapse them and execute next phase
### 5-Phase Execution
@@ -155,7 +155,7 @@ Read(".workflow/active/[sourceSessionId]/.process/context-package.json")
// This preserves user's CLI tool preferences (e.g., "use Codex for fixes")
```
**Step 1.1: Dispatch** - Create test workflow session with preserved intent
**Step 1.1: Execute** - Create test workflow session with preserved intent
```javascript
// Session Mode - Include original task description to enable semantic CLI selection
@@ -187,7 +187,7 @@ SlashCommand(command="/workflow:session:start --type test --new \"Test generatio
#### Phase 2: Gather Test Context
**Step 2.1: Dispatch** - Gather test context via appropriate method
**Step 2.1: Execute** - Gather test context via appropriate method
```javascript
// Session Mode
@@ -224,7 +224,7 @@ SlashCommand(command="/workflow:tools:context-gather --session [testSessionId] \
#### Phase 3: Test Generation Analysis
**Step 3.1: Dispatch** - Generate test requirements using Gemini
**Step 3.1: Execute** - Generate test requirements using Gemini
```javascript
SlashCommand(command="/workflow:tools:test-concept-enhanced --session [testSessionId] --context [contextPath]")
@@ -284,7 +284,7 @@ For each targeted file/function, Gemini MUST generate:
#### Phase 4: Generate Test Tasks
**Step 4.1: Dispatch** - Generate test task JSONs
**Step 4.1: Execute** - Generate test task JSONs
```javascript
SlashCommand(command="/workflow:tools:test-task-generate --session [testSessionId]")
@@ -381,7 +381,7 @@ CRITICAL - Next Steps:
#### Key Principles
1. **Task Attachment** (when SlashCommand dispatched):
1. **Task Attachment** (when SlashCommand executed):
- Sub-command's internal tasks are **attached** to orchestrator's TodoWrite
- Example - Phase 2 with sub-tasks:
```json
@@ -416,7 +416,7 @@ CRITICAL - Next Steps:
- No user intervention required between phases
- TodoWrite dynamically reflects current execution state
**Lifecycle Summary**: Initial pending tasks → Phase dispatched (tasks ATTACHED with mode-specific context gathering) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins → Repeat until all phases complete.
**Lifecycle Summary**: Initial pending tasks → Phase executed (tasks ATTACHED with mode-specific context gathering) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins → Repeat until all phases complete.
#### Test-Fix-Gen Specific Features

View File

@@ -20,7 +20,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*)
**Task Attachment Model**:
- SlashCommand dispatch **expands workflow** by attaching sub-tasks to current TodoWrite
- When a sub-command is dispatched (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- When a sub-command is executed (e.g., `/workflow:tools:test-context-gather`), its internal tasks are attached to the orchestrator's TodoWrite
- Orchestrator **executes these attached tasks** sequentially
- After completion, attached tasks are **collapsed** back to high-level phase summary
- This is **task expansion**, not external delegation
@@ -69,7 +69,7 @@ Read(".workflow/active/[sourceSessionId]/.process/context-package.json")
// This preserves user's CLI tool preferences (e.g., "use Codex for fixes")
```
**Step 1.1: Dispatch** - Create new test workflow session with preserved intent
**Step 1.1: Execute** - Create new test workflow session with preserved intent
```javascript
// Include original task description to enable semantic CLI selection
@@ -104,7 +104,7 @@ SlashCommand(command="/workflow:session:start --new \"Test validation for [sourc
### Phase 2: Gather Test Context
**Step 2.1: Dispatch** - Gather test coverage context from source session
**Step 2.1: Execute** - Gather test coverage context from source session
```javascript
SlashCommand(command="/workflow:tools:test-context-gather --session [testSessionId]")
@@ -130,9 +130,9 @@ SlashCommand(command="/workflow:tools:test-context-gather --session [testSession
- Test framework detected
- Test conventions documented
<!-- TodoWrite: When test-context-gather dispatched, INSERT 3 test-context-gather tasks -->
<!-- TodoWrite: When test-context-gather executed, INSERT 3 test-context-gather tasks -->
**TodoWrite Update (Phase 2 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 2 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Create independent test session", "status": "completed", "activeForm": "Creating test session"},
@@ -168,7 +168,7 @@ SlashCommand(command="/workflow:tools:test-context-gather --session [testSession
### Phase 3: Test Generation Analysis
**Step 3.1: Dispatch** - Analyze test requirements with Gemini
**Step 3.1: Execute** - Analyze test requirements with Gemini
```javascript
SlashCommand(command="/workflow:tools:test-concept-enhanced --session [testSessionId] --context [testContextPath]")
@@ -199,9 +199,9 @@ SlashCommand(command="/workflow:tools:test-concept-enhanced --session [testSessi
- Implementation Targets (test files to create)
- Success Criteria
<!-- TodoWrite: When test-concept-enhanced dispatched, INSERT 3 concept-enhanced tasks -->
<!-- TodoWrite: When test-concept-enhanced executed, INSERT 3 concept-enhanced tasks -->
**TodoWrite Update (Phase 3 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 3 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Create independent test session", "status": "completed", "activeForm": "Creating test session"},
@@ -237,7 +237,7 @@ SlashCommand(command="/workflow:tools:test-concept-enhanced --session [testSessi
### Phase 4: Generate Test Tasks
**Step 4.1: Dispatch** - Generate test task JSON files and planning documents
**Step 4.1: Execute** - Generate test task JSON files and planning documents
```javascript
SlashCommand(command="/workflow:tools:test-task-generate --session [testSessionId]")
@@ -287,9 +287,9 @@ SlashCommand(command="/workflow:tools:test-task-generate --session [testSessionI
- Phase 2: Iterative Gemini diagnosis + fixes (agent or CLI based on step's `command` field)
- Phase 3: Final validation and certification
<!-- TodoWrite: When test-task-generate dispatched, INSERT 3 test-task-generate tasks -->
<!-- TodoWrite: When test-task-generate executed, INSERT 3 test-task-generate tasks -->
**TodoWrite Update (Phase 4 SlashCommand dispatched - tasks attached)**:
**TodoWrite Update (Phase 4 SlashCommand executed - tasks attached)**:
```json
[
{"content": "Create independent test session", "status": "completed", "activeForm": "Creating test session"},
@@ -364,7 +364,7 @@ Ready for execution. Use appropriate workflow commands to proceed.
### Key Principles
1. **Task Attachment** (when SlashCommand dispatched):
1. **Task Attachment** (when SlashCommand executed):
- Sub-command's internal tasks are **attached** to orchestrator's TodoWrite
- Example: `/workflow:tools:test-context-gather` attaches 3 sub-tasks (Phase 2.1, 2.2, 2.3)
- First attached task marked as `in_progress`, others as `pending`
@@ -381,7 +381,7 @@ Ready for execution. Use appropriate workflow commands to proceed.
- No user intervention required between phases
- TodoWrite dynamically reflects current execution state
**Lifecycle Summary**: Initial pending tasks → Phase dispatched (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins → Repeat until all phases complete.
**Lifecycle Summary**: Initial pending tasks → Phase executed (tasks ATTACHED) → Sub-tasks executed sequentially → Phase completed (tasks COLLAPSED to summary) → Next phase begins → Repeat until all phases complete.
### Test-Gen Specific Features
@@ -517,7 +517,7 @@ See `/workflow:tools:test-task-generate` for complete JSON schemas.
**Prerequisite Commands**:
- `/workflow:plan` or `/workflow:execute` - Complete implementation session that needs test validation
**Dispatched by This Command** (4 phases):
**Executed by This Command** (4 phases):
- `/workflow:session:start` - Phase 1: Create independent test workflow session
- `/workflow:tools:test-context-gather` - Phase 2: Analyze test coverage and gather source session context
- `/workflow:tools:test-concept-enhanced` - Phase 3: Generate test requirements and strategy using Gemini

View File

@@ -1,12 +1,16 @@
---
name: conflict-resolution
description: Detect and resolve conflicts between plan and existing codebase using CLI-powered analysis with Gemini/Qwen
argument-hint: "--session WFS-session-id --context path/to/context-package.json"
argument-hint: "[-y|--yes] --session WFS-session-id --context path/to/context-package.json"
examples:
- /workflow:tools:conflict-resolution --session WFS-auth --context .workflow/active/WFS-auth/.process/context-package.json
- /workflow:tools:conflict-resolution --session WFS-payment --context .workflow/active/WFS-payment/.process/context-package.json
- /workflow:tools:conflict-resolution -y --session WFS-payment --context .workflow/active/WFS-payment/.process/context-package.json
---
## Auto Mode
When `--yes` or `-y`: Auto-select recommended strategy for each conflict, skip clarification questions.
# Conflict Resolution Command
## Purpose
@@ -124,6 +128,9 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
## Analysis Steps
### 0. Load Output Schema (MANDATORY)
Execute: cat ~/.claude/workflows/cli-templates/schemas/conflict-resolution-schema.json
### 1. Load Context
- Read existing files from conflict_detection.existing_files
- Load plan from .workflow/active/{session_id}/.process/context-package.json
@@ -151,8 +158,8 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
- Validation of exploration conflict_indicators
- ModuleOverlap conflicts with overlap_analysis
- Targeted clarification questions
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | Focus on breaking changes, migration needs, and functional overlaps | Prioritize exploration-identified conflicts | analysis=READ-ONLY
" --tool gemini --mode analysis --cd {project_root}
CONSTRAINTS: Focus on breaking changes, migration needs, and functional overlaps | Prioritize exploration-identified conflicts | analysis=READ-ONLY
" --tool gemini --mode analysis --rule analysis-code-patterns --cd {project_root}
Fallback: Qwen (same prompt) → Claude (manual analysis)
@@ -171,123 +178,14 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
⚠️ Output to conflict-resolution.json (generated in Phase 4)
Return JSON format for programmatic processing:
**Schema Reference**: Execute \`cat ~/.claude/workflows/cli-templates/schemas/conflict-resolution-schema.json\` to get full schema
\`\`\`json
{
"conflicts": [
{
"id": "CON-001",
"brief": "一行中文冲突摘要",
"severity": "Critical|High|Medium",
"category": "Architecture|API|Data|Dependency|ModuleOverlap",
"affected_files": [
".workflow/active/{session}/.brainstorm/guidance-specification.md",
".workflow/active/{session}/.brainstorm/system-architect/analysis.md"
],
"description": "详细描述冲突 - 什么不兼容",
"impact": {
"scope": "影响的模块/组件",
"compatibility": "Yes|No|Partial",
"migration_required": true|false,
"estimated_effort": "人天估计"
},
"overlap_analysis": {
"// NOTE": "仅当 category=ModuleOverlap 时需要此字段",
"new_module": {
"name": "新模块名称",
"scenarios": ["场景1", "场景2", "场景3"],
"responsibilities": "职责描述"
},
"existing_modules": [
{
"file": "src/existing/module.ts",
"name": "现有模块名称",
"scenarios": ["场景A", "场景B"],
"overlap_scenarios": ["重叠场景1", "重叠场景2"],
"responsibilities": "现有模块职责"
}
]
},
"strategies": [
{
"name": "策略名称(中文)",
"approach": "实现方法简述",
"complexity": "Low|Medium|High",
"risk": "Low|Medium|High",
"effort": "时间估计",
"pros": ["优点1", "优点2"],
"cons": ["缺点1", "缺点2"],
"clarification_needed": [
"// NOTE: 仅当需要用户进一步澄清时需要此字段(尤其是 ModuleOverlap",
"新模块的核心职责边界是什么?",
"如何与现有模块 X 协作?",
"哪些场景应该由新模块处理?"
],
"modifications": [
{
"file": ".workflow/active/{session}/.brainstorm/guidance-specification.md",
"section": "## 2. System Architect Decisions",
"change_type": "update",
"old_content": "原始内容片段(用于定位)",
"new_content": "修改后的内容",
"rationale": "为什么这样改"
},
{
"file": ".workflow/active/{session}/.brainstorm/system-architect/analysis.md",
"section": "## Design Decisions",
"change_type": "update",
"old_content": "原始内容片段",
"new_content": "修改后的内容",
"rationale": "修改理由"
}
]
},
{
"name": "策略2名称",
"approach": "...",
"complexity": "Medium",
"risk": "Low",
"effort": "1-2天",
"pros": ["优点"],
"cons": ["缺点"],
"modifications": [...]
}
],
"recommended": 0,
"modification_suggestions": [
"建议1具体的修改方向或注意事项",
"建议2可能需要考虑的边界情况",
"建议3相关的最佳实践或模式"
]
}
],
"summary": {
"total": 2,
"critical": 1,
"high": 1,
"medium": 0
}
}
\`\`\`
⚠️ CRITICAL Requirements for modifications field:
- old_content: Must be exact text from target file (20-100 chars for unique match)
- new_content: Complete replacement text (maintains formatting)
- change_type: "update" (replace), "add" (insert), "remove" (delete)
- file: Full path relative to project root
- section: Markdown heading for context (helps locate position)
Return JSON following the schema above. Key requirements:
- Minimum 2 strategies per conflict, max 4
- All text in Chinese for user-facing fields (brief, name, pros, cons)
- modification_suggestions: 2-5 actionable suggestions for custom handling (Chinese)
Quality Standards:
- Each strategy must have actionable modifications
- old_content must be precise enough for Edit tool matching
- new_content preserves markdown formatting and structure
- Recommended strategy (index) based on lowest complexity + risk
- modification_suggestions must be specific, actionable, and context-aware
- Each suggestion should address a specific aspect (compatibility, migration, testing, etc.)
- All text in Chinese for user-facing fields (brief, name, pros, cons, modification_suggestions)
- modifications.old_content: 20-100 chars for unique Edit tool matching
- modifications.new_content: preserves markdown formatting
- modification_suggestions: 2-5 actionable suggestions for custom handling
`)
```
@@ -312,143 +210,93 @@ Task(subagent_type="cli-execution-agent", run_in_background=false, prompt=`
8. Return execution log path
```
### Phase 3: Iterative User Interaction with Clarification Loop
### Phase 3: User Interaction Loop
**Execution Flow**:
```
FOR each conflict (逐个处理,无数量限制):
clarified = false
round = 0
userClarifications = []
```javascript
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
WHILE (!clarified && round < 10):
round++
FOR each conflict:
round = 0, clarified = false, userClarifications = []
// 1. Display conflict (包含所有关键字段)
- category, id, brief, severity, description
- IF ModuleOverlap: 展示 overlap_analysis
* new_module: {name, scenarios, responsibilities}
* existing_modules[]: {file, name, scenarios, overlap_scenarios, responsibilities}
WHILE (!clarified && round++ < 10):
// 1. Display conflict info (text output for context)
displayConflictSummary(conflict) // id, brief, severity, overlap_analysis if ModuleOverlap
// 2. Display strategies (2-4个策略 + 自定义选项)
- FOR each strategy: {name, approach, complexity, risk, effort, pros, cons}
* IF clarification_needed: 展示待澄清问题列表
- 自定义选项: {suggestions: modification_suggestions[]}
// 3. User selects strategy
userChoice = readInput()
IF userChoice == "自定义":
customConflicts.push({id, brief, category, suggestions, overlap_analysis})
clarified = true
BREAK
selectedStrategy = strategies[userChoice]
// 4. Clarification loop
IF selectedStrategy.clarification_needed.length > 0:
// 收集澄清答案
FOR each question:
answer = readInput()
userClarifications.push({question, answer})
// Agent 重新分析
reanalysisResult = Task(cli-execution-agent, prompt={
冲突信息: {id, brief, category, 策略}
用户澄清: userClarifications[]
场景分析: overlap_analysis (if ModuleOverlap)
输出: {
uniqueness_confirmed: bool,
rationale: string,
updated_strategy: {name, approach, complexity, risk, effort, modifications[]},
remaining_questions: [] (如果仍有歧义)
}
// 2. Strategy selection
if (autoYes) {
console.log(`[--yes] Auto-selecting recommended strategy`)
selectedStrategy = conflict.strategies[conflict.recommended || 0]
clarified = true // Skip clarification loop
} else {
AskUserQuestion({
questions: [{
question: formatStrategiesForDisplay(conflict.strategies),
header: "策略选择",
multiSelect: false,
options: [
...conflict.strategies.map((s, i) => ({
label: `${s.name}${i === conflict.recommended ? ' (推荐)' : ''}`,
description: `${s.complexity}复杂度 | ${s.risk}风险${s.clarification_needed?.length ? ' | ⚠️需澄清' : ''}`
})),
{ label: "自定义修改", description: `建议: ${conflict.modification_suggestions?.slice(0,2).join('; ')}` }
]
}]
})
IF reanalysisResult.uniqueness_confirmed:
selectedStrategy = updated_strategy
selectedStrategy.clarifications = userClarifications
clarified = true
ELSE:
// 更新澄清问题,继续下一轮
selectedStrategy.clarification_needed = remaining_questions
ELSE:
clarified = true
// 3. Handle selection
if (userChoice === "自定义修改") {
customConflicts.push({ id, brief, category, suggestions, overlap_analysis })
break
}
resolvedConflicts.push({conflict, strategy: selectedStrategy})
selectedStrategy = findStrategyByName(userChoice)
}
// 4. Clarification (if needed) - batched max 4 per call
if (!autoYes && selectedStrategy.clarification_needed?.length > 0) {
for (batch of chunk(selectedStrategy.clarification_needed, 4)) {
AskUserQuestion({
questions: batch.map((q, i) => ({
question: q, header: `澄清${i+1}`, multiSelect: false,
options: [{ label: "详细说明", description: "提供答案" }]
}))
})
userClarifications.push(...collectAnswers(batch))
}
// 5. Agent re-analysis
reanalysisResult = Task({
subagent_type: "cli-execution-agent",
run_in_background: false,
prompt: `Conflict: ${conflict.id}, Strategy: ${selectedStrategy.name}
User Clarifications: ${JSON.stringify(userClarifications)}
Output: { uniqueness_confirmed, rationale, updated_strategy, remaining_questions }`
})
if (reanalysisResult.uniqueness_confirmed) {
selectedStrategy = { ...reanalysisResult.updated_strategy, clarifications: userClarifications }
clarified = true
} else {
selectedStrategy.clarification_needed = reanalysisResult.remaining_questions
}
} else {
clarified = true
}
if (clarified) resolvedConflicts.push({ conflict, strategy: selectedStrategy })
END WHILE
END FOR
// Build output
selectedStrategies = resolvedConflicts.map(r => ({
conflict_id, strategy, clarifications[]
conflict_id: r.conflict.id, strategy: r.strategy, clarifications: r.strategy.clarifications || []
}))
```
**Key Data Structures**:
```javascript
// Custom conflict tracking
customConflicts[] = {
id, brief, category,
suggestions: modification_suggestions[],
overlap_analysis: { new_module{}, existing_modules[] } // ModuleOverlap only
}
// Agent re-analysis prompt output
{
uniqueness_confirmed: bool,
rationale: string,
updated_strategy: {
name, approach, complexity, risk, effort,
modifications: [{file, section, change_type, old_content, new_content, rationale}]
},
remaining_questions: string[]
}
```
**Text Output Example** (展示关键字段):
```markdown
============================================================
冲突 1/3 - 第 1 轮
============================================================
【ModuleOverlap】CON-001: 新增用户认证服务与现有模块功能重叠
严重程度: High | 描述: 计划中的 UserAuthService 与现有 AuthManager 场景重叠
--- 场景重叠分析 ---
新模块: UserAuthService | 场景: 登录, Token验证, 权限, MFA
现有模块: AuthManager (src/auth/AuthManager.ts) | 重叠: 登录, Token验证
--- 解决策略 ---
1) 合并 (Low复杂度 | Low风险 | 2-3天)
⚠️ 需澄清: AuthManager是否能承担MFA
2) 拆分边界 (Medium复杂度 | Medium风险 | 4-5天)
⚠️ 需澄清: 基础/高级认证边界? Token验证归谁?
3) 自定义修改
建议: 评估扩展性; 策略模式分离; 定义接口边界
请选择 (1-3): > 2
--- 澄清问答 (第1轮) ---
Q: 基础/高级认证边界?
A: 基础=密码登录+token验证, 高级=MFA+OAuth+SSO
Q: Token验证归谁?
A: 统一由 AuthManager 负责
🔄 重新分析...
✅ 唯一性已确认 | 理由: 边界清晰 - AuthManager(基础+token), UserAuthService(MFA+OAuth+SSO)
============================================================
冲突 2/3 - 第 1 轮 [下一个冲突]
============================================================
```
**Loop Characteristics**: 逐个处理 | 无限轮次(max 10) | 动态问题生成 | Agent重新分析判断唯一性 | ModuleOverlap场景边界澄清
**Key Points**:
- AskUserQuestion: max 4 questions/call, batch if more
- Strategy options: 2-4 strategies + "自定义修改"
- Clarification loop: max 10 rounds, agent判断 uniqueness_confirmed
- Custom conflicts: 记录 overlap_analysis 供后续手动处理
### Phase 4: Apply Modifications

View File

@@ -15,7 +15,6 @@ allowed-tools: Task(*), Read(*), Glob(*)
Orchestrator command that invokes `context-search-agent` to gather comprehensive project context for implementation planning. Generates standardized `context-package.json` with codebase analysis, dependencies, and conflict detection.
**Agent**: `context-search-agent` (`.claude/agents/context-search-agent.md`)
## Core Philosophy
@@ -237,7 +236,10 @@ Task(
Execute complete context-search-agent workflow for implementation planning:
### Phase 1: Initialization & Pre-Analysis
1. **Project State Loading**: Read and parse `.workflow/project.json`. Use its `overview` section as the foundational `project_context`. This is your primary source for architecture, tech stack, and key components. If file doesn't exist, proceed with fresh analysis.
1. **Project State Loading**:
- Read and parse `.workflow/project-tech.json`. Use its `overview` section as the foundational `project_context`. This is your primary source for architecture, tech stack, and key components.
- Read and parse `.workflow/project-guidelines.json`. Load `conventions`, `constraints`, and `learnings` into a `project_guidelines` section.
- If files don't exist, proceed with fresh analysis.
2. **Detection**: Check for existing context-package (early exit if valid)
3. **Foundation**: Initialize CodexLens, get project structure, load docs
4. **Analysis**: Extract keywords, determine scope, classify complexity based on task description and project state
@@ -252,17 +254,19 @@ Execute all discovery tracks:
### Phase 3: Synthesis, Assessment & Packaging
1. Apply relevance scoring and build dependency graph
2. **Synthesize 4-source data**: Merge findings from all sources (archive > docs > code > web). **Prioritize the context from `project.json`** for architecture and tech stack unless code analysis reveals it's outdated.
3. **Populate `project_context`**: Directly use the `overview` from `project.json` to fill the `project_context` section of the output `context-package.json`. Include description, technology_stack, architecture, and key_components.
4. Integrate brainstorm artifacts (if .brainstorming/ exists, read content)
5. Perform conflict detection with risk assessment
6. **Inject historical conflicts** from archive analysis into conflict_detection
7. Generate and validate context-package.json
2. **Synthesize 4-source data**: Merge findings from all sources (archive > docs > code > web). **Prioritize the context from `project-tech.json`** for architecture and tech stack unless code analysis reveals it's outdated.
3. **Populate `project_context`**: Directly use the `overview` from `project-tech.json` to fill the `project_context` section. Include description, technology_stack, architecture, and key_components.
4. **Populate `project_guidelines`**: Load conventions, constraints, and learnings from `project-guidelines.json` into a dedicated section.
5. Integrate brainstorm artifacts (if .brainstorming/ exists, read content)
6. Perform conflict detection with risk assessment
7. **Inject historical conflicts** from archive analysis into conflict_detection
8. Generate and validate context-package.json
## Output Requirements
Complete context-package.json with:
- **metadata**: task_description, keywords, complexity, tech_stack, session_id
- **project_context**: description, technology_stack, architecture, key_components (sourced from `project.json` overview)
- **project_context**: description, technology_stack, architecture, key_components (sourced from `project-tech.json`)
- **project_guidelines**: {conventions, constraints, quality_rules, learnings} (sourced from `project-guidelines.json`)
- **assets**: {documentation[], source_code[], config[], tests[]} with relevance scores
- **dependencies**: {internal[], external[]} with dependency graph
- **brainstorm_artifacts**: {guidance_specification, role_analyses[], synthesis_output} with content
@@ -315,7 +319,8 @@ Refer to `context-search-agent.md` Phase 3.7 for complete `context-package.json`
**Key Sections**:
- **metadata**: Session info, keywords, complexity, tech stack
- **project_context**: Architecture patterns, conventions, tech stack (populated from `project.json` overview)
- **project_context**: Architecture patterns, conventions, tech stack (populated from `project-tech.json`)
- **project_guidelines**: Conventions, constraints, quality rules, learnings (populated from `project-guidelines.json`)
- **assets**: Categorized files with relevance scores (documentation, source_code, config, tests)
- **dependencies**: Internal and external dependency graphs
- **brainstorm_artifacts**: Brainstorm documents with full content (if exists)
@@ -430,7 +435,7 @@ if (historicalConflicts.length > 0 && currentRisk === "low") {
## Notes
- **Detection-first**: Always check for existing package before invoking agent
- **Project.json integration**: Agent reads `.workflow/project.json` as primary source for project context, avoiding redundant analysis
- **Agent autonomy**: Agent handles all discovery logic per `.claude/agents/context-search-agent.md`
- **Dual project file integration**: Agent reads both `.workflow/project-tech.json` (tech analysis) and `.workflow/project-guidelines.json` (user constraints) as primary sources
- **Guidelines injection**: Project guidelines are included in context-package to ensure task generation respects user-defined constraints
- **No redundancy**: This command is a thin orchestrator, all logic in agent
- **Plan-specific**: Use this for implementation planning; brainstorm mode uses direct agent call

View File

@@ -1,11 +1,16 @@
---
name: task-generate-agent
description: Generate implementation plan documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) using action-planning-agent - produces planning artifacts, does NOT execute code implementation
argument-hint: "--session WFS-session-id"
argument-hint: "[-y|--yes] --session WFS-session-id"
examples:
- /workflow:tools:task-generate-agent --session WFS-auth
- /workflow:tools:task-generate-agent -y --session WFS-auth
---
## Auto Mode
When `--yes` or `-y`: Skip user questions, use defaults (no materials, Agent executor, Codex CLI tool).
# Generate Implementation Plan Command
## Overview
@@ -67,9 +72,25 @@ Phase 3: Integration (+1 Coordinator, Multi-Module Only)
**Purpose**: Collect user preferences before task generation to ensure generated tasks match execution expectations.
**User Questions**:
**Auto Mode Check**:
```javascript
AskUserQuestion({
const autoYes = $ARGUMENTS.includes('--yes') || $ARGUMENTS.includes('-y')
if (autoYes) {
console.log(`[--yes] Using defaults: No materials, Agent executor, Codex CLI`)
userConfig = {
supplementaryMaterials: { type: "none", content: [] },
executionMethod: "agent",
preferredCliTool: "codex",
enableResume: true
}
// Skip to Phase 1
}
```
**User Questions** (skipped if autoYes):
```javascript
if (!autoYes) AskUserQuestion({
questions: [
{
question: "Do you have supplementary materials or guidelines to include?",
@@ -104,11 +125,10 @@ AskUserQuestion({
}
]
})
```
**Handle Materials Response**:
**Handle Materials Response** (skipped if autoYes):
```javascript
if (userConfig.materials === "Provide file paths") {
if (!autoYes && userConfig.materials === "Provide file paths") {
// Follow-up question for file paths
const pathsResponse = AskUserQuestion({
questions: [{
@@ -354,19 +374,20 @@ Generate task JSON files for ${module.name} module within workflow session
IMPORTANT: This is PLANNING ONLY - generate task JSONs, NOT implementing code.
IMPORTANT: Generate Task JSONs ONLY. IMPL_PLAN.md and TODO_LIST.md by Phase 3 Coordinator.
CRITICAL: Follow progressive loading strategy in agent specification
CRITICAL: Follow the progressive loading strategy defined in agent specification (load analysis.md files incrementally due to file size)
## MODULE SCOPE
- Module: ${module.name} (${module.type})
- Focus Paths: ${module.paths.join(', ')}
- Task ID Prefix: IMPL-${module.prefix}
- Task Limit: ≤9 tasks
- Other Modules: ${otherModules.join(', ')}
- Task Limit: ≤9 tasks (hard limit for this module)
- Other Modules: ${otherModules.join(', ')} (reference only, do NOT generate tasks for them)
## SESSION PATHS
Input:
- Session Metadata: .workflow/active/{session-id}/workflow-session.json
- Context Package: .workflow/active/{session-id}/.process/context-package.json
Output:
- Task Dir: .workflow/active/{session-id}/.task/
@@ -374,21 +395,93 @@ Output:
Session ID: {session-id}
MCP Capabilities: {exa_code, exa_web, code_index}
## USER CONFIGURATION (from Phase 0)
Execution Method: ${userConfig.executionMethod} // agent|hybrid|cli
Preferred CLI Tool: ${userConfig.preferredCliTool} // codex|gemini|qwen|auto
Supplementary Materials: ${userConfig.supplementaryMaterials}
## CLI TOOL SELECTION
Based on userConfig.executionMethod:
- "agent": No command field in implementation_approach steps
- "hybrid": Add command field to complex steps only (agent handles simple steps)
- "cli": Add command field to ALL implementation_approach steps
CLI Resume Support (MANDATORY for all CLI commands):
- Use --resume parameter to continue from previous task execution
- Read previous task's cliExecutionId from session state
- Format: ccw cli -p "[prompt]" --resume ${previousCliId} --tool ${tool} --mode write
## EXPLORATION CONTEXT (from context-package.exploration_results)
- Load exploration_results from context-package.json
- Filter for ${module.name} module: Use aggregated_insights.critical_files matching ${module.paths.join(', ')}
- Apply module-relevant constraints from aggregated_insights.constraints
- Reference aggregated_insights.all_patterns applicable to ${module.name}
- Use aggregated_insights.all_integration_points for precise modification locations within module scope
- Use conflict_indicators for risk-aware task sequencing
## CONFLICT RESOLUTION CONTEXT (if exists)
- Check context-package.conflict_detection.resolution_file for conflict-resolution.json path
- If exists, load .process/conflict-resolution.json:
- Apply planning_constraints relevant to ${module.name} as task constraints
- Reference resolved_conflicts affecting ${module.name} for implementation approach alignment
- Handle custom_conflicts with explicit task notes
## CROSS-MODULE DEPENDENCIES
- Use placeholder: depends_on: ["CROSS::{module}::{pattern}"]
- Example: depends_on: ["CROSS::B::api-endpoint"]
- For dependencies ON other modules: Use placeholder depends_on: ["CROSS::{module}::{pattern}"]
- Example: depends_on: ["CROSS::B::api-endpoint"] (this module depends on B's api-endpoint task)
- Phase 3 Coordinator resolves to actual task IDs
- For dependencies FROM other modules: Document in task context as "provides_for" annotation
## EXPECTED DELIVERABLES
Task JSON Files (.task/IMPL-${module.prefix}*.json):
- 6-field schema per agent specification
- 6-field schema (id, title, status, context_package_path, meta, context, flow_control)
- Task ID format: IMPL-${module.prefix}1, IMPL-${module.prefix}2, ...
- Quantified requirements with explicit counts
- Artifacts integration from context package (filtered for ${module.name})
- **focus_paths enhanced with exploration critical_files (module-scoped)**
- Flow control with pre_analysis steps (include exploration integration_points analysis)
- **CLI Execution IDs and strategies (MANDATORY)**
- Focus ONLY on ${module.name} module scope
## CLI EXECUTION ID REQUIREMENTS (MANDATORY)
Each task JSON MUST include:
- **cli_execution_id**: Unique ID for CLI execution (format: `{session_id}-IMPL-${module.prefix}{seq}`)
- **cli_execution**: Strategy object based on depends_on:
- No deps → `{ "strategy": "new" }`
- 1 dep (single child) → `{ "strategy": "resume", "resume_from": "parent-cli-id" }`
- 1 dep (multiple children) → `{ "strategy": "fork", "resume_from": "parent-cli-id" }`
- N deps → `{ "strategy": "merge_fork", "merge_from": ["id1", "id2", ...] }`
- Cross-module dep → `{ "strategy": "cross_module_fork", "resume_from": "CROSS::{module}::{pattern}" }`
**CLI Execution Strategy Rules**:
1. **new**: Task has no dependencies - starts fresh CLI conversation
2. **resume**: Task has 1 parent AND that parent has only this child - continues same conversation
3. **fork**: Task has 1 parent BUT parent has multiple children - creates new branch with parent context
4. **merge_fork**: Task has multiple parents - merges all parent contexts into new conversation
5. **cross_module_fork**: Task depends on task from another module - Phase 3 resolves placeholder
**Execution Command Patterns**:
- new: `ccw cli -p "[prompt]" --tool [tool] --mode write --id [cli_execution_id]`
- resume: `ccw cli -p "[prompt]" --resume [resume_from] --tool [tool] --mode write`
- fork: `ccw cli -p "[prompt]" --resume [resume_from] --id [cli_execution_id] --tool [tool] --mode write`
- merge_fork: `ccw cli -p "[prompt]" --resume [merge_from.join(',')] --id [cli_execution_id] --tool [tool] --mode write`
- cross_module_fork: (Phase 3 resolves placeholder, then uses fork pattern)
## QUALITY STANDARDS
Hard Constraints:
- Task count <= 9 for this module (hard limit - coordinate with Phase 3 if exceeded)
- All requirements quantified (explicit counts and enumerated lists)
- Acceptance criteria measurable (include verification commands)
- Artifact references mapped from context package (module-scoped filter)
- Focus paths use absolute paths or clear relative paths from project root
- Cross-module dependencies use CROSS:: placeholder format
## SUCCESS CRITERIA
- Task JSONs saved to .task/ with IMPL-${module.prefix}* naming
- Cross-module dependencies use CROSS:: placeholder format
- Return task count and brief summary
- All task JSONs include cli_execution_id and cli_execution strategy
- Cross-module dependencies use CROSS:: placeholder format consistently
- Focus paths scoped to ${module.paths.join(', ')} only
- Return: task count, task IDs, dependency summary (internal + cross-module)
`
)
);

View File

@@ -1,11 +1,16 @@
---
name: task-generate-tdd
description: Autonomous TDD task generation using action-planning-agent with Red-Green-Refactor cycles, test-first structure, and cycle validation
argument-hint: "--session WFS-session-id"
argument-hint: "[-y|--yes] --session WFS-session-id"
examples:
- /workflow:tools:task-generate-tdd --session WFS-auth
- /workflow:tools:task-generate-tdd -y --session WFS-auth
---
## Auto Mode
When `--yes` or `-y`: Skip user questions, use defaults (no materials, Agent executor).
# Autonomous TDD Task Generation Command
## Overview
@@ -78,44 +83,176 @@ Phase 2: Agent Execution (Document Generation)
## Execution Lifecycle
### Phase 1: Discovery & Context Loading
### Phase 0: User Configuration (Interactive)
**Purpose**: Collect user preferences before TDD task generation to ensure generated tasks match execution expectations and provide necessary supplementary context.
**User Questions**:
```javascript
AskUserQuestion({
questions: [
{
question: "Do you have supplementary materials or guidelines to include?",
header: "Materials",
multiSelect: false,
options: [
{ label: "No additional materials", description: "Use existing context only" },
{ label: "Provide file paths", description: "I'll specify paths to include" },
{ label: "Provide inline content", description: "I'll paste content directly" }
]
},
{
question: "Select execution method for generated TDD tasks:",
header: "Execution",
multiSelect: false,
options: [
{ label: "Agent (Recommended)", description: "Claude agent executes Red-Green-Refactor cycles directly" },
{ label: "Hybrid", description: "Agent orchestrates, calls CLI for complex steps (Red/Green phases)" },
{ label: "CLI Only", description: "All TDD cycles via CLI tools (codex/gemini/qwen)" }
]
},
{
question: "If using CLI, which tool do you prefer?",
header: "CLI Tool",
multiSelect: false,
options: [
{ label: "Codex (Recommended)", description: "Best for TDD Red-Green-Refactor cycles" },
{ label: "Gemini", description: "Best for analysis and large context" },
{ label: "Qwen", description: "Alternative analysis tool" },
{ label: "Auto", description: "Let agent decide per-task" }
]
}
]
})
```
**Handle Materials Response**:
```javascript
if (userConfig.materials === "Provide file paths") {
// Follow-up question for file paths
const pathsResponse = AskUserQuestion({
questions: [{
question: "Enter file paths to include (comma-separated or one per line):",
header: "Paths",
multiSelect: false,
options: [
{ label: "Enter paths", description: "Provide paths in text input" }
]
}]
})
userConfig.supplementaryPaths = parseUserPaths(pathsResponse)
}
```
**Build userConfig**:
```javascript
const userConfig = {
supplementaryMaterials: {
type: "none|paths|inline",
content: [...], // Parsed paths or inline content
},
executionMethod: "agent|hybrid|cli",
preferredCliTool: "codex|gemini|qwen|auto",
enableResume: true // Always enable resume for CLI executions
}
```
**Pass to Agent**: Include `userConfig` in agent prompt for Phase 2.
---
### Phase 1: Context Preparation & Discovery
**Command Responsibility**: Command prepares session paths and metadata, provides to agent for autonomous context loading.
**⚡ Memory-First Rule**: Skip file loading if documents already in conversation memory
**Agent Context Package**:
**📊 Progressive Loading Strategy**: Load context incrementally due to large analysis.md file sizes:
- **Core**: session metadata + context-package.json (always load)
- **Selective**: synthesis_output OR (guidance + relevant role analyses) - NOT all role analyses
- **On-Demand**: conflict resolution (if conflict_risk >= medium), test context
**🛤️ Path Clarity Requirement**: All `focus_paths` prefer absolute paths (e.g., `D:\\project\\src\\module`), or clear relative paths from project root (e.g., `./src/module`)
**Session Path Structure** (Provided by Command to Agent):
```
.workflow/active/WFS-{session-id}/
├── workflow-session.json # Session metadata
├── .process/
│ ├── context-package.json # Context package with artifact catalog
│ ├── test-context-package.json # Test coverage analysis
│ └── conflict-resolution.json # Conflict resolution (if exists)
├── .task/ # Output: Task JSON files
│ ├── IMPL-1.json
│ ├── IMPL-2.json
│ └── ...
├── IMPL_PLAN.md # Output: TDD implementation plan
└── TODO_LIST.md # Output: TODO list with TDD phases
```
**Command Preparation**:
1. **Assemble Session Paths** for agent prompt:
- `session_metadata_path`: `.workflow/active/{session-id}/workflow-session.json`
- `context_package_path`: `.workflow/active/{session-id}/.process/context-package.json`
- `test_context_package_path`: `.workflow/active/{session-id}/.process/test-context-package.json`
- Output directory paths
2. **Provide Metadata** (simple values):
- `session_id`: WFS-{session-id}
- `workflow_type`: "tdd"
- `mcp_capabilities`: {exa_code, exa_web, code_index}
3. **Pass userConfig** from Phase 0
**Agent Context Package** (Agent loads autonomously):
```javascript
{
"session_id": "WFS-[session-id]",
"workflow_type": "tdd",
// Note: CLI tool usage is determined semantically by action-planning-agent based on user's task description
// Core (ALWAYS load)
"session_metadata": {
// If in memory: use cached content
// Else: Load from .workflow/active//{session-id}/workflow-session.json
// Else: Load from workflow-session.json
},
"context_package": {
// If in memory: use cached content
// Else: Load from context-package.json
},
// Selective (load based on progressive strategy)
"brainstorm_artifacts": {
// Loaded from context-package.json → brainstorm_artifacts section
"role_analyses": [
"synthesis_output": {"path": "...", "exists": true}, // Load if exists (highest priority)
"guidance_specification": {"path": "...", "exists": true}, // Load if no synthesis
"role_analyses": [ // Load SELECTIVELY based on task relevance
{
"role": "system-architect",
"files": [{"path": "...", "type": "primary|supplementary"}]
}
],
"guidance_specification": {"path": "...", "exists": true},
"synthesis_output": {"path": "...", "exists": true},
"conflict_resolution": {"path": "...", "exists": true} // if conflict_risk >= medium
]
},
"context_package_path": ".workflow/active//{session-id}/.process/context-package.json",
"context_package": {
// If in memory: use cached content
// Else: Load from .workflow/active//{session-id}/.process/context-package.json
},
"test_context_package_path": ".workflow/active//{session-id}/.process/test-context-package.json",
// On-Demand (load if exists)
"test_context_package": {
// Existing test patterns and coverage analysis
// Load from test-context-package.json
// Contains existing test patterns and coverage analysis
},
"conflict_resolution": {
// Load from conflict-resolution.json if conflict_risk >= medium
// Check context-package.conflict_detection.resolution_file
},
// Capabilities
"mcp_capabilities": {
"codex_lens": true,
"exa_code": true,
"exa_web": true
"exa_web": true,
"code_index": true
},
// User configuration from Phase 0
"user_config": {
// From Phase 0 AskUserQuestion
}
}
```
@@ -124,21 +261,21 @@ Phase 2: Agent Execution (Document Generation)
1. **Load Session Context** (if not in memory)
```javascript
if (!memory.has("workflow-session.json")) {
Read(.workflow/active//{session-id}/workflow-session.json)
Read(.workflow/active/{session-id}/workflow-session.json)
}
```
2. **Load Context Package** (if not in memory)
```javascript
if (!memory.has("context-package.json")) {
Read(.workflow/active//{session-id}/.process/context-package.json)
Read(.workflow/active/{session-id}/.process/context-package.json)
}
```
3. **Load Test Context Package** (if not in memory)
```javascript
if (!memory.has("test-context-package.json")) {
Read(.workflow/active//{session-id}/.process/test-context-package.json)
Read(.workflow/active/{session-id}/.process/test-context-package.json)
}
```
@@ -180,74 +317,84 @@ Phase 2: Agent Execution (Document Generation)
)
```
### Phase 2: Agent Execution (Document Generation)
### Phase 2: Agent Execution (TDD Document Generation)
**Pre-Agent Template Selection** (Command decides path before invoking agent):
```javascript
// Command checks flag and selects template PATH (not content)
const templatePath = hasCliExecuteFlag
? "~/.claude/workflows/cli-templates/prompts/workflow/task-json-cli-mode.txt"
: "~/.claude/workflows/cli-templates/prompts/workflow/task-json-agent-mode.txt";
```
**Purpose**: Generate TDD planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) - planning only, NOT code implementation.
**Agent Invocation**:
```javascript
Task(
subagent_type="action-planning-agent",
run_in_background=false,
description="Generate TDD task JSON and implementation plan",
description="Generate TDD planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md)",
prompt=`
## Execution Context
## TASK OBJECTIVE
Generate TDD implementation planning documents (IMPL_PLAN.md, task JSONs, TODO_LIST.md) for workflow session
**Session ID**: WFS-{session-id}
**Workflow Type**: TDD
**Note**: CLI tool usage is determined semantically from user's task description
IMPORTANT: This is PLANNING ONLY - you are generating planning documents, NOT implementing code.
## Phase 1: Discovery Results (Provided Context)
CRITICAL: Follow the progressive loading strategy (load analysis.md files incrementally due to file size):
- **Core**: session metadata + context-package.json (always)
- **Selective**: synthesis_output OR (guidance + relevant role analyses) - NOT all
- **On-Demand**: conflict resolution (if conflict_risk >= medium), test context
### Session Metadata
{session_metadata_content}
## SESSION PATHS
Input:
- Session Metadata: .workflow/active/{session-id}/workflow-session.json
- Context Package: .workflow/active/{session-id}/.process/context-package.json
- Test Context: .workflow/active/{session-id}/.process/test-context-package.json
### Role Analyses (Enhanced by Synthesis)
{role_analyses_content}
- Includes requirements, design specs, enhancements, and clarifications from synthesis phase
Output:
- Task Dir: .workflow/active/{session-id}/.task/
- IMPL_PLAN: .workflow/active/{session-id}/IMPL_PLAN.md
- TODO_LIST: .workflow/active/{session-id}/TODO_LIST.md
### Artifacts Inventory
- **Guidance Specification**: {guidance_spec_path}
- **Role Analyses**: {role_analyses_list}
## CONTEXT METADATA
Session ID: {session-id}
Workflow Type: TDD
MCP Capabilities: {exa_code, exa_web, code_index}
### Context Package
{context_package_summary}
- Includes conflict_risk assessment
## USER CONFIGURATION (from Phase 0)
Execution Method: ${userConfig.executionMethod} // agent|hybrid|cli
Preferred CLI Tool: ${userConfig.preferredCliTool} // codex|gemini|qwen|auto
Supplementary Materials: ${userConfig.supplementaryMaterials}
### Test Context Package
{test_context_package_summary}
- Existing test patterns, framework config, coverage analysis
## CLI TOOL SELECTION
Based on userConfig.executionMethod:
- "agent": No command field in implementation_approach steps
- "hybrid": Add command field to complex steps only (Red/Green phases recommended for CLI)
- "cli": Add command field to ALL Red-Green-Refactor steps
### Conflict Resolution (Conditional)
If conflict_risk was medium/high, modifications have been applied to:
- **guidance-specification.md**: Design decisions updated to resolve conflicts
- **Role analyses (*.md)**: Recommendations adjusted for compatibility
- **context-package.json**: Marked as "resolved" with conflict IDs
- Conflict resolution results stored in conflict-resolution.json
CLI Resume Support (MANDATORY for all CLI commands):
- Use --resume parameter to continue from previous task execution
- Read previous task's cliExecutionId from session state
- Format: ccw cli -p "[prompt]" --resume [previousCliId] --tool [tool] --mode write
### MCP Analysis Results (Optional)
**Code Structure**: {mcp_code_index_results}
**External Research**: {mcp_exa_research_results}
## EXPLORATION CONTEXT (from context-package.exploration_results)
- Load exploration_results from context-package.json
- Use aggregated_insights.critical_files for focus_paths generation
- Apply aggregated_insights.constraints to acceptance criteria
- Reference aggregated_insights.all_patterns for implementation approach
- Use aggregated_insights.all_integration_points for precise modification locations
- Use conflict_indicators for risk-aware task sequencing
## Phase 2: TDD Document Generation Task
## CONFLICT RESOLUTION CONTEXT (if exists)
- Check context-package.conflict_detection.resolution_file for conflict-resolution.json path
- If exists, load .process/conflict-resolution.json:
- Apply planning_constraints as task constraints (for brainstorm-less workflows)
- Reference resolved_conflicts for implementation approach alignment
- Handle custom_conflicts with explicit task notes
## TEST CONTEXT INTEGRATION
- Load test-context-package.json for existing test patterns and coverage analysis
- Extract test framework configuration (Jest/Pytest/etc.)
- Identify existing test conventions and patterns
- Map coverage gaps to TDD Red phase test targets
## TDD DOCUMENT GENERATION TASK
**Agent Configuration Reference**: All TDD task generation rules, quantification requirements, Red-Green-Refactor cycle structure, quality standards, and execution details are defined in action-planning-agent.
Refer to: @.claude/agents/action-planning-agent.md for:
- TDD Task Decomposition Standards
- Red-Green-Refactor Cycle Requirements
- Quantification Requirements (MANDATORY)
- 5-Field Task JSON Schema
- IMPL_PLAN.md Structure (TDD variant)
- TODO_LIST.md Format
- TDD Execution Flow & Quality Validation
### TDD-Specific Requirements Summary
#### Task Structure Philosophy
@@ -265,31 +412,61 @@ Refer to: @.claude/agents/action-planning-agent.md for:
#### Required Outputs Summary
##### 1. TDD Task JSON Files (.task/IMPL-*.json)
- **Location**: `.workflow/active//{session-id}/.task/`
- **Schema**: 5-field structure with TDD-specific metadata
- **Location**: `.workflow/active/{session-id}/.task/`
- **Schema**: 6-field structure with TDD-specific metadata
- `id, title, status, context_package_path, meta, context, flow_control`
- `meta.tdd_workflow`: true (REQUIRED)
- `meta.max_iterations`: 3 (Green phase test-fix cycle limit)
- `meta.cli_execution_id`: Unique CLI execution ID (format: `{session_id}-{task_id}`)
- `meta.cli_execution`: Strategy object (new|resume|fork|merge_fork)
- `context.tdd_cycles`: Array with quantified test cases and coverage
- `context.focus_paths`: Absolute or clear relative paths (enhanced with exploration critical_files)
- `flow_control.implementation_approach`: Exactly 3 steps with `tdd_phase` field
1. Red Phase (`tdd_phase: "red"`): Write failing tests
2. Green Phase (`tdd_phase: "green"`): Implement to pass tests
3. Refactor Phase (`tdd_phase: "refactor"`): Improve code quality
- CLI tool usage determined semantically (add `command` field when user requests CLI execution)
- `flow_control.pre_analysis`: Include exploration integration_points analysis
- CLI tool usage based on userConfig (add `command` field per executionMethod)
- **Details**: See action-planning-agent.md § TDD Task JSON Generation
##### 2. IMPL_PLAN.md (TDD Variant)
- **Location**: `.workflow/active//{session-id}/IMPL_PLAN.md`
- **Location**: `.workflow/active/{session-id}/IMPL_PLAN.md`
- **Template**: `~/.claude/workflows/cli-templates/prompts/workflow/impl-plan-template.txt`
- **TDD-Specific Frontmatter**: workflow_type="tdd", tdd_workflow=true, feature_count, task_breakdown
- **TDD Implementation Tasks Section**: Feature-by-feature with internal Red-Green-Refactor cycles
- **Context Analysis**: Artifact references and exploration insights
- **Details**: See action-planning-agent.md § TDD Implementation Plan Creation
##### 3. TODO_LIST.md
- **Location**: `.workflow/active//{session-id}/TODO_LIST.md`
- **Location**: `.workflow/active/{session-id}/TODO_LIST.md`
- **Format**: Hierarchical task list with internal TDD phase indicators (Red → Green → Refactor)
- **Status**: ▸ (container), [ ] (pending), [x] (completed)
- **Links**: Task JSON references and summaries
- **Details**: See action-planning-agent.md § TODO List Generation
### CLI EXECUTION ID REQUIREMENTS (MANDATORY)
Each task JSON MUST include:
- **meta.cli_execution_id**: Unique ID for CLI execution (format: `{session_id}-{task_id}`)
- **meta.cli_execution**: Strategy object based on depends_on:
- No deps → `{ "strategy": "new" }`
- 1 dep (single child) → `{ "strategy": "resume", "resume_from": "parent-cli-id" }`
- 1 dep (multiple children) → `{ "strategy": "fork", "resume_from": "parent-cli-id" }`
- N deps → `{ "strategy": "merge_fork", "resume_from": ["id1", "id2", ...] }`
- **Type**: `resume_from: string | string[]` (string for resume/fork, array for merge_fork)
**CLI Execution Strategy Rules**:
1. **new**: Task has no dependencies - starts fresh CLI conversation
2. **resume**: Task has 1 parent AND that parent has only this child - continues same conversation
3. **fork**: Task has 1 parent BUT parent has multiple children - creates new branch with parent context
4. **merge_fork**: Task has multiple parents - merges all parent contexts into new conversation
**Execution Command Patterns**:
- new: `ccw cli -p "[prompt]" --tool [tool] --mode write --id [cli_execution_id]`
- resume: `ccw cli -p "[prompt]" --resume [resume_from] --tool [tool] --mode write`
- fork: `ccw cli -p "[prompt]" --resume [resume_from] --id [cli_execution_id] --tool [tool] --mode write`
- merge_fork: `ccw cli -p "[prompt]" --resume [resume_from.join(',')] --id [cli_execution_id] --tool [tool] --mode write` (resume_from is array)
### Quantification Requirements (MANDATORY)
**Core Rules**:
@@ -311,6 +488,7 @@ Refer to: @.claude/agents/action-planning-agent.md for:
- [ ] Every acceptance criterion includes measurable coverage percentage
- [ ] tdd_cycles array contains test_count and test_cases for each cycle
- [ ] No vague language ("comprehensive", "complete", "thorough")
- [ ] cli_execution_id and cli_execution strategy assigned to each task
### Agent Execution Summary
@@ -326,20 +504,34 @@ Refer to: @.claude/agents/action-planning-agent.md for:
- ✓ Quantification requirements enforced (explicit counts, measurable acceptance, exact targets)
- ✓ Task count ≤18 (hard limit)
- ✓ Each task has meta.tdd_workflow: true
- ✓ Each task has exactly 3 implementation steps with tdd_phase field
-Green phase includes test-fix cycle logic
-Artifact references mapped correctly
-MCP tool integration added
- ✓ Each task has exactly 3 implementation steps with tdd_phase field ("red", "green", "refactor")
-Each task has meta.cli_execution_id and meta.cli_execution strategy
-Green phase includes test-fix cycle logic with max_iterations
-focus_paths are absolute or clear relative paths (from exploration critical_files)
- ✓ Artifact references mapped correctly from context package
- ✓ Exploration context integrated (critical_files, constraints, patterns, integration_points)
- ✓ Conflict resolution context applied (if conflict_risk >= medium)
- ✓ Test context integrated (existing test patterns and coverage analysis)
- ✓ Documents follow TDD template structure
- ✓ CLI tool selection based on userConfig.executionMethod
## Output
## SUCCESS CRITERIA
- All planning documents generated successfully:
- Task JSONs valid and saved to .task/ directory with cli_execution_id
- IMPL_PLAN.md created with complete TDD structure
- TODO_LIST.md generated matching task JSONs
- CLI execution strategies assigned based on task dependencies
- Return completion status with document count and task breakdown summary
Generate all three documents and report completion status:
- TDD task JSON files created: N files (IMPL-*.json)
## OUTPUT SUMMARY
Generate all three documents and report:
- TDD task JSON files created: N files (IMPL-*.json) with cli_execution_id assigned
- TDD cycles configured: N cycles with quantified test cases
- Artifacts integrated: synthesis-spec, guidance-specification, N role analyses
- CLI execution strategies: new/resume/fork/merge_fork assigned per dependency graph
- Artifacts integrated: synthesis-spec/guidance-specification, relevant role analyses
- Exploration context: critical_files, constraints, patterns, integration_points
- Test context integrated: existing patterns and coverage
- MCP enhancements: CodexLens, exa-research
- Conflict resolution: applied (if conflict_risk >= medium)
- Session ready for TDD execution: /workflow:execute
`
)
@@ -347,50 +539,64 @@ Generate all three documents and report completion status:
### Agent Context Passing
**Memory-Aware Context Assembly**:
**Context Delegation Model**: Command provides paths and metadata, agent loads context autonomously using progressive loading strategy.
**Command Provides** (in agent prompt):
```javascript
// Assemble context package for agent
const agentContext = {
session_id: "WFS-[id]",
// Command assembles these simple values and paths for agent
const commandProvides = {
// Session paths
session_metadata_path: ".workflow/active/WFS-{id}/workflow-session.json",
context_package_path: ".workflow/active/WFS-{id}/.process/context-package.json",
test_context_package_path: ".workflow/active/WFS-{id}/.process/test-context-package.json",
output_task_dir: ".workflow/active/WFS-{id}/.task/",
output_impl_plan: ".workflow/active/WFS-{id}/IMPL_PLAN.md",
output_todo_list: ".workflow/active/WFS-{id}/TODO_LIST.md",
// Simple metadata
session_id: "WFS-{id}",
workflow_type: "tdd",
mcp_capabilities: { exa_code: true, exa_web: true, code_index: true },
// Use memory if available, else load
session_metadata: memory.has("workflow-session.json")
? memory.get("workflow-session.json")
: Read(.workflow/active/WFS-[id]/workflow-session.json),
context_package_path: ".workflow/active/WFS-[id]/.process/context-package.json",
context_package: memory.has("context-package.json")
? memory.get("context-package.json")
: Read(".workflow/active/WFS-[id]/.process/context-package.json"),
test_context_package_path: ".workflow/active/WFS-[id]/.process/test-context-package.json",
test_context_package: memory.has("test-context-package.json")
? memory.get("test-context-package.json")
: Read(".workflow/active/WFS-[id]/.process/test-context-package.json"),
// Extract brainstorm artifacts from context package
brainstorm_artifacts: extractBrainstormArtifacts(context_package),
// Load role analyses using paths from context package
role_analyses: brainstorm_artifacts.role_analyses
.flatMap(role => role.files)
.map(file => Read(file.path)),
// Load conflict resolution if exists (prefer new JSON format)
conflict_resolution: context_package.conflict_detection?.resolution_file
? Read(context_package.conflict_detection.resolution_file) // .process/conflict-resolution.json
: (brainstorm_artifacts?.conflict_resolution?.exists
? Read(brainstorm_artifacts.conflict_resolution.path)
: null),
// Optional MCP enhancements
mcp_analysis: executeMcpDiscovery()
// User configuration from Phase 0
user_config: {
supplementaryMaterials: { type: "...", content: [...] },
executionMethod: "agent|hybrid|cli",
preferredCliTool: "codex|gemini|qwen|auto",
enableResume: true
}
}
```
**Agent Loads Autonomously** (progressive loading):
```javascript
// Agent executes progressive loading based on memory state
const agentLoads = {
// Core (ALWAYS load if not in memory)
session_metadata: loadIfNotInMemory(session_metadata_path),
context_package: loadIfNotInMemory(context_package_path),
// Selective (based on progressive strategy)
// Priority: synthesis_output > guidance + relevant_role_analyses
brainstorm_content: loadSelectiveBrainstormArtifacts(context_package),
// On-Demand (load if exists and relevant)
test_context: loadIfExists(test_context_package_path),
conflict_resolution: loadConflictResolution(context_package),
// Optional (if MCP available)
exploration_results: extractExplorationResults(context_package),
external_research: executeMcpResearch() // If needed
}
```
**Progressive Loading Implementation** (agent responsibility):
1. **Check memory first** - skip if already loaded
2. **Load core files** - session metadata + context-package.json
3. **Smart selective loading** - synthesis_output OR (guidance + task-relevant role analyses)
4. **On-demand loading** - test context, conflict resolution (if conflict_risk >= medium)
5. **Extract references** - exploration results, artifact paths from context package
## TDD Task Structure Reference
This section provides quick reference for TDD task JSON structure. For complete implementation details, see the agent invocation prompt in Phase 2 above.
@@ -398,14 +604,31 @@ This section provides quick reference for TDD task JSON structure. For complete
**Quick Reference**:
- Each TDD task contains complete Red-Green-Refactor cycle
- Task ID format: `IMPL-N` (simple) or `IMPL-N.M` (complex subtasks)
- Required metadata: `meta.tdd_workflow: true`, `meta.max_iterations: 3`
- Flow control: Exactly 3 steps with `tdd_phase` field (red, green, refactor)
- Context: `tdd_cycles` array with quantified test cases and coverage
- Required metadata:
- `meta.tdd_workflow: true`
- `meta.max_iterations: 3`
- `meta.cli_execution_id: "{session_id}-{task_id}"`
- `meta.cli_execution: { "strategy": "new|resume|fork|merge_fork", ... }`
- Context: `tdd_cycles` array with quantified test cases and coverage:
```javascript
tdd_cycles: [
{
test_count: 5, // Number of test cases to write
test_cases: ["case1", "case2"], // Enumerated test scenarios
implementation_scope: "...", // Files and functions to implement
expected_coverage: ">=85%" // Coverage target
}
]
```
- Context: `focus_paths` use absolute or clear relative paths
- Flow control: Exactly 3 steps with `tdd_phase` field ("red", "green", "refactor")
- Flow control: `pre_analysis` includes exploration integration_points analysis
- Command field: Added per `userConfig.executionMethod` (agent/hybrid/cli)
- See Phase 2 agent prompt for full schema and requirements
## Output Files Structure
```
.workflow/active//{session-id}/
.workflow/active/{session-id}/
├── IMPL_PLAN.md # Unified plan with TDD Implementation Tasks section
├── TODO_LIST.md # Progress tracking with internal TDD phase indicators
├── .task/
@@ -441,9 +664,9 @@ This section provides quick reference for TDD task JSON structure. For complete
- No circular dependencies allowed
### Task Limits
- Maximum 10 total tasks (simple + subtasks)
- Flat hierarchy (≤5 tasks) or two-level (6-10 tasks with containers)
- Re-scope requirements if >10 tasks needed
- Maximum 18 total tasks (simple + subtasks) - hard limit for TDD workflows
- Flat hierarchy (≤5 tasks) or two-level (6-18 tasks with containers)
- Re-scope requirements if >18 tasks needed
### TDD Workflow Validation
- `meta.tdd_workflow` must be true
@@ -463,7 +686,7 @@ This section provides quick reference for TDD task JSON structure. For complete
### TDD Generation Errors
| Error | Cause | Resolution |
|-------|-------|------------|
| Task count exceeds 10 | Too many features or subtasks | Re-scope requirements or merge features |
| Task count exceeds 18 | Too many features or subtasks | Re-scope requirements or merge features into multiple TDD sessions |
| Missing test framework | No test config | Configure testing first |
| Invalid TDD workflow | Missing tdd_phase or incomplete flow_control | Fix TDD structure in ANALYSIS_RESULTS.md |
| Missing tdd_workflow flag | Task doesn't have meta.tdd_workflow: true | Add TDD workflow metadata |
@@ -521,6 +744,6 @@ IMPL (Green phase) tasks include automatic test-fix cycle:
## Configuration Options
- **meta.max_iterations**: Number of fix attempts (default: 3 for TDD, 5 for test-gen)
- **meta.max_iterations**: Number of fix attempts in Green phase (default: 3)
- **CLI tool usage**: Determined semantically from user's task description via `command` field in implementation_approach

View File

@@ -90,7 +90,7 @@ Template: ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.t
## EXECUTION STEPS
1. Execute Gemini analysis:
ccw cli -p "$(cat ~/.claude/workflows/cli-templates/prompts/test/test-concept-analysis.txt)" --tool gemini --mode write --cd .workflow/active/{test_session_id}/.process
ccw cli -p "..." --tool gemini --mode write --rule test-test-concept-analysis --cd .workflow/active/{test_session_id}/.process
2. Generate TEST_ANALYSIS_RESULTS.md:
Synthesize gemini-test-analysis.md into standardized format for task generation

View File

@@ -14,7 +14,7 @@ allowed-tools: Task(*), Read(*), Glob(*)
Orchestrator command that invokes `test-context-search-agent` to gather comprehensive test coverage context for test generation workflows. Generates standardized `test-context-package.json` with coverage analysis, framework detection, and source implementation context.
**Agent**: `test-context-search-agent` (`.claude/agents/test-context-search-agent.md`)
## Core Philosophy
@@ -89,7 +89,6 @@ Task(
run_in_background=false,
description="Gather test coverage context",
prompt=`
You are executing as test-context-search-agent (.claude/agents/test-context-search-agent.md).
## Execution Mode
**PLAN MODE** (Comprehensive) - Full Phase 1-3 execution
@@ -229,7 +228,7 @@ Refer to `test-context-search-agent.md` Phase 3.2 for complete `test-context-pac
## Notes
- **Detection-first**: Always check for existing test-context-package before invoking agent
- **Agent autonomy**: Agent handles all coverage analysis logic per `.claude/agents/test-context-search-agent.md`
- **No redundancy**: This command is a thin orchestrator, all logic in agent
- **Framework agnostic**: Supports Jest, Mocha, pytest, RSpec, Go testing, etc.
- **Coverage focus**: Primary goal is identifying implementation files without tests

View File

@@ -107,8 +107,6 @@ CRITICAL:
- Follow the progressive loading strategy defined in your agent specification (load context incrementally from memory-first approach)
## AGENT CONFIGURATION REFERENCE
All test task generation rules, schemas, and quality standards are defined in your agent specification:
@.claude/agents/action-planning-agent.md
Refer to your specification for:
- Test Task JSON Schema (6-field structure with test-specific metadata)

View File

@@ -1,10 +1,14 @@
---
name: animation-extract
description: Extract animation and transition patterns from prompt inference and image references for design system documentation
argument-hint: "[--design-id <id>] [--session <id>] [--images "<glob>"] [--focus "<types>"] [--interactive] [--refine]"
argument-hint: "[-y|--yes] [--design-id <id>] [--session <id>] [--images "<glob>"] [--focus "<types>"] [--interactive] [--refine]"
allowed-tools: TodoWrite(*), Read(*), Write(*), Glob(*), Bash(*), AskUserQuestion(*), Task(ui-design-agent)
---
## Auto Mode
When `--yes` or `-y`: Skip all clarification questions, use AI-inferred animation decisions.
# Animation Extraction Command
## Overview

View File

@@ -27,8 +27,8 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Glob(*), Write(*
6. **Phase 10 (ui-assembly)****Attach tasks → Execute → Collapse** → Workflow complete
**Phase Transition Mechanism**:
- **Phase 5 (User Interaction)**: User confirms targets → IMMEDIATELY dispatches Phase 7
- **Phase 7-10 (Autonomous)**: SlashCommand dispatch **ATTACHES** tasks to current workflow
- **Phase 5 (User Interaction)**: User confirms targets → IMMEDIATELY executes Phase 7
- **Phase 7-10 (Autonomous)**: SlashCommand execute **ATTACHES** tasks to current workflow
- **Task Execution**: Orchestrator **EXECUTES** these attached tasks itself
- **Task Collapse**: After tasks complete, collapse them into phase summary
- **Phase Transition**: Automatically execute next phase after collapsing
@@ -36,7 +36,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Bash(*), Glob(*), Write(*
**Auto-Continue Mechanism**: TodoWrite tracks phase status with dynamic task attachment/collapse. After executing all attached tasks, you MUST immediately collapse them, restore phase summary, and execute the next phase. No user intervention required. The workflow is NOT complete until Phase 10 (UI assembly) finishes.
**Task Attachment Model**: SlashCommand dispatch is NOT delegation - it's task expansion. The orchestrator executes these attached tasks itself, not waiting for external completion.
**Task Attachment Model**: SlashCommand execute is NOT delegation - it's task expansion. The orchestrator executes these attached tasks itself, not waiting for external completion.
**Target Type Detection**: Automatically inferred from prompt/targets, or explicitly set via `--target-type`.
@@ -63,26 +63,26 @@ Phase 5: Unified Target Inference
Phase 6: Code Import (Conditional)
└─ Decision (design_source):
├─ code_only | hybrid → Dispatch /workflow:ui-design:import-from-code
├─ code_only | hybrid → Execute /workflow:ui-design:import-from-code
└─ visual_only → Skip to Phase 7
Phase 7: Style Extraction
└─ Decision (needs_visual_supplement):
├─ visual_only OR supplement needed → Dispatch /workflow:ui-design:style-extract
├─ visual_only OR supplement needed → Execute /workflow:ui-design:style-extract
└─ code_only AND style_complete → Use code import
Phase 8: Animation Extraction
└─ Decision (should_extract_animation):
├─ visual_only OR incomplete OR regenerate → Dispatch /workflow:ui-design:animation-extract
├─ visual_only OR incomplete OR regenerate → Execute /workflow:ui-design:animation-extract
└─ code_only AND animation_complete → Use code import
Phase 9: Layout Extraction
└─ Decision (needs_visual_supplement OR NOT layout_complete):
├─ True → Dispatch /workflow:ui-design:layout-extract
├─ True → Execute /workflow:ui-design:layout-extract
└─ False → Use code import
Phase 10: UI Assembly
└─ Dispatch /workflow:ui-design:generate → Workflow complete
└─ Execute /workflow:ui-design:generate → Workflow complete
```
## Core Rules
@@ -92,7 +92,7 @@ Phase 10: UI Assembly
3. **Parse & Pass**: Extract data from each output for next phase
4. **Default to All**: When selecting variants/prototypes, use ALL generated items
5. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
6. **⚠️ CRITICAL: Task Attachment Model** - SlashCommand dispatch **ATTACHES** tasks to current workflow. Orchestrator **EXECUTES** these attached tasks itself, not waiting for external completion. This is NOT delegation - it's task expansion.
6. **⚠️ CRITICAL: Task Attachment Model** - SlashCommand execute **ATTACHES** tasks to current workflow. Orchestrator **EXECUTES** these attached tasks itself, not waiting for external completion. This is NOT delegation - it's task expansion.
7. **⚠️ CRITICAL: DO NOT STOP** - This is a continuous multi-phase workflow. After executing all attached tasks, you MUST immediately collapse them and execute the next phase. Workflow is NOT complete until Phase 10 (UI assembly) finishes.
## Parameter Requirements
@@ -356,7 +356,7 @@ detect_target_type(target_list):
### Phase 6: Code Import & Completeness Assessment (Conditional)
**Step 6.1: Dispatch** - Import design system from code files
**Step 6.1: Execute** - Import design system from code files
```javascript
IF design_source IN ["code_only", "hybrid"]:
@@ -364,7 +364,7 @@ IF design_source IN ["code_only", "hybrid"]:
command = "/workflow:ui-design:import-from-code --design-id \"{design_id}\" --source \"{code_base_path}\""
TRY:
# SlashCommand dispatch ATTACHES import-from-code's tasks to current workflow
# SlashCommand execute ATTACHES import-from-code's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself:
# - Phase 0: Discover and categorize code files
# - Phase 1.1-1.3: Style/Animation/Layout Agent extraction
@@ -469,7 +469,7 @@ IF design_source IN ["code_only", "hybrid"]:
### Phase 7: Style Extraction
**Step 7.1: Dispatch** - Extract style design systems
**Step 7.1: Execute** - Extract style design systems
```javascript
IF design_source == "visual_only" OR needs_visual_supplement:
@@ -479,7 +479,7 @@ IF design_source == "visual_only" OR needs_visual_supplement:
(prompt_text ? "--prompt \"{prompt_text}\" " : "") +
"--variants {style_variants} --interactive"
# SlashCommand dispatch ATTACHES style-extract's tasks to current workflow
# SlashCommand execute ATTACHES style-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(command)
@@ -490,7 +490,7 @@ ELSE:
### Phase 8: Animation Extraction
**Step 8.1: Dispatch** - Extract animation patterns
**Step 8.1: Execute** - Extract animation patterns
```javascript
# Determine if animation extraction is needed
@@ -522,7 +522,7 @@ IF should_extract_animation:
command = " ".join(command_parts)
# SlashCommand dispatch ATTACHES animation-extract's tasks to current workflow
# SlashCommand execute ATTACHES animation-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(command)
@@ -536,7 +536,7 @@ ELSE:
### Phase 9: Layout Extraction
**Step 9.1: Dispatch** - Extract layout templates
**Step 9.1: Execute** - Extract layout templates
```javascript
targets_string = ",".join(inferred_target_list)
@@ -548,7 +548,7 @@ IF (design_source == "visual_only" OR needs_visual_supplement) OR (NOT layout_co
(prompt_text ? "--prompt \"{prompt_text}\" " : "") +
"--targets \"{targets_string}\" --variants {layout_variants} --device-type \"{device_type}\" --interactive"
# SlashCommand dispatch ATTACHES layout-extract's tasks to current workflow
# SlashCommand execute ATTACHES layout-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(command)
@@ -559,7 +559,7 @@ ELSE:
### Phase 10: UI Assembly
**Step 10.1: Dispatch** - Assemble UI prototypes from design tokens and layout templates
**Step 10.1: Execute** - Assemble UI prototypes from design tokens and layout templates
```javascript
command = "/workflow:ui-design:generate --design-id \"{design_id}\"" + (--session ? " --session {session_id}" : "")
@@ -571,7 +571,7 @@ REPORT: " → Pure assembly: Combining layout templates + design tokens"
REPORT: " → Device: {device_type} (from layout templates)"
REPORT: " → Assembly tasks: {total} combinations"
# SlashCommand dispatch ATTACHES generate's tasks to current workflow
# SlashCommand execute ATTACHES generate's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(command)
@@ -596,10 +596,10 @@ TodoWrite({todos: [
// ⚠️ CRITICAL: Dynamic TodoWrite task attachment strategy:
//
// **Key Concept**: SlashCommand dispatch ATTACHES tasks to current workflow.
// **Key Concept**: SlashCommand execute ATTACHES tasks to current workflow.
// Orchestrator EXECUTES these attached tasks itself, not waiting for external completion.
//
// Phase 7-10 SlashCommand Dispatch Pattern (when tasks are attached):
// Phase 7-10 SlashCommand Execute Pattern (when tasks are attached):
// Example - Phase 7 with sub-tasks:
// [
// {"content": "Phase 7: Style Extraction", "status": "in_progress", "activeForm": "Executing style extraction"},

View File

@@ -26,7 +26,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Write(*), Bash(*)
7. Phase 4: Design system integration → **Execute orchestrator task** → Reports completion
**Phase Transition Mechanism**:
- **Task Attachment**: SlashCommand dispatch **ATTACHES** tasks to current workflow
- **Task Attachment**: SlashCommand execute **ATTACHES** tasks to current workflow
- **Task Execution**: Orchestrator **EXECUTES** these attached tasks itself
- **Task Collapse**: After tasks complete, collapse them into phase summary
- **Phase Transition**: Automatically execute next phase after collapsing
@@ -34,7 +34,7 @@ allowed-tools: SlashCommand(*), TodoWrite(*), Read(*), Write(*), Bash(*)
**Auto-Continue Mechanism**: TodoWrite tracks phase status with dynamic task attachment/collapse. After executing all attached tasks, you MUST immediately collapse them, restore phase summary, and execute the next phase. No user intervention required. The workflow is NOT complete until reaching Phase 4.
**Task Attachment Model**: SlashCommand dispatch is NOT delegation - it's task expansion. The orchestrator executes these attached tasks itself, not waiting for external completion.
**Task Attachment Model**: SlashCommand execute is NOT delegation - it's task expansion. The orchestrator executes these attached tasks itself, not waiting for external completion.
## Execution Process
@@ -53,30 +53,30 @@ Phase 0: Parameter Parsing & Input Detection
Phase 0.5: Code Import (Conditional)
└─ Decision (design_source):
├─ hybrid → Dispatch /workflow:ui-design:import-from-code
├─ hybrid → Execute /workflow:ui-design:import-from-code
└─ Other → Skip to Phase 2
Phase 2: Style Extraction
└─ Decision (skip_style):
├─ code_only AND style_complete → Use code import
└─ Otherwise → Dispatch /workflow:ui-design:style-extract
└─ Otherwise → Execute /workflow:ui-design:style-extract
Phase 2.3: Animation Extraction
└─ Decision (skip_animation):
├─ code_only AND animation_complete → Use code import
└─ Otherwise → Dispatch /workflow:ui-design:animation-extract
└─ Otherwise → Execute /workflow:ui-design:animation-extract
Phase 2.5: Layout Extraction
└─ Decision (skip_layout):
├─ code_only AND layout_complete → Use code import
└─ Otherwise → Dispatch /workflow:ui-design:layout-extract
└─ Otherwise → Execute /workflow:ui-design:layout-extract
Phase 3: UI Assembly
└─ Dispatch /workflow:ui-design:generate
└─ Execute /workflow:ui-design:generate
Phase 4: Design System Integration
└─ Decision (session_id):
├─ Provided → Dispatch /workflow:ui-design:update
├─ Provided → Execute /workflow:ui-design:update
└─ Not provided → Standalone completion
```
@@ -86,7 +86,7 @@ Phase 4: Design System Integration
2. **No Preliminary Validation**: Sub-commands handle their own validation
3. **Parse & Pass**: Extract data from each output for next phase
4. **Track Progress**: Update TodoWrite dynamically with task attachment/collapse pattern
5. **⚠️ CRITICAL: Task Attachment Model** - SlashCommand dispatch **ATTACHES** tasks to current workflow. Orchestrator **EXECUTES** these attached tasks itself, not waiting for external completion. This is NOT delegation - it's task expansion.
5. **⚠️ CRITICAL: Task Attachment Model** - SlashCommand execute **ATTACHES** tasks to current workflow. Orchestrator **EXECUTES** these attached tasks itself, not waiting for external completion. This is NOT delegation - it's task expansion.
6. **⚠️ CRITICAL: DO NOT STOP** - This is a continuous multi-phase workflow. After executing all attached tasks, you MUST immediately collapse them and execute the next phase. Workflow is NOT complete until Phase 4.
## Parameter Requirements
@@ -276,7 +276,7 @@ TodoWrite({todos: [
### Phase 0.5: Code Import & Completeness Assessment (Conditional)
**Step 0.5.1: Dispatch** - Import design system from code files
**Step 0.5.1: Execute** - Import design system from code files
```javascript
# Only execute if code files detected
@@ -291,7 +291,7 @@ IF design_source == "hybrid":
"--source \"{code_base_path}\""
TRY:
# SlashCommand dispatch ATTACHES import-from-code's tasks to current workflow
# SlashCommand execute ATTACHES import-from-code's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself:
# - Phase 0: Discover and categorize code files
# - Phase 1.1-1.3: Style/Animation/Layout Agent extraction
@@ -382,7 +382,7 @@ TodoWrite(mark_completed: "Initialize and detect design source",
### Phase 2: Style Extraction
**Step 2.1: Dispatch** - Extract style design system
**Step 2.1: Execute** - Extract style design system
```javascript
# Determine if style extraction needed
@@ -409,7 +409,7 @@ ELSE:
extract_command = " ".join(command_parts)
# SlashCommand dispatch ATTACHES style-extract's tasks to current workflow
# SlashCommand execute ATTACHES style-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(extract_command)
@@ -419,7 +419,7 @@ ELSE:
### Phase 2.3: Animation Extraction
**Step 2.3.1: Dispatch** - Extract animation patterns
**Step 2.3.1: Execute** - Extract animation patterns
```javascript
skip_animation = (design_source == "code_only" AND animation_complete)
@@ -442,7 +442,7 @@ ELSE:
animation_extract_command = " ".join(command_parts)
# SlashCommand dispatch ATTACHES animation-extract's tasks to current workflow
# SlashCommand execute ATTACHES animation-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(animation_extract_command)
@@ -452,7 +452,7 @@ ELSE:
### Phase 2.5: Layout Extraction
**Step 2.5.1: Dispatch** - Extract layout templates
**Step 2.5.1: Execute** - Extract layout templates
```javascript
skip_layout = (design_source == "code_only" AND layout_complete)
@@ -477,7 +477,7 @@ ELSE:
layout_extract_command = " ".join(command_parts)
# SlashCommand dispatch ATTACHES layout-extract's tasks to current workflow
# SlashCommand execute ATTACHES layout-extract's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(layout_extract_command)
@@ -487,13 +487,13 @@ ELSE:
### Phase 3: UI Assembly
**Step 3.1: Dispatch** - Assemble UI prototypes from design tokens and layout templates
**Step 3.1: Execute** - Assemble UI prototypes from design tokens and layout templates
```javascript
REPORT: "🚀 Phase 3: UI Assembly"
generate_command = f"/workflow:ui-design:generate --design-id \"{design_id}\""
# SlashCommand dispatch ATTACHES generate's tasks to current workflow
# SlashCommand execute ATTACHES generate's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(generate_command)
@@ -503,14 +503,14 @@ TodoWrite(mark_completed: "Assemble UI", mark_in_progress: session_id ? "Integra
### Phase 4: Design System Integration
**Step 4.1: Dispatch** - Integrate design system into workflow session
**Step 4.1: Execute** - Integrate design system into workflow session
```javascript
IF session_id:
REPORT: "🚀 Phase 4: Design System Integration"
update_command = f"/workflow:ui-design:update --session {session_id}"
# SlashCommand dispatch ATTACHES update's tasks to current workflow
# SlashCommand execute ATTACHES update's tasks to current workflow
# Orchestrator will EXECUTE these attached tasks itself
SlashCommand(update_command)
@@ -636,10 +636,10 @@ TodoWrite({todos: [
// ⚠️ CRITICAL: Dynamic TodoWrite task attachment strategy:
//
// **Key Concept**: SlashCommand dispatch ATTACHES tasks to current workflow.
// **Key Concept**: SlashCommand execute ATTACHES tasks to current workflow.
// Orchestrator EXECUTES these attached tasks itself, not waiting for external completion.
//
// Phase 2-4 SlashCommand Dispatch Pattern (when tasks are attached):
// Phase 2-4 SlashCommand Execute Pattern (when tasks are attached):
// Example - Phase 2 with sub-tasks:
// [
// {"content": "Phase 0: Initialize and Detect Design Source", "status": "completed", "activeForm": "Initializing"},
@@ -702,7 +702,7 @@ TodoWrite({todos: [
- **Input**: `--images` (glob pattern) and/or `--prompt` (text/file paths) + optional `--session`
- **Output**: Complete design system in `{base_path}/` (style-extraction, layout-extraction, prototypes)
- **Sub-commands Dispatched**:
- **Sub-commands Executeed**:
1. `/workflow:ui-design:import-from-code` (Phase 0.5, conditional - if code files detected)
2. `/workflow:ui-design:style-extract` (Phase 2 - complete design systems)
3. `/workflow:ui-design:animation-extract` (Phase 2.3 - animation tokens)

View File

@@ -1,10 +1,14 @@
---
name: layout-extract
description: Extract structural layout information from reference images or text prompts using Claude analysis with variant generation or refinement mode
argument-hint: [--design-id <id>] [--session <id>] [--images "<glob>"] [--prompt "<desc>"] [--targets "<list>"] [--variants <count>] [--device-type <desktop|mobile|tablet|responsive>] [--interactive] [--refine]
argument-hint: "[-y|--yes] [--design-id <id>] [--session <id>] [--images "<glob>"] [--prompt "<desc>"] [--targets "<list>"] [--variants <count>] [--device-type <desktop|mobile|tablet|responsive>] [--interactive] [--refine]"
allowed-tools: TodoWrite(*), Read(*), Write(*), Glob(*), Bash(*), AskUserQuestion(*), Task(ui-design-agent), mcp__exa__web_search_exa(*)
---
## Auto Mode
When `--yes` or `-y`: Skip all clarification questions, use AI-inferred layout decisions.
# Layout Extraction Command
## Overview

View File

@@ -1,10 +1,14 @@
---
name: style-extract
description: Extract design style from reference images or text prompts using Claude analysis with variant generation or refinement mode
argument-hint: "[--design-id <id>] [--session <id>] [--images "<glob>"] [--prompt "<desc>"] [--variants <count>] [--interactive] [--refine]"
argument-hint: "[-y|--yes] [--design-id <id>] [--session <id>] [--images "<glob>"] [--prompt "<desc>"] [--variants <count>] [--interactive] [--refine]"
allowed-tools: TodoWrite(*), Read(*), Write(*), Glob(*), AskUserQuestion(*)
---
## Auto Mode
When `--yes` or `-y`: Skip all clarification questions, use AI-inferred design decisions.
# Style Extraction Command
## Overview

View File

@@ -0,0 +1,693 @@
# Skill 设计规范 v1.0
> 基于 `software-manual` 和 `copyright-docs` 两个成熟 Skill 的设计模式提炼
---
## 目录
1. [设计理念](#1-设计理念)
2. [目录结构规范](#2-目录结构规范)
3. [核心组件定义](#3-核心组件定义)
4. [SKILL.md 入口规范](#4-skillmd-入口规范)
5. [Phase 阶段设计规范](#5-phase-阶段设计规范)
6. [Specs 规范文件设计](#6-specs-规范文件设计)
7. [Templates 模板设计](#7-templates-模板设计)
8. [Scripts 脚本规范](#8-scripts-脚本规范)
9. [Prompt 工程规范](#9-prompt-工程规范)
10. [质量控制规范](#10-质量控制规范)
11. [最佳实践清单](#11-最佳实践清单)
12. [示例模板](#12-示例模板)
---
## 1. 设计理念
### 1.1 核心原则
| 原则 | 说明 | 实践 |
|------|------|------|
| **阶段化执行** | 复杂任务分解为有序阶段 | 使用 `phases/` 目录,数字前缀控制顺序 |
| **关注点分离** | 逻辑、配置、视图分离 | `phases/`(逻辑) + `specs/`(配置) + `templates/`(视图) |
| **简要返回** | Agent 返回路径+摘要,避免上下文溢出 | 返回 JSON 简要信息,文件存储完整内容 |
| **配置驱动** | 规范作为"配置文件",易于调整行为 | 修改 `specs/` 无需触及 `phases/` |
| **模板复用** | 提取通用片段,确保一致性 | `templates/` 存放可复用内容 |
### 1.2 架构模式
```
┌─────────────────────────────────────────────────────────────────┐
│ Context-Optimized Architecture │
├─────────────────────────────────────────────────────────────────┤
│ │
│ SKILL.md (入口) → 描述目标、定义阶段、链接资源 │
│ ↓ │
│ Phase 1: 收集 → 用户输入 + 自动检测 → config.json │
│ ↓ │
│ Phase 2: 分析 → 并行 Agent → sections/*.md │
│ ↓ │
│ Phase N: 汇总 → 交叉检查 → summary.md │
│ ↓ │
│ Phase N+1: 组装 → 合并文件 → 最终产物 │
│ ↓ │
│ Phase N+2: 迭代 → 用户反馈 → 优化 │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 2. 目录结构规范
### 2.1 标准目录结构
```
[skill-name]/
├── SKILL.md # 【必需】技能入口:元数据 + 架构 + 执行流程
├── phases/ # 【必需】执行阶段 Prompt
│ ├── 01-{first-step}.md # 数字前缀定义顺序
│ ├── 02-{second-step}.md
│ ├── 02.5-{sub-step}.md # 小数点用于插入子步骤
│ └── ...
├── specs/ # 【必需】规范与约束
│ ├── {domain}-requirements.md # 领域特定要求
│ ├── quality-standards.md # 质量标准
│ └── writing-style.md # 写作风格(如适用)
├── templates/ # 【推荐】可复用模板
│ ├── agent-base.md # Agent 基础 Prompt 模板
│ ├── output-shell.{ext} # 输出外壳模板html/md
│ └── css/ # 样式文件(如适用)
├── scripts/ # 【可选】辅助脚本
│ ├── {tool}.py # Python 脚本
│ └── {tool}-runner.md # 脚本使用说明
└── outputs/ # 【运行时】执行产物(不纳入版本控制)
```
### 2.2 命名约定
| 类型 | 规则 | 示例 |
|------|------|------|
| Skill 目录 | 小写-连字符 | `software-manual`, `copyright-docs` |
| Phase 文件 | `NN-{动作}.md` | `01-metadata-collection.md` |
| Spec 文件 | `{领域}-{类型}.md` | `cpcc-requirements.md` |
| Template 文件 | `{用途}-{类型}.{ext}` | `agent-base.md`, `tiddlywiki-shell.html` |
| 输出文件 | `section-{N}-{名称}.md` | `section-2-architecture.md` |
---
## 3. 核心组件定义
### 3.1 组件职责矩阵
| 组件 | 职责 | 内容类型 | 修改频率 |
|------|------|----------|----------|
| `SKILL.md` | 入口 + 编排 | 元数据、架构图、执行流程 | 低(结构稳定) |
| `phases/*.md` | 执行逻辑 | 步骤说明、Prompt、代码示例 | 中(优化迭代) |
| `specs/*.md` | 约束配置 | 规则、标准、检查清单 | 中(需求变更) |
| `templates/*` | 可复用片段 | Prompt 模板、输出格式 | 低(通用稳定) |
| `scripts/*` | 自动化 | Python/JS 脚本 | 高(功能增强) |
### 3.2 组件依赖关系
```mermaid
graph TD
SKILL[SKILL.md] --> P1[phases/01-*]
P1 --> P2[phases/02-*]
P2 --> PN[phases/N-*]
P1 -.->|引用| SPEC[specs/*]
P2 -.->|引用| SPEC
PN -.->|引用| SPEC
P1 -.->|使用| TPL[templates/*]
PN -.->|使用| TPL
P2 -->|调用| SCR[scripts/*]
style SKILL fill:#e1f5fe
style SPEC fill:#fff3e0
style TPL fill:#e8f5e9
style SCR fill:#fce4ec
```
---
## 4. SKILL.md 入口规范
### 4.1 必需结构
```markdown
---
name: {skill-name}
description: {一句话描述}. {触发关键词}. Triggers on "{关键词1}", "{关键词2}".
allowed-tools: Task, AskUserQuestion, Read, Bash, Glob, Grep, Write, {其他MCP工具}
---
# {Skill 标题}
{一段话描述 Skill 的用途和产出}
## Architecture Overview
{ASCII 或 Mermaid 架构图}
## Key Design Principles
1. **原则1**: 说明
2. **原则2**: 说明
...
## Execution Flow
{阶段执行流程图}
## Agent Configuration (如适用)
| Agent | Role | Output File | Focus Areas |
|-------|------|-------------|-------------|
| ... | ... | ... | ... |
## Directory Setup
{工作目录创建代码}
## Output Structure
{输出目录结构}
## Reference Documents
| Document | Purpose |
|----------|---------|
| [phases/01-xxx.md](phases/01-xxx.md) | ... |
| ... | ... |
```
### 4.2 Front Matter 规范
```yaml
---
name: skill-name # 必需Skill 唯一标识
description: | # 必需:描述 + 触发词
Generate XXX documents.
Triggers on "keyword1", "keyword2".
allowed-tools: | # 必需:允许使用的工具
Task, AskUserQuestion, Read, Bash,
Glob, Grep, Write, mcp__chrome__*
---
```
---
## 5. Phase 阶段设计规范
### 5.1 Phase 文件结构
```markdown
# Phase N: {阶段名称}
{一句话描述此阶段目标}
## Objective
{详细目标说明}
- 目标1
- 目标2
## Execution Steps
### Step 1: {步骤名称}
{代码或说明}
### Step 2: {步骤名称}
{代码或说明}
## Output
- **File**: `{输出文件名}`
- **Location**: `{输出路径}`
- **Format**: {JSON/Markdown/HTML}
## Next Phase
Proceed to [Phase N+1: xxx](0N+1-xxx.md) with the generated {产出}.
```
### 5.2 Phase 类型
| 类型 | 特点 | 示例 |
|------|------|------|
| **收集型** | 用户交互 + 自动检测 | `01-requirements-discovery.md` |
| **探索型** | 代码分析 + 结构识别 | `02-project-exploration.md` |
| **并行型** | 多 Agent 并行执行 | `03-parallel-analysis.md` |
| **汇总型** | 交叉检查 + 质量验证 | `03.5-consolidation.md` |
| **组装型** | 合并产出 + 格式化 | `04-document-assembly.md` |
| **迭代型** | 用户反馈 + 优化 | `05-iterative-refinement.md` |
### 5.3 Phase 编号规则
```
01-xxx.md # 主阶段
02-xxx.md # 主阶段
02.5-xxx.md # 子阶段(插入 02 和 03 之间)
03-xxx.md # 主阶段
```
---
## 6. Specs 规范文件设计
### 6.1 Specs 类型
| 类型 | 用途 | 示例 |
|------|------|------|
| **领域要求** | 领域特定合规性 | `cpcc-requirements.md` |
| **质量标准** | 输出质量评估 | `quality-standards.md` |
| **写作风格** | 内容风格指南 | `writing-style.md` |
| **模板规范** | 输出格式定义 | `html-template.md` |
### 6.2 Specs 结构模板
```markdown
# {规范名称}
{规范用途说明}
## When to Use
| Phase | Usage | Section |
|-------|-------|---------|
| Phase N | {使用场景} | {引用章节} |
| ... | ... | ... |
---
## Requirements
### Category 1
- [ ] 检查项1
- [ ] 检查项2
### Category 2
| 项目 | 要求 | 检查方式 |
|------|------|----------|
| ... | ... | ... |
## Validation Function
{验证函数代码}
## Error Handling
| Error | Recovery |
|-------|----------|
| ... | ... |
```
### 6.3 质量标准示例结构
```markdown
# Quality Standards
## Quality Dimensions
### 1. Completeness (25%)
{评分标准}
### 2. Consistency (25%)
{评分标准}
### 3. Depth (25%)
{评分标准}
### 4. Readability (25%)
{评分标准}
## Quality Gates
| Gate | Threshold | Action |
|------|-----------|--------|
| Pass | ≥ 80% | 继续执行 |
| Review | 60-79% | 处理警告后继续 |
| Fail | < 60% | 必须修复 |
## Issue Classification
### Errors (Must Fix)
- ...
### Warnings (Should Fix)
- ...
### Info (Nice to Have)
- ...
```
---
## 7. Templates 模板设计
### 7.1 Agent 基础模板
```markdown
# Agent Base Template
## 通用提示词结构
[ROLE] 你是{角色},专注于{职责}。
[TASK]
{任务描述}
- 输出: {output_path}
- 格式: {format}
- 范围: {scope}
[CONSTRAINTS]
- 约束1
- 约束2
[OUTPUT_FORMAT]
1. 直接写入文件
2. 返回 JSON 简要信息
[QUALITY_CHECKLIST]
- [ ] 检查项1
- [ ] 检查项2
## 变量说明
| 变量 | 来源 | 示例 |
|------|------|------|
| {output_dir} | Phase 1 | .workflow/.scratchpad/xxx |
| ... | ... | ... |
## Agent 配置映射
{AGENT_ROLES, AGENT_SECTIONS, AGENT_FILES, AGENT_FOCUS}
```
### 7.2 输出模板规范
```html
<!-- output-shell.html 示例 -->
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>{{title}}</title>
<style>
/* 内嵌 CSS */
{{styles}}
</style>
</head>
<body>
<div id="app">
{{content}}
</div>
<script>
/* 内嵌 JS */
{{scripts}}
</script>
</body>
</html>
```
### 7.3 占位符规范
| 占位符格式 | 用途 | 示例 |
|------------|------|------|
| `{{variable}}` | 简单变量替换 | `{{title}}` |
| `${variable}` | JavaScript 模板字符串 | `${workDir}` |
| `{placeholder}` | Prompt 占位 | `{intro}`, `{diagram}` |
---
## 8. Scripts 脚本规范
### 8.1 脚本类型
| 类型 | 用途 | 命名 |
|------|------|------|
| **提取器** | 从代码提取信息 | `extract_*.py` |
| **组装器** | 合并/转换文件 | `assemble_*.py` |
| **验证器** | 检查合规性 | `validate_*.py` |
| **辅助器** | 工具函数 | `*_helper.py` |
### 8.2 脚本使用说明文件
每个脚本应有对应的 `.md` 说明文件:
```markdown
# {Script Name} Runner
## Purpose
{脚本用途}
## Usage
{命令行使用方式}
## Parameters
| 参数 | 说明 | 默认值 |
|------|------|--------|
| ... | ... | ... |
## Output
{输出说明}
## Example
{使用示例}
```
---
## 9. Prompt 工程规范
### 9.1 Prompt 结构标准
```
[ROLE] {角色定义}
[PROJECT CONTEXT]
项目类型: {type}
语言: {language}
名称: {name}
[TASK]
{任务描述}
输出: {output_path}
[INPUT]
- 配置: {config_path}
- 扫描路径: {scan_paths}
[CONTENT REQUIREMENTS]
- 标题层级: # ## ### (最多3级)
- 代码块: ```language ... ``` (必须标注语言)
- 表格: | col1 | col2 | 格式
- 列表: 有序 1. 2. 3. / 无序 - - -
[FOCUS]
{重点关注项}
[OUTPUT FORMAT]
{输出格式说明}
[RETURN JSON]
{返回结构}
```
### 9.2 效率优化原则
| 原则 | Before (冗余) | After (精简) |
|------|---------------|--------------|
| **角色简化** | "你是一个专业的系统架构师,具有丰富的软件设计经验..." | `[ROLE] 系统架构师,专注于分层设计和模块依赖` |
| **模板驱动** | "请按照以下格式输出: 首先写一个二级标题..." | `[TEMPLATE] ## 2. 标题 {content}` |
| **焦点明确** | "分析项目的各个方面,包括架构、模块、依赖等" | `[FOCUS] 1. 分层 2. 模块 3. 依赖 4. 数据流` |
| **返回简洁** | "请返回详细的分析结果,包括所有发现的问题..." | `[RETURN] {"status":"completed","output_file":"xxx.md","summary":"<50字"}` |
### 9.3 Agent 返回格式标准
```typescript
interface AgentReturn {
status: "completed" | "partial" | "failed";
output_file: string; // 输出文件路径
summary: string; // 最多 50 字摘要
cross_module_notes?: string[]; // 跨模块备注
stats?: { // 统计信息
diagrams?: number;
words?: number;
};
screenshots_needed?: Array<{ // 截图需求(如适用)
id: string;
url: string;
description: string;
}>;
}
```
---
## 10. 质量控制规范
### 10.1 质量维度
| 维度 | 权重 | 检查项 |
|------|------|--------|
| **完整性** | 25% | 所有必需章节存在且有实质内容 |
| **一致性** | 25% | 术语、格式、风格统一 |
| **深度** | 25% | 内容详尽、示例充分 |
| **可读性** | 25% | 结构清晰、语言简洁 |
### 10.2 质量门控
```javascript
const QUALITY_GATES = {
pass: { threshold: 80, action: "继续执行" },
review: { threshold: 60, action: "处理警告后继续" },
fail: { threshold: 0, action: "必须修复后重试" }
};
```
### 10.3 问题分类
| 级别 | 前缀 | 含义 | 处理方式 |
|------|------|------|----------|
| **Error** | E | 阻塞性问题 | 必须修复 |
| **Warning** | W | 影响质量 | 建议修复 |
| **Info** | I | 可改进项 | 可选修复 |
### 10.4 自动化检查函数模板
```javascript
function runQualityChecks(workDir) {
const results = {
completeness: checkCompleteness(workDir),
consistency: checkConsistency(workDir),
depth: checkDepth(workDir),
readability: checkReadability(workDir)
};
results.overall = Object.values(results).reduce((a, b) => a + b) / 4;
return {
score: results.overall,
gate: results.overall >= 80 ? 'pass' :
results.overall >= 60 ? 'review' : 'fail',
details: results
};
}
```
---
## 11. 最佳实践清单
### 11.1 Skill 设计
- [ ] **单一职责**: 每个 Skill 专注一个领域
- [ ] **清晰入口**: SKILL.md 完整描述目标和流程
- [ ] **阶段分解**: 复杂任务拆分为 3-7 个阶段
- [ ] **顺序命名**: 使用数字前缀控制执行顺序
### 11.2 Phase 设计
- [ ] **明确目标**: 每个 Phase 有清晰的输入输出
- [ ] **独立可测**: 每个 Phase 可单独调试
- [ ] **链接下一步**: 明确说明后续阶段
### 11.3 Prompt 设计
- [ ] **角色明确**: 使用 `[ROLE]` 定义 Agent 身份
- [ ] **任务具体**: 使用 `[TASK]` 明确执行目标
- [ ] **约束清晰**: 使用 `[CONSTRAINTS]` 定义边界
- [ ] **返回简洁**: Agent 返回路径+摘要,非完整内容
### 11.4 质量控制
- [ ] **规范驱动**: 使用 `specs/` 定义可验证的标准
- [ ] **汇总检查**: 设置 Consolidation 阶段交叉验证
- [ ] **问题分级**: 区分 Error/Warning/Info
- [ ] **迭代优化**: 支持用户反馈循环
---
## 12. 示例模板
### 12.1 新 Skill 快速启动模板
```bash
# 创建 Skill 目录结构
mkdir -p my-skill/{phases,specs,templates,scripts}
# 创建核心文件
touch my-skill/SKILL.md
touch my-skill/phases/{01-collection,02-analysis,03-assembly}.md
touch my-skill/specs/{requirements,quality-standards}.md
touch my-skill/templates/agent-base.md
```
### 12.2 SKILL.md 最小模板
```markdown
---
name: my-skill
description: Generate XXX. Triggers on "keyword1", "keyword2".
allowed-tools: Task, AskUserQuestion, Read, Bash, Glob, Grep, Write
---
# My Skill
Generate XXX through multi-phase analysis.
## Execution Flow
1. Phase 1: Collection → config.json
2. Phase 2: Analysis → sections/*.md
3. Phase 3: Assembly → output.md
## Reference Documents
| Document | Purpose |
|----------|---------|
| [phases/01-collection.md](phases/01-collection.md) | 信息收集 |
| [phases/02-analysis.md](phases/02-analysis.md) | 代码分析 |
| [phases/03-assembly.md](phases/03-assembly.md) | 文档组装 |
```
---
## 附录 A: 设计对比
| 设计点 | software-manual | copyright-docs |
|--------|-----------------|----------------|
| 阶段数 | 6 | 5 |
| 并行 Agent | 6 | 6 |
| 输出格式 | HTML | Markdown |
| 质量检查 | 4 维度评分 | CPCC 合规检查 |
| 截图支持 | Chrome MCP | 无 |
| 迭代优化 | 用户反馈循环 | 合规验证循环 |
## 附录 B: 工具依赖
| 工具 | 用途 | 适用 Skill |
|------|------|------------|
| `Task` | 启动子 Agent | 所有 |
| `AskUserQuestion` | 用户交互 | 所有 |
| `Read/Write/Glob/Grep` | 文件操作 | 所有 |
| `Bash` | 脚本执行 | 需要自动化 |
| `mcp__chrome__*` | 浏览器截图 | UI 相关 |
---
*规范版本: 1.0*
*基于: software-manual, copyright-docs*
*最后更新: 2026-01-03*

View File

@@ -0,0 +1,584 @@
# Mermaid Utilities Library
Shared utilities for generating and validating Mermaid diagrams across all analysis skills.
## Sanitization Functions
### sanitizeId
Convert any text to a valid Mermaid node ID.
```javascript
/**
* Sanitize text to valid Mermaid node ID
* - Only alphanumeric and underscore allowed
* - Cannot start with number
* - Truncates to 50 chars max
*
* @param {string} text - Input text
* @returns {string} - Valid Mermaid ID
*/
function sanitizeId(text) {
if (!text) return '_empty';
return text
.replace(/[^a-zA-Z0-9_\u4e00-\u9fa5]/g, '_') // Allow Chinese chars
.replace(/^[0-9]/, '_$&') // Prefix number with _
.replace(/_+/g, '_') // Collapse multiple _
.substring(0, 50); // Limit length
}
// Examples:
// sanitizeId("User-Service") → "User_Service"
// sanitizeId("3rdParty") → "_3rdParty"
// sanitizeId("用户服务") → "用户服务"
```
### escapeLabel
Escape special characters for Mermaid labels.
```javascript
/**
* Escape special characters in Mermaid labels
* Uses HTML entity encoding for problematic chars
*
* @param {string} text - Label text
* @returns {string} - Escaped label
*/
function escapeLabel(text) {
if (!text) return '';
return text
.replace(/"/g, "'") // Avoid quote issues
.replace(/\(/g, '#40;') // (
.replace(/\)/g, '#41;') // )
.replace(/\{/g, '#123;') // {
.replace(/\}/g, '#125;') // }
.replace(/\[/g, '#91;') // [
.replace(/\]/g, '#93;') // ]
.replace(/</g, '#60;') // <
.replace(/>/g, '#62;') // >
.replace(/\|/g, '#124;') // |
.substring(0, 80); // Limit length
}
// Examples:
// escapeLabel("Process(data)") → "Process#40;data#41;"
// escapeLabel("Check {valid?}") → "Check #123;valid?#125;"
```
### sanitizeType
Sanitize type names for class diagrams.
```javascript
/**
* Sanitize type names for Mermaid classDiagram
* Removes generics syntax that causes issues
*
* @param {string} type - Type name
* @returns {string} - Sanitized type
*/
function sanitizeType(type) {
if (!type) return 'any';
return type
.replace(/<[^>]*>/g, '') // Remove generics <T>
.replace(/\|/g, ' or ') // Union types
.replace(/&/g, ' and ') // Intersection types
.replace(/\[\]/g, 'Array') // Array notation
.substring(0, 30);
}
// Examples:
// sanitizeType("Array<string>") → "Array"
// sanitizeType("string | number") → "string or number"
```
## Diagram Generation Functions
### generateFlowchartNode
Generate a flowchart node with proper shape.
```javascript
/**
* Generate flowchart node with shape
*
* @param {string} id - Node ID
* @param {string} label - Display label
* @param {string} type - Node type: start|end|process|decision|io|subroutine
* @returns {string} - Mermaid node definition
*/
function generateFlowchartNode(id, label, type = 'process') {
const safeId = sanitizeId(id);
const safeLabel = escapeLabel(label);
const shapes = {
start: `${safeId}(["${safeLabel}"])`, // Stadium shape
end: `${safeId}(["${safeLabel}"])`, // Stadium shape
process: `${safeId}["${safeLabel}"]`, // Rectangle
decision: `${safeId}{"${safeLabel}"}`, // Diamond
io: `${safeId}[/"${safeLabel}"/]`, // Parallelogram
subroutine: `${safeId}[["${safeLabel}"]]`, // Subroutine
database: `${safeId}[("${safeLabel}")]`, // Cylinder
manual: `${safeId}[/"${safeLabel}"\\]` // Trapezoid
};
return shapes[type] || shapes.process;
}
```
### generateFlowchartEdge
Generate a flowchart edge with optional label.
```javascript
/**
* Generate flowchart edge
*
* @param {string} from - Source node ID
* @param {string} to - Target node ID
* @param {string} label - Edge label (optional)
* @param {string} style - Edge style: solid|dashed|thick
* @returns {string} - Mermaid edge definition
*/
function generateFlowchartEdge(from, to, label = '', style = 'solid') {
const safeFrom = sanitizeId(from);
const safeTo = sanitizeId(to);
const safeLabel = label ? `|"${escapeLabel(label)}"|` : '';
const arrows = {
solid: '-->',
dashed: '-.->',
thick: '==>'
};
const arrow = arrows[style] || arrows.solid;
return ` ${safeFrom} ${arrow}${safeLabel} ${safeTo}`;
}
```
### generateAlgorithmFlowchart (Enhanced)
Generate algorithm flowchart with branch/loop support.
```javascript
/**
* Generate algorithm flowchart with decision support
*
* @param {Object} algorithm - Algorithm definition
* - name: Algorithm name
* - inputs: [{name, type}]
* - outputs: [{name, type}]
* - steps: [{id, description, type, next: [id], conditions: [text]}]
* @returns {string} - Complete Mermaid flowchart
*/
function generateAlgorithmFlowchart(algorithm) {
let mermaid = 'flowchart TD\n';
// Start node
mermaid += ` START(["开始: ${escapeLabel(algorithm.name)}"])\n`;
// Input node (if has inputs)
if (algorithm.inputs?.length > 0) {
const inputList = algorithm.inputs.map(i => `${i.name}: ${i.type}`).join(', ');
mermaid += ` INPUT[/"输入: ${escapeLabel(inputList)}"/]\n`;
mermaid += ` START --> INPUT\n`;
}
// Process nodes
const steps = algorithm.steps || [];
for (const step of steps) {
const nodeId = sanitizeId(step.id || `STEP_${step.step_num}`);
if (step.type === 'decision') {
mermaid += ` ${nodeId}{"${escapeLabel(step.description)}"}\n`;
} else if (step.type === 'io') {
mermaid += ` ${nodeId}[/"${escapeLabel(step.description)}"/]\n`;
} else if (step.type === 'loop_start') {
mermaid += ` ${nodeId}[["循环: ${escapeLabel(step.description)}"]]\n`;
} else {
mermaid += ` ${nodeId}["${escapeLabel(step.description)}"]\n`;
}
}
// Output node
const outputDesc = algorithm.outputs?.map(o => o.name).join(', ') || '结果';
mermaid += ` OUTPUT[/"输出: ${escapeLabel(outputDesc)}"/]\n`;
mermaid += ` END_(["结束"])\n`;
// Connect first step to input/start
if (steps.length > 0) {
const firstStep = sanitizeId(steps[0].id || 'STEP_1');
if (algorithm.inputs?.length > 0) {
mermaid += ` INPUT --> ${firstStep}\n`;
} else {
mermaid += ` START --> ${firstStep}\n`;
}
}
// Connect steps based on next array
for (const step of steps) {
const nodeId = sanitizeId(step.id || `STEP_${step.step_num}`);
if (step.next && step.next.length > 0) {
step.next.forEach((nextId, index) => {
const safeNextId = sanitizeId(nextId);
const condition = step.conditions?.[index];
if (condition) {
mermaid += ` ${nodeId} -->|"${escapeLabel(condition)}"| ${safeNextId}\n`;
} else {
mermaid += ` ${nodeId} --> ${safeNextId}\n`;
}
});
} else if (!step.type?.includes('end')) {
// Default: connect to next step or output
const stepIndex = steps.indexOf(step);
if (stepIndex < steps.length - 1) {
const nextStep = sanitizeId(steps[stepIndex + 1].id || `STEP_${stepIndex + 2}`);
mermaid += ` ${nodeId} --> ${nextStep}\n`;
} else {
mermaid += ` ${nodeId} --> OUTPUT\n`;
}
}
}
// Connect output to end
mermaid += ` OUTPUT --> END_\n`;
return mermaid;
}
```
## Diagram Validation
### validateMermaidSyntax
Comprehensive Mermaid syntax validation.
```javascript
/**
* Validate Mermaid diagram syntax
*
* @param {string} content - Mermaid diagram content
* @returns {Object} - {valid: boolean, issues: string[]}
*/
function validateMermaidSyntax(content) {
const issues = [];
// Check 1: Diagram type declaration
if (!content.match(/^(graph|flowchart|classDiagram|sequenceDiagram|stateDiagram|erDiagram|gantt|pie|mindmap)/m)) {
issues.push('Missing diagram type declaration');
}
// Check 2: Undefined values
if (content.includes('undefined') || content.includes('null')) {
issues.push('Contains undefined/null values');
}
// Check 3: Invalid arrow syntax
if (content.match(/-->\s*-->/)) {
issues.push('Double arrow syntax error');
}
// Check 4: Unescaped special characters in labels
const labelMatches = content.match(/\["[^"]*[(){}[\]<>][^"]*"\]/g);
if (labelMatches?.some(m => !m.includes('#'))) {
issues.push('Unescaped special characters in labels');
}
// Check 5: Node ID starts with number
if (content.match(/\n\s*[0-9][a-zA-Z0-9_]*[\[\({]/)) {
issues.push('Node ID cannot start with number');
}
// Check 6: Nested subgraph syntax error
if (content.match(/subgraph\s+\S+\s*\n[^e]*subgraph/)) {
// This is actually valid, only flag if brackets don't match
const subgraphCount = (content.match(/subgraph/g) || []).length;
const endCount = (content.match(/\bend\b/g) || []).length;
if (subgraphCount > endCount) {
issues.push('Unbalanced subgraph/end blocks');
}
}
// Check 7: Invalid arrow type for diagram type
const diagramType = content.match(/^(graph|flowchart|classDiagram|sequenceDiagram)/m)?.[1];
if (diagramType === 'classDiagram' && content.includes('-->|')) {
issues.push('Invalid edge label syntax for classDiagram');
}
// Check 8: Empty node labels
if (content.match(/\[""\]|\{\}|\(\)/)) {
issues.push('Empty node labels detected');
}
// Check 9: Reserved keywords as IDs
const reserved = ['end', 'graph', 'subgraph', 'direction', 'class', 'click'];
for (const keyword of reserved) {
const pattern = new RegExp(`\\n\\s*${keyword}\\s*[\\[\\(\\{]`, 'i');
if (content.match(pattern)) {
issues.push(`Reserved keyword "${keyword}" used as node ID`);
}
}
// Check 10: Line length (Mermaid has issues with very long lines)
const lines = content.split('\n');
for (let i = 0; i < lines.length; i++) {
if (lines[i].length > 500) {
issues.push(`Line ${i + 1} exceeds 500 characters`);
}
}
return {
valid: issues.length === 0,
issues
};
}
```
### validateDiagramDirectory
Validate all diagrams in a directory.
```javascript
/**
* Validate all Mermaid diagrams in directory
*
* @param {string} diagramDir - Path to diagrams directory
* @returns {Object[]} - Array of {file, valid, issues}
*/
function validateDiagramDirectory(diagramDir) {
const files = Glob(`${diagramDir}/*.mmd`);
const results = [];
for (const file of files) {
const content = Read(file);
const validation = validateMermaidSyntax(content);
results.push({
file: file.split('/').pop(),
path: file,
valid: validation.valid,
issues: validation.issues,
lines: content.split('\n').length
});
}
return results;
}
```
## Class Diagram Utilities
### generateClassDiagram
Generate class diagram with relationships.
```javascript
/**
* Generate class diagram from analysis data
*
* @param {Object} analysis - Data structure analysis
* - entities: [{name, type, properties, methods}]
* - relationships: [{from, to, type, label}]
* @param {Object} options - Generation options
* - maxClasses: Max classes to include (default: 15)
* - maxProperties: Max properties per class (default: 8)
* - maxMethods: Max methods per class (default: 6)
* @returns {string} - Mermaid classDiagram
*/
function generateClassDiagram(analysis, options = {}) {
const maxClasses = options.maxClasses || 15;
const maxProperties = options.maxProperties || 8;
const maxMethods = options.maxMethods || 6;
let mermaid = 'classDiagram\n';
const entities = (analysis.entities || []).slice(0, maxClasses);
// Generate classes
for (const entity of entities) {
const className = sanitizeId(entity.name);
mermaid += ` class ${className} {\n`;
// Properties
for (const prop of (entity.properties || []).slice(0, maxProperties)) {
const vis = {public: '+', private: '-', protected: '#'}[prop.visibility] || '+';
const type = sanitizeType(prop.type);
mermaid += ` ${vis}${type} ${prop.name}\n`;
}
// Methods
for (const method of (entity.methods || []).slice(0, maxMethods)) {
const vis = {public: '+', private: '-', protected: '#'}[method.visibility] || '+';
const params = (method.params || []).map(p => p.name).join(', ');
const returnType = sanitizeType(method.returnType || 'void');
mermaid += ` ${vis}${method.name}(${params}) ${returnType}\n`;
}
mermaid += ' }\n';
// Add stereotype if applicable
if (entity.type === 'interface') {
mermaid += ` <<interface>> ${className}\n`;
} else if (entity.type === 'abstract') {
mermaid += ` <<abstract>> ${className}\n`;
}
}
// Generate relationships
const arrows = {
inheritance: '--|>',
implementation: '..|>',
composition: '*--',
aggregation: 'o--',
association: '-->',
dependency: '..>'
};
for (const rel of (analysis.relationships || [])) {
const from = sanitizeId(rel.from);
const to = sanitizeId(rel.to);
const arrow = arrows[rel.type] || '-->';
const label = rel.label ? ` : ${escapeLabel(rel.label)}` : '';
// Only include if both entities exist
if (entities.some(e => sanitizeId(e.name) === from) &&
entities.some(e => sanitizeId(e.name) === to)) {
mermaid += ` ${from} ${arrow} ${to}${label}\n`;
}
}
return mermaid;
}
```
## Sequence Diagram Utilities
### generateSequenceDiagram
Generate sequence diagram from scenario.
```javascript
/**
* Generate sequence diagram from scenario
*
* @param {Object} scenario - Sequence scenario
* - name: Scenario name
* - actors: [{id, name, type}]
* - messages: [{from, to, description, type}]
* - blocks: [{type, condition, messages}]
* @returns {string} - Mermaid sequenceDiagram
*/
function generateSequenceDiagram(scenario) {
let mermaid = 'sequenceDiagram\n';
// Title
if (scenario.name) {
mermaid += ` title ${escapeLabel(scenario.name)}\n`;
}
// Participants
for (const actor of scenario.actors || []) {
const actorType = actor.type === 'external' ? 'actor' : 'participant';
mermaid += ` ${actorType} ${sanitizeId(actor.id)} as ${escapeLabel(actor.name)}\n`;
}
mermaid += '\n';
// Messages
for (const msg of scenario.messages || []) {
const from = sanitizeId(msg.from);
const to = sanitizeId(msg.to);
const desc = escapeLabel(msg.description);
let arrow;
switch (msg.type) {
case 'async': arrow = '->>'; break;
case 'response': arrow = '-->>'; break;
case 'create': arrow = '->>+'; break;
case 'destroy': arrow = '->>-'; break;
case 'self': arrow = '->>'; break;
default: arrow = '->>';
}
mermaid += ` ${from}${arrow}${to}: ${desc}\n`;
// Activation
if (msg.activate) {
mermaid += ` activate ${to}\n`;
}
if (msg.deactivate) {
mermaid += ` deactivate ${from}\n`;
}
// Notes
if (msg.note) {
mermaid += ` Note over ${to}: ${escapeLabel(msg.note)}\n`;
}
}
// Blocks (loops, alt, opt)
for (const block of scenario.blocks || []) {
switch (block.type) {
case 'loop':
mermaid += ` loop ${escapeLabel(block.condition)}\n`;
break;
case 'alt':
mermaid += ` alt ${escapeLabel(block.condition)}\n`;
break;
case 'opt':
mermaid += ` opt ${escapeLabel(block.condition)}\n`;
break;
}
for (const m of block.messages || []) {
mermaid += ` ${sanitizeId(m.from)}->>${sanitizeId(m.to)}: ${escapeLabel(m.description)}\n`;
}
mermaid += ' end\n';
}
return mermaid;
}
```
## Usage Examples
### Example 1: Algorithm with Branches
```javascript
const algorithm = {
name: "用户认证流程",
inputs: [{name: "credentials", type: "Object"}],
outputs: [{name: "token", type: "JWT"}],
steps: [
{id: "validate", description: "验证输入格式", type: "process"},
{id: "check_user", description: "用户是否存在?", type: "decision",
next: ["verify_pwd", "error_user"], conditions: ["是", "否"]},
{id: "verify_pwd", description: "验证密码", type: "process"},
{id: "pwd_ok", description: "密码正确?", type: "decision",
next: ["gen_token", "error_pwd"], conditions: ["是", "否"]},
{id: "gen_token", description: "生成 JWT Token", type: "process"},
{id: "error_user", description: "返回用户不存在", type: "io"},
{id: "error_pwd", description: "返回密码错误", type: "io"}
]
};
const flowchart = generateAlgorithmFlowchart(algorithm);
```
### Example 2: Validate Before Output
```javascript
const diagram = generateClassDiagram(analysis);
const validation = validateMermaidSyntax(diagram);
if (!validation.valid) {
console.log("Diagram has issues:", validation.issues);
// Fix issues or regenerate
} else {
Write(`${outputDir}/class-diagram.mmd`, diagram);
}
```

View File

@@ -0,0 +1,116 @@
---
name: ccw-help
description: CCW command help system. Search, browse, recommend commands. Triggers "ccw-help", "ccw-issue".
allowed-tools: Read, Grep, Glob, AskUserQuestion
version: 7.0.0
---
# CCW-Help Skill
CCW 命令帮助系统,提供命令搜索、推荐、文档查看功能。
## Trigger Conditions
- 关键词: "ccw-help", "ccw-issue", "帮助", "命令", "怎么用"
- 场景: 询问命令用法、搜索命令、请求下一步建议
## Operation Modes
### Mode 1: Command Search
**Triggers**: "搜索命令", "find command", "search"
**Process**:
1. Query `command.json` commands array
2. Filter by name, description, category
3. Present top 3-5 relevant commands
### Mode 2: Smart Recommendations
**Triggers**: "下一步", "what's next", "推荐"
**Process**:
1. Query command's `flow.next_steps` in `command.json`
2. Explain WHY each recommendation fits
### Mode 3: Documentation
**Triggers**: "怎么用", "how to use", "详情"
**Process**:
1. Locate command in `command.json`
2. Read source file via `source` path
3. Provide context-specific examples
### Mode 4: Beginner Onboarding
**Triggers**: "新手", "getting started", "常用命令"
**Process**:
1. Query `essential_commands` array
2. Guide appropriate workflow entry point
### Mode 5: Issue Reporting
**Triggers**: "ccw-issue", "报告 bug"
**Process**:
1. Use AskUserQuestion to gather context
2. Generate structured issue template
## Data Source
Single source of truth: **[command.json](command.json)**
| Field | Purpose |
|-------|---------|
| `commands[]` | Flat command list with metadata |
| `commands[].flow` | Relationships (next_steps, prerequisites) |
| `commands[].essential` | Essential flag for onboarding |
| `agents[]` | Agent directory |
| `essential_commands[]` | Core commands list |
### Source Path Format
`source` 字段是相对路径(从 `skills/ccw-help/` 目录):
```json
{
"name": "lite-plan",
"source": "../../../commands/workflow/lite-plan.md"
}
```
## Slash Commands
```bash
/ccw-help # 通用帮助入口
/ccw-help search <keyword> # 搜索命令
/ccw-help next <command> # 获取下一步建议
/ccw-issue # 问题报告
```
## Maintenance
### Update Index
```bash
cd D:/Claude_dms3/.claude/skills/ccw-help
python scripts/analyze_commands.py
```
脚本功能:扫描 commands/ 和 agents/ 目录,生成统一的 command.json
## Statistics
- **Commands**: 88+
- **Agents**: 16
- **Essential**: 10 核心命令
## Core Principle
**智能整合,非模板复制**
- 理解用户具体情况
- 整合多个来源信息
- 定制示例和说明

View File

@@ -0,0 +1,520 @@
{
"_metadata": {
"version": "2.0.0",
"total_commands": 45,
"total_agents": 16,
"description": "Unified CCW-Help command index"
},
"essential_commands": [
"/workflow:lite-plan",
"/workflow:lite-fix",
"/workflow:plan",
"/workflow:execute",
"/workflow:session:start",
"/workflow:review-session-cycle",
"/memory:docs",
"/workflow:brainstorm:artifacts",
"/workflow:plan-verify",
"/version"
],
"commands": [
{
"name": "lite-plan",
"command": "/workflow:lite-plan",
"description": "Lightweight interactive planning with in-memory plan, dispatches to lite-execute",
"arguments": "[-e|--explore] \"task\"|file.md",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"next_steps": ["/workflow:lite-execute"],
"alternatives": ["/workflow:plan"]
},
"source": "../../../commands/workflow/lite-plan.md"
},
{
"name": "lite-execute",
"command": "/workflow:lite-execute",
"description": "Execute based on in-memory plan or prompt",
"arguments": "[--in-memory] \"task\"|file-path",
"category": "workflow",
"difficulty": "Intermediate",
"flow": {
"prerequisites": ["/workflow:lite-plan", "/workflow:lite-fix"]
},
"source": "../../../commands/workflow/lite-execute.md"
},
{
"name": "lite-fix",
"command": "/workflow:lite-fix",
"description": "Lightweight bug diagnosis and fix with optional hotfix mode",
"arguments": "[--hotfix] \"bug description\"",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"next_steps": ["/workflow:lite-execute"],
"alternatives": ["/workflow:lite-plan"]
},
"source": "../../../commands/workflow/lite-fix.md"
},
{
"name": "plan",
"command": "/workflow:plan",
"description": "5-phase planning with task JSON generation",
"arguments": "\"description\"|file.md",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"next_steps": ["/workflow:plan-verify", "/workflow:execute"],
"alternatives": ["/workflow:tdd-plan"]
},
"source": "../../../commands/workflow/plan.md"
},
{
"name": "execute",
"command": "/workflow:execute",
"description": "Coordinate agent execution with DAG parallel processing",
"arguments": "[--resume-session=\"session-id\"]",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"prerequisites": ["/workflow:plan", "/workflow:tdd-plan"],
"next_steps": ["/workflow:review"]
},
"source": "../../../commands/workflow/execute.md"
},
{
"name": "plan-verify",
"command": "/workflow:plan-verify",
"description": "Cross-artifact consistency analysis",
"arguments": "[--session session-id]",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"prerequisites": ["/workflow:plan"],
"next_steps": ["/workflow:execute"]
},
"source": "../../../commands/workflow/plan-verify.md"
},
{
"name": "init",
"command": "/workflow:init",
"description": "Initialize project-level state",
"arguments": "[--regenerate]",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/init.md"
},
{
"name": "clean",
"command": "/workflow:clean",
"description": "Intelligent code cleanup with stale artifact discovery",
"arguments": "[--dry-run] [\"focus\"]",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/clean.md"
},
{
"name": "debug",
"command": "/workflow:debug",
"description": "Hypothesis-driven debugging with NDJSON logging",
"arguments": "\"bug description\"",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/debug.md"
},
{
"name": "replan",
"command": "/workflow:replan",
"description": "Interactive workflow replanning",
"arguments": "[--session id] [task-id] \"requirements\"",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/replan.md"
},
{
"name": "session:start",
"command": "/workflow:session:start",
"description": "Start or discover workflow sessions",
"arguments": "[--type <workflow|review|tdd>] [--auto|--new]",
"category": "workflow",
"subcategory": "session",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"next_steps": ["/workflow:plan", "/workflow:execute"]
},
"source": "../../../commands/workflow/session/start.md"
},
{
"name": "session:list",
"command": "/workflow:session:list",
"description": "List all workflow sessions",
"arguments": "",
"category": "workflow",
"subcategory": "session",
"difficulty": "Beginner",
"source": "../../../commands/workflow/session/list.md"
},
{
"name": "session:resume",
"command": "/workflow:session:resume",
"description": "Resume paused workflow session",
"arguments": "",
"category": "workflow",
"subcategory": "session",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/session/resume.md"
},
{
"name": "session:complete",
"command": "/workflow:session:complete",
"description": "Mark session complete and archive",
"arguments": "",
"category": "workflow",
"subcategory": "session",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/session/complete.md"
},
{
"name": "brainstorm:auto-parallel",
"command": "/workflow:brainstorm:auto-parallel",
"description": "Parallel brainstorming with multi-role analysis",
"arguments": "\"topic\" [--count N]",
"category": "workflow",
"subcategory": "brainstorm",
"difficulty": "Advanced",
"source": "../../../commands/workflow/brainstorm/auto-parallel.md"
},
{
"name": "brainstorm:artifacts",
"command": "/workflow:brainstorm:artifacts",
"description": "Interactive clarification with guidance specification",
"arguments": "\"topic\" [--count N]",
"category": "workflow",
"subcategory": "brainstorm",
"difficulty": "Intermediate",
"essential": true,
"source": "../../../commands/workflow/brainstorm/artifacts.md"
},
{
"name": "brainstorm:synthesis",
"command": "/workflow:brainstorm:synthesis",
"description": "Refine role analyses through Q&A",
"arguments": "[--session session-id]",
"category": "workflow",
"subcategory": "brainstorm",
"difficulty": "Advanced",
"source": "../../../commands/workflow/brainstorm/synthesis.md"
},
{
"name": "tdd-plan",
"command": "/workflow:tdd-plan",
"description": "TDD planning with Red-Green-Refactor cycles",
"arguments": "\"feature\"|file.md",
"category": "workflow",
"difficulty": "Advanced",
"flow": {
"next_steps": ["/workflow:execute", "/workflow:tdd-verify"],
"alternatives": ["/workflow:plan"]
},
"source": "../../../commands/workflow/tdd-plan.md"
},
{
"name": "tdd-verify",
"command": "/workflow:tdd-verify",
"description": "Verify TDD compliance with coverage analysis",
"arguments": "[session-id]",
"category": "workflow",
"difficulty": "Advanced",
"flow": {
"prerequisites": ["/workflow:execute"]
},
"source": "../../../commands/workflow/tdd-verify.md"
},
{
"name": "review",
"command": "/workflow:review",
"description": "Post-implementation review (security/architecture/quality)",
"arguments": "[--type=<type>] [session-id]",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/review.md"
},
{
"name": "review-session-cycle",
"command": "/workflow:review-session-cycle",
"description": "Multi-dimensional code review across 7 dimensions",
"arguments": "[session-id] [--dimensions=...]",
"category": "workflow",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"prerequisites": ["/workflow:execute"],
"next_steps": ["/workflow:review-fix"]
},
"source": "../../../commands/workflow/review-session-cycle.md"
},
{
"name": "review-module-cycle",
"command": "/workflow:review-module-cycle",
"description": "Module-based multi-dimensional review",
"arguments": "<path-pattern> [--dimensions=...]",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/review-module-cycle.md"
},
{
"name": "review-fix",
"command": "/workflow:review-fix",
"description": "Automated fixing of review findings",
"arguments": "<export-file|review-dir>",
"category": "workflow",
"difficulty": "Intermediate",
"flow": {
"prerequisites": ["/workflow:review-session-cycle", "/workflow:review-module-cycle"]
},
"source": "../../../commands/workflow/review-fix.md"
},
{
"name": "test-gen",
"command": "/workflow:test-gen",
"description": "Generate test session from implementation",
"arguments": "source-session-id",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/test-gen.md"
},
{
"name": "test-fix-gen",
"command": "/workflow:test-fix-gen",
"description": "Create test-fix session with strategy",
"arguments": "session-id|\"description\"|file",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/test-fix-gen.md"
},
{
"name": "test-cycle-execute",
"command": "/workflow:test-cycle-execute",
"description": "Execute test-fix with iterative cycles",
"arguments": "[--resume-session=id] [--max-iterations=N]",
"category": "workflow",
"difficulty": "Intermediate",
"source": "../../../commands/workflow/test-cycle-execute.md"
},
{
"name": "issue:new",
"command": "/issue:new",
"description": "Create issue from GitHub URL or text",
"arguments": "<url|text> [--priority 1-5]",
"category": "issue",
"difficulty": "Intermediate",
"source": "../../../commands/issue/new.md"
},
{
"name": "issue:discover",
"command": "/issue:discover",
"description": "Discover issues from multiple perspectives",
"arguments": "<path> [--perspectives=...]",
"category": "issue",
"difficulty": "Intermediate",
"source": "../../../commands/issue/discover.md"
},
{
"name": "issue:plan",
"command": "/issue:plan",
"description": "Batch plan issue resolution",
"arguments": "--all-pending|<ids>",
"category": "issue",
"difficulty": "Intermediate",
"flow": {
"next_steps": ["/issue:queue"]
},
"source": "../../../commands/issue/plan.md"
},
{
"name": "issue:queue",
"command": "/issue:queue",
"description": "Form execution queue from solutions",
"arguments": "[--rebuild]",
"category": "issue",
"difficulty": "Intermediate",
"flow": {
"prerequisites": ["/issue:plan"],
"next_steps": ["/issue:execute"]
},
"source": "../../../commands/issue/queue.md"
},
{
"name": "issue:execute",
"command": "/issue:execute",
"description": "Execute queue with DAG parallel",
"arguments": "[--worktree]",
"category": "issue",
"difficulty": "Intermediate",
"flow": {
"prerequisites": ["/issue:queue"]
},
"source": "../../../commands/issue/execute.md"
},
{
"name": "docs",
"command": "/memory:docs",
"description": "Plan documentation workflow",
"arguments": "[path] [--tool <tool>]",
"category": "memory",
"difficulty": "Intermediate",
"essential": true,
"flow": {
"next_steps": ["/workflow:execute"]
},
"source": "../../../commands/memory/docs.md"
},
{
"name": "update-related",
"command": "/memory:update-related",
"description": "Update docs for git-changed modules",
"arguments": "[--tool <tool>]",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/update-related.md"
},
{
"name": "update-full",
"command": "/memory:update-full",
"description": "Update all CLAUDE.md files",
"arguments": "[--tool <tool>]",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/update-full.md"
},
{
"name": "skill-memory",
"command": "/memory:skill-memory",
"description": "Generate SKILL.md with loading index",
"arguments": "[path] [--regenerate]",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/skill-memory.md"
},
{
"name": "load-skill-memory",
"command": "/memory:load-skill-memory",
"description": "Activate SKILL package for task",
"arguments": "[skill_name] \"task intent\"",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/load-skill-memory.md"
},
{
"name": "load",
"command": "/memory:load",
"description": "Load project context via CLI",
"arguments": "[--tool <tool>] \"context\"",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/load.md"
},
{
"name": "compact",
"command": "/memory:compact",
"description": "Compact session memory for recovery",
"arguments": "[description]",
"category": "memory",
"difficulty": "Intermediate",
"source": "../../../commands/memory/compact.md"
},
{
"name": "task:create",
"command": "/task:create",
"description": "Generate task JSON from description",
"arguments": "\"task title\"",
"category": "task",
"difficulty": "Intermediate",
"source": "../../../commands/task/create.md"
},
{
"name": "task:execute",
"command": "/task:execute",
"description": "Execute task JSON with agent",
"arguments": "task-id",
"category": "task",
"difficulty": "Intermediate",
"source": "../../../commands/task/execute.md"
},
{
"name": "task:breakdown",
"command": "/task:breakdown",
"description": "Decompose task into subtasks",
"arguments": "task-id",
"category": "task",
"difficulty": "Intermediate",
"source": "../../../commands/task/breakdown.md"
},
{
"name": "task:replan",
"command": "/task:replan",
"description": "Update task with new requirements",
"arguments": "task-id [\"text\"|file]",
"category": "task",
"difficulty": "Intermediate",
"source": "../../../commands/task/replan.md"
},
{
"name": "version",
"command": "/version",
"description": "Display version and check updates",
"arguments": "",
"category": "general",
"difficulty": "Beginner",
"essential": true,
"source": "../../../commands/version.md"
},
{
"name": "enhance-prompt",
"command": "/enhance-prompt",
"description": "Transform prompts with session memory",
"arguments": "user input",
"category": "general",
"difficulty": "Intermediate",
"source": "../../../commands/enhance-prompt.md"
},
{
"name": "cli-init",
"command": "/cli:cli-init",
"description": "Initialize CLI tool configurations (.gemini/, .qwen/) with technology-aware ignore rules",
"arguments": "[--tool gemini|qwen|all] [--preview] [--output path]",
"category": "cli",
"difficulty": "Intermediate",
"source": "../../../commands/cli/cli-init.md"
}
],
"agents": [
{ "name": "action-planning-agent", "description": "Task planning and generation", "source": "../../../agents/action-planning-agent.md" },
{ "name": "cli-execution-agent", "description": "CLI tool execution", "source": "../../../agents/cli-execution-agent.md" },
{ "name": "cli-explore-agent", "description": "Codebase exploration", "source": "../../../agents/cli-explore-agent.md" },
{ "name": "cli-lite-planning-agent", "description": "Lightweight planning", "source": "../../../agents/cli-lite-planning-agent.md" },
{ "name": "cli-planning-agent", "description": "CLI-based planning", "source": "../../../agents/cli-planning-agent.md" },
{ "name": "code-developer", "description": "Code implementation", "source": "../../../agents/code-developer.md" },
{ "name": "conceptual-planning-agent", "description": "Conceptual analysis", "source": "../../../agents/conceptual-planning-agent.md" },
{ "name": "context-search-agent", "description": "Context discovery", "source": "../../../agents/context-search-agent.md" },
{ "name": "doc-generator", "description": "Documentation generation", "source": "../../../agents/doc-generator.md" },
{ "name": "issue-plan-agent", "description": "Issue planning", "source": "../../../agents/issue-plan-agent.md" },
{ "name": "issue-queue-agent", "description": "Issue queue formation", "source": "../../../agents/issue-queue-agent.md" },
{ "name": "memory-bridge", "description": "Documentation coordination", "source": "../../../agents/memory-bridge.md" },
{ "name": "test-context-search-agent", "description": "Test context collection", "source": "../../../agents/test-context-search-agent.md" },
{ "name": "test-fix-agent", "description": "Test execution and fixing", "source": "../../../agents/test-fix-agent.md" },
{ "name": "ui-design-agent", "description": "UI design and prototyping", "source": "../../../agents/ui-design-agent.md" },
{ "name": "universal-executor", "description": "Universal task execution", "source": "../../../agents/universal-executor.md" }
],
"categories": ["workflow", "issue", "memory", "task", "general", "cli"]
}

View File

@@ -0,0 +1,337 @@
#!/usr/bin/env python3
"""
Analyze all command/agent files and generate index files for ccw-help skill.
Outputs relative paths pointing to source files (no reference folder duplication).
"""
import os
import re
import json
from pathlib import Path
from collections import defaultdict
from typing import Dict, List, Any
# Base paths
BASE_DIR = Path("D:/Claude_dms3/.claude")
COMMANDS_DIR = BASE_DIR / "commands"
AGENTS_DIR = BASE_DIR / "agents"
SKILL_DIR = BASE_DIR / "skills" / "ccw-help"
INDEX_DIR = SKILL_DIR / "index"
def parse_frontmatter(content: str) -> Dict[str, Any]:
"""Extract YAML frontmatter from markdown content."""
frontmatter = {}
if content.startswith('---'):
lines = content.split('\n')
for i, line in enumerate(lines[1:], 1):
if line.strip() == '---':
break
if ':' in line:
key, value = line.split(':', 1)
frontmatter[key.strip()] = value.strip().strip('"')
return frontmatter
def categorize_command(file_path: Path) -> tuple:
"""Determine category and subcategory from file path."""
parts = file_path.relative_to(COMMANDS_DIR).parts
if len(parts) == 1:
return "general", None
category = parts[0] # cli, memory, task, workflow
subcategory = parts[1].replace('.md', '') if len(parts) > 2 else None
return category, subcategory
def determine_usage_scenario(name: str, description: str, category: str) -> str:
"""Determine primary usage scenario for command."""
name_lower = name.lower()
if any(word in name_lower for word in ['plan', 'design', 'breakdown', 'brainstorm']):
return "planning"
if any(word in name_lower for word in ['implement', 'execute', 'generate', 'create', 'write']):
return "implementation"
if any(word in name_lower for word in ['test', 'tdd', 'verify', 'coverage']):
return "testing"
if any(word in name_lower for word in ['docs', 'documentation', 'memory']):
return "documentation"
if any(word in name_lower for word in ['session', 'resume', 'status', 'complete']):
return "session-management"
if any(word in name_lower for word in ['analyze', 'review', 'diagnosis']):
return "analysis"
return "general"
def determine_difficulty(name: str, description: str, category: str) -> str:
"""Determine difficulty level."""
name_lower = name.lower()
beginner_keywords = ['status', 'list', 'chat', 'analyze', 'version']
if any(word in name_lower for word in beginner_keywords):
return "Beginner"
advanced_keywords = ['tdd', 'conflict', 'agent', 'auto-parallel', 'coverage', 'synthesis']
if any(word in name_lower for word in advanced_keywords):
return "Advanced"
return "Intermediate"
def analyze_command_file(file_path: Path) -> Dict[str, Any]:
"""Analyze a single command file and extract metadata."""
with open(file_path, 'r', encoding='utf-8') as f:
content = f.read()
frontmatter = parse_frontmatter(content)
name = frontmatter.get('name', file_path.stem)
description = frontmatter.get('description', '')
argument_hint = frontmatter.get('argument-hint', '')
category, subcategory = categorize_command(file_path)
usage_scenario = determine_usage_scenario(name, description, category)
difficulty = determine_difficulty(name, description, category)
# Build relative path from INDEX_DIR (need to go up 3 levels: index -> ccw-help -> skills -> .claude)
# e.g., "../../../commands/workflow/lite-plan.md"
rel_from_base = file_path.relative_to(BASE_DIR)
rel_path = "../../../" + str(rel_from_base).replace('\\', '/')
# Build full command name
if ':' in name:
command_name = f"/{name}"
elif category == "general":
command_name = f"/{name}"
else:
if subcategory:
command_name = f"/{category}:{subcategory}:{name}"
else:
command_name = f"/{category}:{name}"
return {
"name": name,
"command": command_name,
"description": description,
"arguments": argument_hint,
"category": category,
"subcategory": subcategory,
"usage_scenario": usage_scenario,
"difficulty": difficulty,
"source": rel_path # Relative from index/ dir (e.g., "../../../commands/workflow/...")
}
def analyze_agent_file(file_path: Path) -> Dict[str, Any]:
"""Analyze a single agent file and extract metadata."""
with open(file_path, 'r', encoding='utf-8') as f:
content = f.read()
frontmatter = parse_frontmatter(content)
name = frontmatter.get('name', file_path.stem)
description = frontmatter.get('description', '')
# Build relative path from INDEX_DIR (need to go up 3 levels)
# e.g., "../../../agents/code-developer.md"
rel_from_base = file_path.relative_to(BASE_DIR)
rel_path = "../../../" + str(rel_from_base).replace('\\', '/')
return {
"name": name,
"description": description,
"source": rel_path # Relative from index/ dir (e.g., "../../../agents/...")
}
def build_command_relationships() -> Dict[str, Any]:
"""Build command relationship mappings."""
return {
"workflow:plan": {
"calls_internally": ["workflow:session:start", "workflow:tools:context-gather", "workflow:tools:conflict-resolution", "workflow:tools:task-generate-agent"],
"next_steps": ["workflow:plan-verify", "workflow:status", "workflow:execute"],
"alternatives": ["workflow:tdd-plan"],
"prerequisites": []
},
"workflow:tdd-plan": {
"calls_internally": ["workflow:session:start", "workflow:tools:context-gather", "workflow:tools:task-generate-tdd"],
"next_steps": ["workflow:tdd-verify", "workflow:status", "workflow:execute"],
"alternatives": ["workflow:plan"],
"prerequisites": []
},
"workflow:execute": {
"prerequisites": ["workflow:plan", "workflow:tdd-plan"],
"related": ["workflow:status", "workflow:resume"],
"next_steps": ["workflow:review", "workflow:tdd-verify"]
},
"workflow:plan-verify": {
"prerequisites": ["workflow:plan"],
"next_steps": ["workflow:execute"],
"related": ["workflow:status"]
},
"workflow:tdd-verify": {
"prerequisites": ["workflow:execute"],
"related": ["workflow:tools:tdd-coverage-analysis"]
},
"workflow:session:start": {
"next_steps": ["workflow:plan", "workflow:execute"],
"related": ["workflow:session:list", "workflow:session:resume"]
},
"workflow:session:resume": {
"alternatives": ["workflow:resume"],
"related": ["workflow:session:list", "workflow:status"]
},
"workflow:lite-plan": {
"calls_internally": ["workflow:lite-execute"],
"next_steps": ["workflow:lite-execute", "workflow:status"],
"alternatives": ["workflow:plan"],
"prerequisites": []
},
"workflow:lite-fix": {
"next_steps": ["workflow:lite-execute", "workflow:status"],
"alternatives": ["workflow:lite-plan"],
"related": ["workflow:test-cycle-execute"]
},
"workflow:lite-execute": {
"prerequisites": ["workflow:lite-plan", "workflow:lite-fix"],
"related": ["workflow:execute", "workflow:status"]
},
"workflow:review-session-cycle": {
"prerequisites": ["workflow:execute"],
"next_steps": ["workflow:review-fix"],
"related": ["workflow:review-module-cycle"]
},
"workflow:review-fix": {
"prerequisites": ["workflow:review-module-cycle", "workflow:review-session-cycle"],
"related": ["workflow:test-cycle-execute"]
},
"memory:docs": {
"calls_internally": ["workflow:session:start", "workflow:tools:context-gather"],
"next_steps": ["workflow:execute"]
},
"memory:skill-memory": {
"next_steps": ["workflow:plan", "cli:analyze"],
"related": ["memory:load-skill-memory"]
}
}
def identify_essential_commands(all_commands: List[Dict]) -> List[Dict]:
"""Identify the most essential commands for beginners."""
essential_names = [
"workflow:lite-plan", "workflow:lite-fix", "workflow:plan",
"workflow:execute", "workflow:status", "workflow:session:start",
"workflow:review-session-cycle", "cli:analyze", "cli:chat",
"memory:docs", "workflow:brainstorm:artifacts",
"workflow:plan-verify", "workflow:resume", "version"
]
essential = []
for cmd in all_commands:
cmd_name = cmd['command'].lstrip('/')
if cmd_name in essential_names:
essential.append(cmd)
essential.sort(key=lambda x: essential_names.index(x['command'].lstrip('/')) if x['command'].lstrip('/') in essential_names else 999)
return essential[:14]
def main():
"""Main analysis function."""
import sys
import io
if sys.platform == 'win32':
sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')
print("=== CCW-Help Index Rebuild ===\n")
# Analyze command files
print("=== Analyzing Command Files ===")
command_files = list(COMMANDS_DIR.rglob("*.md"))
print(f"Found {len(command_files)} command files")
all_commands = []
for cmd_file in sorted(command_files):
try:
metadata = analyze_command_file(cmd_file)
all_commands.append(metadata)
print(f" OK {metadata['command']}")
except Exception as e:
print(f" ERROR analyzing {cmd_file}: {e}")
# Analyze agent files
print("\n=== Analyzing Agent Files ===")
agent_files = list(AGENTS_DIR.rglob("*.md"))
print(f"Found {len(agent_files)} agent files")
all_agents = []
for agent_file in sorted(agent_files):
try:
metadata = analyze_agent_file(agent_file)
all_agents.append(metadata)
print(f" OK {metadata['name']}")
except Exception as e:
print(f" ERROR analyzing {agent_file}: {e}")
print(f"\nAnalyzed {len(all_commands)} commands, {len(all_agents)} agents")
# Generate index files
INDEX_DIR.mkdir(parents=True, exist_ok=True)
# 1. all-commands.json
all_commands_path = INDEX_DIR / "all-commands.json"
with open(all_commands_path, 'w', encoding='utf-8') as f:
json.dump(all_commands, f, indent=2, ensure_ascii=False)
print(f"\nOK Generated {all_commands_path.name} ({os.path.getsize(all_commands_path)} bytes)")
# 2. all-agents.json
all_agents_path = INDEX_DIR / "all-agents.json"
with open(all_agents_path, 'w', encoding='utf-8') as f:
json.dump(all_agents, f, indent=2, ensure_ascii=False)
print(f"OK Generated {all_agents_path.name} ({os.path.getsize(all_agents_path)} bytes)")
# 3. by-category.json
by_category = defaultdict(lambda: defaultdict(list))
for cmd in all_commands:
cat = cmd['category']
subcat = cmd['subcategory'] or '_root'
by_category[cat][subcat].append(cmd)
by_category_path = INDEX_DIR / "by-category.json"
with open(by_category_path, 'w', encoding='utf-8') as f:
json.dump(dict(by_category), f, indent=2, ensure_ascii=False)
print(f"OK Generated {by_category_path.name} ({os.path.getsize(by_category_path)} bytes)")
# 4. by-use-case.json
by_use_case = defaultdict(list)
for cmd in all_commands:
by_use_case[cmd['usage_scenario']].append(cmd)
by_use_case_path = INDEX_DIR / "by-use-case.json"
with open(by_use_case_path, 'w', encoding='utf-8') as f:
json.dump(dict(by_use_case), f, indent=2, ensure_ascii=False)
print(f"OK Generated {by_use_case_path.name} ({os.path.getsize(by_use_case_path)} bytes)")
# 5. essential-commands.json
essential = identify_essential_commands(all_commands)
essential_path = INDEX_DIR / "essential-commands.json"
with open(essential_path, 'w', encoding='utf-8') as f:
json.dump(essential, f, indent=2, ensure_ascii=False)
print(f"OK Generated {essential_path.name} ({os.path.getsize(essential_path)} bytes)")
# 6. command-relationships.json
relationships = build_command_relationships()
relationships_path = INDEX_DIR / "command-relationships.json"
with open(relationships_path, 'w', encoding='utf-8') as f:
json.dump(relationships, f, indent=2, ensure_ascii=False)
print(f"OK Generated {relationships_path.name} ({os.path.getsize(relationships_path)} bytes)")
# Print summary
print("\n=== Summary ===")
print(f"Commands: {len(all_commands)}")
print(f"Agents: {len(all_agents)}")
print(f"Essential: {len(essential)}")
print(f"\nBy category:")
for cat in sorted(by_category.keys()):
total = sum(len(cmds) for cmds in by_category[cat].values())
print(f" {cat}: {total}")
print(f"\nIndex: {INDEX_DIR}")
print("=== Complete ===")
if __name__ == '__main__':
main()

View File

@@ -0,0 +1,303 @@
# CCW Loop Skill
无状态迭代开发循环工作流,支持开发 (Develop)、调试 (Debug)、验证 (Validate) 三个阶段,每个阶段都有独立的文件记录进展。
## Overview
CCW Loop 是一个自主模式 (Autonomous) 的 Skill通过文件驱动的无状态循环帮助开发者系统化地完成开发任务。
### 核心特性
1. **无状态循环**: 每次执行从文件读取状态,不依赖内存
2. **文件驱动**: 所有进度记录在 Markdown 文件中,可审计、可回顾
3. **Gemini 辅助**: 关键决策点使用 CLI 工具进行深度分析
4. **可恢复**: 任何时候中断后可继续
5. **双模式**: 支持交互式和自动循环
### 三大阶段
- **Develop**: 任务分解 → 代码实现 → 进度记录
- **Debug**: 假设生成 → 证据收集 → 根因分析 → 修复验证
- **Validate**: 测试执行 → 覆盖率检查 → 质量评估
## Installation
已包含在 `.claude/skills/ccw-loop/`,无需额外安装。
## Usage
### 基本用法
```bash
# 启动新循环
/ccw-loop "实现用户认证功能"
# 继续现有循环
/ccw-loop --resume LOOP-auth-2026-01-22
# 自动循环模式
/ccw-loop --auto "修复登录bug并添加测试"
```
### 交互式流程
```
1. 启动: /ccw-loop "任务描述"
2. 初始化: 自动分析任务并生成子任务列表
3. 显示菜单:
- 📝 继续开发 (Develop)
- 🔍 开始调试 (Debug)
- ✅ 运行验证 (Validate)
- 📊 查看详情 (Status)
- 🏁 完成循环 (Complete)
- 🚪 退出 (Exit)
4. 执行选择的动作
5. 重复步骤 3-4 直到完成
```
### 自动循环流程
```
Develop (所有任务) → Debug (如有需要) → Validate → 完成
```
## Directory Structure
```
.workflow/.loop/{session-id}/
├── meta.json # 会话元数据 (不可修改)
├── state.json # 当前状态 (每次更新)
├── summary.md # 完成报告 (结束时生成)
├── develop/
│ ├── progress.md # 开发进度时间线
│ ├── tasks.json # 任务列表
│ └── changes.log # 代码变更日志 (NDJSON)
├── debug/
│ ├── understanding.md # 理解演变文档
│ ├── hypotheses.json # 假设历史
│ └── debug.log # 调试日志 (NDJSON)
└── validate/
├── validation.md # 验证报告
├── test-results.json # 测试结果
└── coverage.json # 覆盖率数据
```
## Action Reference
| Action | 描述 | 触发条件 |
|--------|------|----------|
| action-init | 初始化会话 | 首次启动 |
| action-menu | 显示操作菜单 | 交互模式下每次循环 |
| action-develop-with-file | 执行开发任务 | 有待处理任务 |
| action-debug-with-file | 假设驱动调试 | 需要调试 |
| action-validate-with-file | 运行测试验证 | 需要验证 |
| action-complete | 完成并生成报告 | 所有任务完成 |
详细说明见 [specs/action-catalog.md](specs/action-catalog.md)
## CLI Integration
CCW Loop 在关键决策点集成 CLI 工具:
### 任务分解 (action-init)
```bash
ccw cli -p "PURPOSE: 分解开发任务..."
--tool gemini
--mode analysis
--rule planning-breakdown-task-steps
```
### 代码实现 (action-develop)
```bash
ccw cli -p "PURPOSE: 实现功能代码..."
--tool gemini
--mode write
--rule development-implement-feature
```
### 假设生成 (action-debug - 探索)
```bash
ccw cli -p "PURPOSE: Generate debugging hypotheses..."
--tool gemini
--mode analysis
--rule analysis-diagnose-bug-root-cause
```
### 证据分析 (action-debug - 分析)
```bash
ccw cli -p "PURPOSE: Analyze debug log evidence..."
--tool gemini
--mode analysis
--rule analysis-diagnose-bug-root-cause
```
### 质量评估 (action-validate)
```bash
ccw cli -p "PURPOSE: Analyze test results and coverage..."
--tool gemini
--mode analysis
--rule analysis-review-code-quality
```
## State Management
### State Schema
参见 [phases/state-schema.md](phases/state-schema.md)
### State Transitions
```
pending → running → completed
user_exit
failed
```
### State Recovery
如果 `state.json` 损坏,可从其他文件重建:
- develop/tasks.json → develop.*
- debug/hypotheses.json → debug.*
- validate/test-results.json → validate.*
## Examples
### Example 1: 功能开发
```bash
# 1. 启动循环
/ccw-loop "Add user profile page"
# 2. 系统初始化,生成任务:
# - task-001: Create profile component
# - task-002: Add API endpoints
# - task-003: Implement tests
# 3. 选择 "继续开发"
# → 执行 task-001 (Gemini 辅助实现)
# → 更新 progress.md
# 4. 重复开发直到所有任务完成
# 5. 选择 "运行验证"
# → 运行测试
# → 检查覆盖率
# → 生成 validation.md
# 6. 选择 "完成循环"
# → 生成 summary.md
# → 询问是否扩展为 Issue
```
### Example 2: Bug 修复
```bash
# 1. 启动循环
/ccw-loop "Fix login timeout issue"
# 2. 选择 "开始调试"
# → 输入 bug 描述: "Login times out after 30s"
# → Gemini 生成假设 (H1, H2, H3)
# → 添加 NDJSON 日志
# → 提示复现 bug
# 3. 复现 bug (在应用中操作)
# 4. 再次选择 "开始调试"
# → 解析 debug.log
# → Gemini 分析证据
# → H2 确认为根因
# → 生成修复代码
# → 更新 understanding.md
# 5. 选择 "运行验证"
# → 测试通过
# 6. 完成
```
## Templates
- [progress-template.md](templates/progress-template.md): 开发进度文档模板
- [understanding-template.md](templates/understanding-template.md): 调试理解文档模板
- [validation-template.md](templates/validation-template.md): 验证报告模板
## Specifications
- [loop-requirements.md](specs/loop-requirements.md): 循环需求规范
- [action-catalog.md](specs/action-catalog.md): 动作目录
## Integration
### Dashboard Integration
CCW Loop 与 Dashboard Loop Monitor 集成:
- Dashboard 创建 Loop → 触发此 Skill
- state.json → Dashboard 实时显示
- 任务列表双向同步
- 控制按钮映射到 actions
### Issue System Integration
完成后可扩展为 Issue:
- 维度: test, enhance, refactor, doc
- 自动调用 `/issue:new`
- 上下文自动填充
## Error Handling
| 情况 | 处理 |
|------|------|
| Session 不存在 | 创建新会话 |
| state.json 损坏 | 从文件重建 |
| CLI 工具失败 | 回退到手动模式 |
| 测试失败 | 循环回到 develop/debug |
| >10 迭代 | 警告用户,建议拆分 |
## Limitations
1. **单会话限制**: 同一时间只能有一个活跃会话
2. **迭代限制**: 建议不超过 10 次迭代
3. **CLI 依赖**: 部分功能依赖 Gemini CLI 可用性
4. **测试框架**: 需要 package.json 中定义测试脚本
## Troubleshooting
### Q: 如何查看当前会话状态?
A: 在菜单中选择 "查看详情 (Status)"
### Q: 如何恢复中断的会话?
A: 使用 `--resume` 参数:
```bash
/ccw-loop --resume LOOP-xxx-2026-01-22
```
### Q: 如果 CLI 工具失败怎么办?
A: Skill 会自动降级到手动模式,提示用户手动输入
### Q: 如何添加自定义 action
A: 参见 [specs/action-catalog.md](specs/action-catalog.md) 的 "Action Extensions" 部分
## Contributing
添加新功能:
1. 创建 action 文件在 `phases/actions/`
2. 更新 orchestrator 决策逻辑
3. 添加到 action-catalog.md
4. 更新 action-menu.md
## License
MIT
---
**Version**: 1.0.0
**Last Updated**: 2026-01-22
**Author**: CCW Team

View File

@@ -0,0 +1,259 @@
---
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}"`

View File

@@ -0,0 +1,320 @@
# Action: Complete
完成 CCW Loop 会话,生成总结报告。
## Purpose
- 生成完成报告
- 汇总所有阶段成果
- 提供后续建议
- 询问是否扩展为 Issue
## Preconditions
- [ ] state.initialized === true
- [ ] state.status === 'running'
## Execution
### Step 1: 汇总统计
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const sessionFolder = `.workflow/.loop/${state.session_id}`
const stats = {
// 时间统计
duration: Date.now() - new Date(state.created_at).getTime(),
iterations: state.iteration_count,
// 开发统计
develop: {
total_tasks: state.develop.total_count,
completed_tasks: state.develop.completed_count,
completion_rate: state.develop.total_count > 0
? (state.develop.completed_count / state.develop.total_count * 100).toFixed(1)
: 0
},
// 调试统计
debug: {
iterations: state.debug.iteration,
hypotheses_tested: state.debug.hypotheses.length,
root_cause_found: state.debug.confirmed_hypothesis !== null
},
// 验证统计
validate: {
runs: state.validate.test_results.length,
passed: state.validate.passed,
coverage: state.validate.coverage,
failed_tests: state.validate.failed_tests.length
}
}
console.log('\n生成完成报告...')
```
### Step 2: 生成总结报告
```javascript
const summaryReport = `# CCW Loop Session Summary
**Session ID**: ${state.session_id}
**Task**: ${state.task_description}
**Started**: ${state.created_at}
**Completed**: ${getUtc8ISOString()}
**Duration**: ${formatDuration(stats.duration)}
---
## Executive Summary
${state.validate.passed
? '✅ **任务成功完成** - 所有测试通过,验证成功'
: state.develop.completed_count === state.develop.total_count
? '⚠️ **开发完成,验证未通过** - 需要进一步调试'
: '⏸️ **任务部分完成** - 仍有待处理项'}
---
## Development Phase
| Metric | Value |
|--------|-------|
| Total Tasks | ${stats.develop.total_tasks} |
| Completed | ${stats.develop.completed_tasks} |
| Completion Rate | ${stats.develop.completion_rate}% |
### Completed Tasks
${state.develop.tasks.filter(t => t.status === 'completed').map(t => `
- ✅ ${t.description}
- Files: ${t.files_changed?.join(', ') || 'N/A'}
- Completed: ${t.completed_at}
`).join('\n')}
### Pending Tasks
${state.develop.tasks.filter(t => t.status !== 'completed').map(t => `
- ⏳ ${t.description}
`).join('\n') || '_None_'}
---
## Debug Phase
| Metric | Value |
|--------|-------|
| Iterations | ${stats.debug.iterations} |
| Hypotheses Tested | ${stats.debug.hypotheses_tested} |
| Root Cause Found | ${stats.debug.root_cause_found ? 'Yes' : 'No'} |
${stats.debug.root_cause_found ? `
### Confirmed Root Cause
**${state.debug.confirmed_hypothesis}**: ${state.debug.hypotheses.find(h => h.id === state.debug.confirmed_hypothesis)?.description || 'N/A'}
` : ''}
### Hypothesis Summary
${state.debug.hypotheses.map(h => `
- **${h.id}**: ${h.status.toUpperCase()}
- ${h.description}
`).join('\n') || '_No hypotheses tested_'}
---
## Validation Phase
| Metric | Value |
|--------|-------|
| Test Runs | ${stats.validate.runs} |
| Status | ${stats.validate.passed ? 'PASSED' : 'FAILED'} |
| Coverage | ${stats.validate.coverage || 'N/A'}% |
| Failed Tests | ${stats.validate.failed_tests} |
${stats.validate.failed_tests > 0 ? `
### Failed Tests
${state.validate.failed_tests.map(t => `- ❌ ${t}`).join('\n')}
` : ''}
---
## Files Modified
${listModifiedFiles(sessionFolder)}
---
## Key Learnings
${state.debug.iteration > 0 ? `
### From Debugging
${extractLearnings(state.debug.hypotheses)}
` : ''}
---
## Recommendations
${generateRecommendations(stats, state)}
---
## Session Artifacts
| File | Description |
|------|-------------|
| \`develop/progress.md\` | Development progress timeline |
| \`develop/tasks.json\` | Task list with status |
| \`debug/understanding.md\` | Debug exploration and learnings |
| \`debug/hypotheses.json\` | Hypothesis history |
| \`validate/validation.md\` | Validation report |
| \`validate/test-results.json\` | Test execution results |
---
*Generated by CCW Loop at ${getUtc8ISOString()}*
`
Write(`${sessionFolder}/summary.md`, summaryReport)
console.log(`\n报告已保存: ${sessionFolder}/summary.md`)
```
### Step 3: 询问后续扩展
```javascript
console.log('\n' + '═'.repeat(60))
console.log(' 任务已完成')
console.log('═'.repeat(60))
const expansionResponse = await AskUserQuestion({
questions: [{
question: "是否将发现扩展为 Issue",
header: "扩展选项",
multiSelect: true,
options: [
{ label: "测试 (Test)", description: "添加更多测试用例" },
{ label: "增强 (Enhance)", description: "功能增强建议" },
{ label: "重构 (Refactor)", description: "代码重构建议" },
{ label: "文档 (Doc)", description: "文档更新需求" },
{ label: "否,直接完成", description: "不创建 Issue" }
]
}]
})
const selectedExpansions = expansionResponse["扩展选项"]
if (selectedExpansions && !selectedExpansions.includes("否,直接完成")) {
for (const expansion of selectedExpansions) {
const dimension = expansion.split(' ')[0].toLowerCase()
const issueSummary = `${state.task_description} - ${dimension}`
console.log(`\n创建 Issue: ${issueSummary}`)
// 调用 /issue:new 创建 issue
await Bash({
command: `/issue:new "${issueSummary}"`,
run_in_background: false
})
}
}
```
### Step 4: 最终输出
```javascript
console.log(`
═══════════════════════════════════════════════════════════
✅ CCW Loop 会话完成
═══════════════════════════════════════════════════════════
会话 ID: ${state.session_id}
用时: ${formatDuration(stats.duration)}
迭代: ${stats.iterations}
开发: ${stats.develop.completed_tasks}/${stats.develop.total_tasks} 任务完成
调试: ${stats.debug.iterations} 次迭代
验证: ${stats.validate.passed ? '通过 ✅' : '未通过 ❌'}
报告: ${sessionFolder}/summary.md
═══════════════════════════════════════════════════════════
`)
```
## State Updates
```javascript
return {
stateUpdates: {
status: 'completed',
completed_at: getUtc8ISOString(),
summary: stats
},
continue: false,
message: `会话 ${state.session_id} 已完成`
}
```
## Helper Functions
```javascript
function formatDuration(ms) {
const seconds = Math.floor(ms / 1000)
const minutes = Math.floor(seconds / 60)
const hours = Math.floor(minutes / 60)
if (hours > 0) {
return `${hours}h ${minutes % 60}m`
} else if (minutes > 0) {
return `${minutes}m ${seconds % 60}s`
} else {
return `${seconds}s`
}
}
function generateRecommendations(stats, state) {
const recommendations = []
if (stats.develop.completion_rate < 100) {
recommendations.push('- 完成剩余开发任务')
}
if (!stats.validate.passed) {
recommendations.push('- 修复失败的测试')
}
if (stats.validate.coverage && stats.validate.coverage < 80) {
recommendations.push(`- 提高测试覆盖率 (当前: ${stats.validate.coverage}%)`)
}
if (stats.debug.iterations > 3 && !stats.debug.root_cause_found) {
recommendations.push('- 考虑代码重构以简化调试')
}
if (recommendations.length === 0) {
recommendations.push('- 考虑代码审查')
recommendations.push('- 更新相关文档')
recommendations.push('- 准备部署')
}
return recommendations.join('\n')
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| 报告生成失败 | 显示基本统计,跳过文件写入 |
| Issue 创建失败 | 记录错误,继续完成 |
## Next Actions
- 无 (终止状态)
- 如需继续: 使用 `ccw-loop --resume {session-id}` 重新打开会话

View File

@@ -0,0 +1,485 @@
# Action: Debug With File
假设驱动调试,记录理解演变到 understanding.md支持 Gemini 辅助分析和假设生成。
## Purpose
执行假设驱动的调试流程,包括:
- 定位错误源
- 生成可测试假设
- 添加 NDJSON 日志
- 分析日志证据
- 纠正错误理解
- 应用修复
## Preconditions
- [ ] state.initialized === true
- [ ] state.status === 'running'
## Session Setup
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const sessionFolder = `.workflow/.loop/${state.session_id}`
const debugFolder = `${sessionFolder}/debug`
const understandingPath = `${debugFolder}/understanding.md`
const hypothesesPath = `${debugFolder}/hypotheses.json`
const debugLogPath = `${debugFolder}/debug.log`
```
---
## Mode Detection
```javascript
// 自动检测模式
const understandingExists = fs.existsSync(understandingPath)
const logHasContent = fs.existsSync(debugLogPath) && fs.statSync(debugLogPath).size > 0
const debugMode = logHasContent ? 'analyze' : (understandingExists ? 'continue' : 'explore')
console.log(`Debug mode: ${debugMode}`)
```
---
## Explore Mode (首次调试)
### Step 1.1: 定位错误源
```javascript
if (debugMode === 'explore') {
// 询问用户 bug 描述
const bugInput = await AskUserQuestion({
questions: [{
question: "请描述遇到的 bug 或错误信息:",
header: "Bug 描述",
multiSelect: false,
options: [
{ label: "手动输入", description: "输入错误描述或堆栈" },
{ label: "从测试失败", description: "从验证阶段的失败测试中获取" }
]
}]
})
const bugDescription = bugInput["Bug 描述"]
// 提取关键词并搜索
const searchResults = await Task({
subagent_type: 'Explore',
run_in_background: false,
prompt: `Search codebase for error patterns related to: ${bugDescription}`
})
// 分析搜索结果,识别受影响的位置
const affectedLocations = analyzeSearchResults(searchResults)
}
```
### Step 1.2: 记录初始理解
```javascript
// 创建 understanding.md
const initialUnderstanding = `# Understanding Document
**Session ID**: ${state.session_id}
**Bug Description**: ${bugDescription}
**Started**: ${getUtc8ISOString()}
---
## Exploration Timeline
### Iteration 1 - Initial Exploration (${getUtc8ISOString()})
#### Current Understanding
Based on bug description and initial code search:
- Error pattern: ${errorPattern}
- Affected areas: ${affectedLocations.map(l => l.file).join(', ')}
- Initial hypothesis: ${initialThoughts}
#### Evidence from Code Search
${searchResults.map(r => `
**Keyword: "${r.keyword}"**
- Found in: ${r.files.join(', ')}
- Key findings: ${r.insights}
`).join('\n')}
#### Next Steps
- Generate testable hypotheses
- Add instrumentation
- Await reproduction
---
## Current Consolidated Understanding
${initialConsolidatedUnderstanding}
`
Write(understandingPath, initialUnderstanding)
```
### Step 1.3: Gemini 辅助假设生成
```bash
ccw cli -p "
PURPOSE: Generate debugging hypotheses for: ${bugDescription}
Success criteria: Testable hypotheses with clear evidence criteria
TASK:
• Analyze error pattern and code search results
• Identify 3-5 most likely root causes
• For each hypothesis, specify:
- What might be wrong
- What evidence would confirm/reject it
- Where to add instrumentation
• Rank by likelihood
MODE: analysis
CONTEXT: @${understandingPath} | Search results in understanding.md
EXPECTED:
- Structured hypothesis list (JSON format)
- Each hypothesis with: id, description, testable_condition, logging_point, evidence_criteria
- Likelihood ranking (1=most likely)
CONSTRAINTS: Focus on testable conditions
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
### Step 1.4: 保存假设
```javascript
const hypotheses = {
iteration: 1,
timestamp: getUtc8ISOString(),
bug_description: bugDescription,
hypotheses: [
{
id: "H1",
description: "...",
testable_condition: "...",
logging_point: "file.ts:func:42",
evidence_criteria: {
confirm: "...",
reject: "..."
},
likelihood: 1,
status: "pending"
}
// ...
],
gemini_insights: "...",
corrected_assumptions: []
}
Write(hypothesesPath, JSON.stringify(hypotheses, null, 2))
```
### Step 1.5: 添加 NDJSON 日志
```javascript
// 为每个假设添加日志点
for (const hypothesis of hypotheses.hypotheses) {
const [file, func, line] = hypothesis.logging_point.split(':')
const logStatement = `console.log(JSON.stringify({
hid: "${hypothesis.id}",
ts: Date.now(),
func: "${func}",
data: { /* 相关数据 */ }
}))`
// 使用 Edit 工具添加日志
// ...
}
```
---
## Analyze Mode (有日志后)
### Step 2.1: 解析调试日志
```javascript
if (debugMode === 'analyze') {
// 读取 NDJSON 日志
const logContent = Read(debugLogPath)
const entries = logContent.split('\n')
.filter(l => l.trim())
.map(l => JSON.parse(l))
// 按假设分组
const byHypothesis = groupBy(entries, 'hid')
}
```
### Step 2.2: Gemini 辅助证据分析
```bash
ccw cli -p "
PURPOSE: Analyze debug log evidence to validate/correct hypotheses for: ${bugDescription}
Success criteria: Clear verdict per hypothesis + corrected understanding
TASK:
• Parse log entries by hypothesis
• Evaluate evidence against expected criteria
• Determine verdict: confirmed | rejected | inconclusive
• Identify incorrect assumptions from previous understanding
• Suggest corrections to understanding
MODE: analysis
CONTEXT:
@${debugLogPath}
@${understandingPath}
@${hypothesesPath}
EXPECTED:
- Per-hypothesis verdict with reasoning
- Evidence summary
- List of incorrect assumptions with corrections
- Updated consolidated understanding
- Root cause if confirmed, or next investigation steps
CONSTRAINTS: Evidence-based reasoning only, no speculation
" --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
### Step 2.3: 更新理解文档
```javascript
// 追加新迭代到 understanding.md
const iteration = state.debug.iteration + 1
const analysisEntry = `
### Iteration ${iteration} - Evidence Analysis (${getUtc8ISOString()})
#### Log Analysis Results
${results.map(r => `
**${r.id}**: ${r.verdict.toUpperCase()}
- Evidence: ${JSON.stringify(r.evidence)}
- Reasoning: ${r.reason}
`).join('\n')}
#### Corrected Understanding
Previous misunderstandings identified and corrected:
${corrections.map(c => `
- ~~${c.wrong}~~ → ${c.corrected}
- Why wrong: ${c.reason}
- Evidence: ${c.evidence}
`).join('\n')}
#### New Insights
${newInsights.join('\n- ')}
#### Gemini Analysis
${geminiAnalysis}
${confirmedHypothesis ? `
#### Root Cause Identified
**${confirmedHypothesis.id}**: ${confirmedHypothesis.description}
Evidence supporting this conclusion:
${confirmedHypothesis.supportingEvidence}
` : `
#### Next Steps
${nextSteps}
`}
---
## Current Consolidated Understanding (Updated)
### What We Know
- ${validUnderstanding1}
- ${validUnderstanding2}
### What Was Disproven
- ~~${wrongAssumption}~~ (Evidence: ${disproofEvidence})
### Current Investigation Focus
${currentFocus}
### Remaining Questions
- ${openQuestion1}
- ${openQuestion2}
`
const existingContent = Read(understandingPath)
Write(understandingPath, existingContent + analysisEntry)
```
### Step 2.4: 更新假设状态
```javascript
const hypothesesData = JSON.parse(Read(hypothesesPath))
// 更新假设状态
hypothesesData.hypotheses = hypothesesData.hypotheses.map(h => ({
...h,
status: results.find(r => r.id === h.id)?.verdict || h.status,
evidence: results.find(r => r.id === h.id)?.evidence || h.evidence,
verdict_reason: results.find(r => r.id === h.id)?.reason || h.verdict_reason
}))
hypothesesData.iteration++
hypothesesData.timestamp = getUtc8ISOString()
Write(hypothesesPath, JSON.stringify(hypothesesData, null, 2))
```
---
## Fix & Verification
### Step 3.1: 应用修复
```javascript
if (confirmedHypothesis) {
console.log(`\n根因确认: ${confirmedHypothesis.description}`)
console.log('准备应用修复...')
// 使用 Gemini 生成修复代码
const fixPrompt = `
PURPOSE: Fix the identified root cause
Root Cause: ${confirmedHypothesis.description}
Evidence: ${confirmedHypothesis.supportingEvidence}
TASK:
• Generate fix code
• Ensure backward compatibility
• Add tests if needed
MODE: write
CONTEXT: @${confirmedHypothesis.logging_point.split(':')[0]}
EXPECTED: Fixed code + verification steps
`
await Bash({
command: `ccw cli -p "${fixPrompt}" --tool gemini --mode write --rule development-debug-runtime-issues`,
run_in_background: false
})
}
```
### Step 3.2: 记录解决方案
```javascript
const resolutionEntry = `
### Resolution (${getUtc8ISOString()})
#### Fix Applied
- Modified files: ${modifiedFiles.join(', ')}
- Fix description: ${fixDescription}
- Root cause addressed: ${rootCause}
#### Verification Results
${verificationResults}
#### Lessons Learned
1. ${lesson1}
2. ${lesson2}
#### Key Insights for Future
- ${insight1}
- ${insight2}
`
const existingContent = Read(understandingPath)
Write(understandingPath, existingContent + resolutionEntry)
```
### Step 3.3: 清理日志
```javascript
// 移除调试日志
// (可选,根据用户选择)
```
---
## State Updates
```javascript
return {
stateUpdates: {
debug: {
current_bug: bugDescription,
hypotheses: hypothesesData.hypotheses,
confirmed_hypothesis: confirmedHypothesis?.id || null,
iteration: hypothesesData.iteration,
last_analysis_at: getUtc8ISOString(),
understanding_updated: true
},
last_action: 'action-debug-with-file'
},
continue: true,
message: confirmedHypothesis
? `根因确认: ${confirmedHypothesis.description}\n修复已应用,请验证`
: `分析完成,需要更多证据\n请复现 bug 后再次执行`
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| 空 debug.log | 提示用户复现 bug |
| 所有假设被否定 | 使用 Gemini 生成新假设 |
| 修复无效 | 记录失败尝试,迭代 |
| >5 迭代 | 建议升级到 /workflow:lite-fix |
| Gemini 不可用 | 回退到手动分析 |
## Understanding Document Template
参考 [templates/understanding-template.md](../../templates/understanding-template.md)
## CLI Integration
### 假设生成
```bash
ccw cli -p "PURPOSE: Generate debugging hypotheses..." --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
### 证据分析
```bash
ccw cli -p "PURPOSE: Analyze debug log evidence..." --tool gemini --mode analysis --rule analysis-diagnose-bug-root-cause
```
### 生成修复
```bash
ccw cli -p "PURPOSE: Fix the identified root cause..." --tool gemini --mode write --rule development-debug-runtime-issues
```
## Next Actions (Hints)
- 根因确认: `action-validate-with-file` (验证修复)
- 需要更多证据: 等待用户复现,再次执行此动作
- 所有假设否定: 重新执行此动作生成新假设
- 用户选择: `action-menu` (返回菜单)

View File

@@ -0,0 +1,365 @@
# Action: Develop With File
增量开发任务执行,记录进度到 progress.md支持 Gemini 辅助实现。
## Purpose
执行开发任务并记录进度,包括:
- 分析任务需求
- 使用 Gemini/CLI 实现代码
- 记录代码变更
- 更新进度文档
## Preconditions
- [ ] state.status === 'running'
- [ ] state.skill_state !== null
- [ ] state.skill_state.develop.tasks.some(t => t.status === 'pending')
## Session Setup (Unified Location)
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
// 统一位置: .loop/{loopId}
const loopId = state.loop_id
const loopFile = `.loop/${loopId}.json`
const progressDir = `.loop/${loopId}.progress`
const progressPath = `${progressDir}/develop.md`
const changesLogPath = `${progressDir}/changes.log`
```
---
## Execution
### Step 0: Check Control Signals (CRITICAL)
```javascript
/**
* CRITICAL: 每个 Action 必须在开始时检查控制信号
* 如果 API 设置了 paused/stoppedSkill 应立即退出
*/
function checkControlSignals(loopId) {
const state = JSON.parse(Read(`.loop/${loopId}.json`))
switch (state.status) {
case 'paused':
console.log('⏸️ Loop paused by API. Exiting action.')
return { continue: false, reason: 'paused' }
case 'failed':
console.log('⏹️ Loop stopped by API. Exiting action.')
return { continue: false, reason: 'stopped' }
case 'running':
return { continue: true, reason: 'running' }
default:
return { continue: false, reason: 'unknown_status' }
}
}
// Execute check
const control = checkControlSignals(loopId)
if (!control.continue) {
return {
skillStateUpdates: { current_action: null },
continue: false,
message: `Action terminated: ${control.reason}`
}
}
```
### Step 1: 加载任务列表
```javascript
// 读取任务列表 (从 skill_state)
let tasks = state.skill_state?.develop?.tasks || []
// 如果任务列表为空,询问用户创建
if (tasks.length === 0) {
// 使用 Gemini 分析任务描述,生成任务列表
const analysisPrompt = `
PURPOSE: 分析开发任务并分解为可执行步骤
Success: 生成 3-7 个具体、可验证的子任务
TASK:
• 分析任务描述: ${state.task_description}
• 识别关键功能点
• 分解为独立子任务
• 为每个子任务指定工具和模式
MODE: analysis
CONTEXT: @package.json @src/**/*.ts | Memory: 项目结构
EXPECTED:
JSON 格式:
{
"tasks": [
{
"id": "task-001",
"description": "任务描述",
"tool": "gemini",
"mode": "write",
"files": ["src/xxx.ts"]
}
]
}
`
const result = await Task({
subagent_type: 'cli-execution-agent',
run_in_background: false,
prompt: `Execute Gemini CLI with prompt: ${analysisPrompt}`
})
tasks = JSON.parse(result).tasks
}
// 找到第一个待处理任务
const currentTask = tasks.find(t => t.status === 'pending')
if (!currentTask) {
return {
skillStateUpdates: {
develop: { ...state.skill_state.develop, current_task: null }
},
continue: true,
message: '所有开发任务已完成'
}
}
```
### Step 2: 执行开发任务
```javascript
console.log(`\n执行任务: ${currentTask.description}`)
// 更新任务状态
currentTask.status = 'in_progress'
// 使用 Gemini 实现
const implementPrompt = `
PURPOSE: 实现开发任务
Task: ${currentTask.description}
Success criteria: 代码实现完成,测试通过
TASK:
• 分析现有代码结构
• 实现功能代码
• 添加必要的类型定义
• 确保代码风格一致
MODE: write
CONTEXT: @${currentTask.files?.join(' @') || 'src/**/*.ts'}
EXPECTED:
- 完整的代码实现
- 代码变更列表
- 简要实现说明
CONSTRAINTS: 遵循现有代码风格 | 不破坏现有功能
`
const implementResult = await Bash({
command: `ccw cli -p "${implementPrompt}" --tool gemini --mode write --rule development-implement-feature`,
run_in_background: false
})
// 记录代码变更
const timestamp = getUtc8ISOString()
const changeEntry = {
timestamp,
task_id: currentTask.id,
description: currentTask.description,
files_changed: currentTask.files || [],
result: 'success'
}
// 追加到 changes.log (NDJSON 格式)
const changesContent = Read(changesLogPath) || ''
Write(changesLogPath, changesContent + JSON.stringify(changeEntry) + '\n')
```
### Step 3: 更新进度文档
```javascript
const timestamp = getUtc8ISOString()
const iteration = state.develop.completed_count + 1
// 读取现有进度文档
let progressContent = Read(progressPath) || ''
// 如果是新文档,添加头部
if (!progressContent) {
progressContent = `# Development Progress
**Session ID**: ${state.session_id}
**Task**: ${state.task_description}
**Started**: ${timestamp}
---
## Progress Timeline
`
}
// 追加本次进度
const progressEntry = `
### Iteration ${iteration} - ${currentTask.description} (${timestamp})
#### Task Details
- **ID**: ${currentTask.id}
- **Tool**: ${currentTask.tool}
- **Mode**: ${currentTask.mode}
#### Implementation Summary
${implementResult.summary || '实现完成'}
#### Files Changed
${currentTask.files?.map(f => `- \`${f}\``).join('\n') || '- No files specified'}
#### Status: COMPLETED
---
`
Write(progressPath, progressContent + progressEntry)
// 更新任务状态
currentTask.status = 'completed'
currentTask.completed_at = timestamp
```
### Step 4: 更新任务列表文件
```javascript
// 更新 tasks.json
const updatedTasks = tasks.map(t =>
t.id === currentTask.id ? currentTask : t
)
Write(tasksPath, JSON.stringify(updatedTasks, null, 2))
```
## State Updates
```javascript
return {
stateUpdates: {
develop: {
tasks: updatedTasks,
current_task_id: null,
completed_count: state.develop.completed_count + 1,
total_count: updatedTasks.length,
last_progress_at: getUtc8ISOString()
},
last_action: 'action-develop-with-file'
},
continue: true,
message: `任务完成: ${currentTask.description}\n进度: ${state.develop.completed_count + 1}/${updatedTasks.length}`
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| Gemini CLI 失败 | 提示用户手动实现,记录到 progress.md |
| 文件写入失败 | 重试一次,失败则记录错误 |
| 任务解析失败 | 询问用户手动输入任务 |
## Progress Document Template
```markdown
# Development Progress
**Session ID**: LOOP-xxx-2026-01-22
**Task**: 实现用户认证功能
**Started**: 2026-01-22T10:00:00+08:00
---
## Progress Timeline
### Iteration 1 - 分析登录组件 (2026-01-22T10:05:00+08:00)
#### Task Details
- **ID**: task-001
- **Tool**: gemini
- **Mode**: analysis
#### Implementation Summary
分析了现有登录组件结构,识别了需要修改的文件和依赖关系。
#### Files Changed
- `src/components/Login.tsx`
- `src/hooks/useAuth.ts`
#### Status: COMPLETED
---
### Iteration 2 - 实现登录 API (2026-01-22T10:15:00+08:00)
...
---
## Current Statistics
| Metric | Value |
|--------|-------|
| Total Tasks | 5 |
| Completed | 2 |
| In Progress | 1 |
| Pending | 2 |
| Progress | 40% |
---
## Next Steps
- [ ] 完成剩余任务
- [ ] 运行测试
- [ ] 代码审查
```
## CLI Integration
### 任务分析
```bash
ccw cli -p "PURPOSE: 分解开发任务为子任务
TASK: • 分析任务描述 • 识别功能点 • 生成任务列表
MODE: analysis
CONTEXT: @package.json @src/**/*
EXPECTED: JSON 任务列表
" --tool gemini --mode analysis --rule planning-breakdown-task-steps
```
### 代码实现
```bash
ccw cli -p "PURPOSE: 实现功能代码
TASK: • 分析需求 • 编写代码 • 添加类型
MODE: write
CONTEXT: @src/xxx.ts
EXPECTED: 完整实现
" --tool gemini --mode write --rule development-implement-feature
```
## Next Actions (Hints)
- 所有任务完成: `action-debug-with-file` (开始调试)
- 任务失败: `action-develop-with-file` (重试或下一个任务)
- 用户选择: `action-menu` (返回菜单)

View File

@@ -0,0 +1,200 @@
# Action: Initialize
初始化 CCW Loop 会话,创建目录结构和初始状态。
## Purpose
- 创建会话目录结构
- 初始化状态文件
- 分析任务描述生成初始任务列表
- 准备执行环境
## Preconditions
- [ ] state.status === 'pending'
- [ ] state.initialized === false
## Execution
### Step 1: 创建目录结构
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const taskSlug = state.task_description.toLowerCase().replace(/[^a-z0-9]+/g, '-').substring(0, 30)
const dateStr = getUtc8ISOString().substring(0, 10)
const sessionId = `LOOP-${taskSlug}-${dateStr}`
const sessionFolder = `.workflow/.loop/${sessionId}`
Bash(`mkdir -p "${sessionFolder}/develop"`)
Bash(`mkdir -p "${sessionFolder}/debug"`)
Bash(`mkdir -p "${sessionFolder}/validate"`)
console.log(`Session created: ${sessionId}`)
console.log(`Location: ${sessionFolder}`)
```
### Step 2: 创建元数据文件
```javascript
const meta = {
session_id: sessionId,
task_description: state.task_description,
created_at: getUtc8ISOString(),
mode: state.mode || 'interactive'
}
Write(`${sessionFolder}/meta.json`, JSON.stringify(meta, null, 2))
```
### Step 3: 分析任务生成开发任务列表
```javascript
// 使用 Gemini 分析任务描述
console.log('\n分析任务描述...')
const analysisPrompt = `
PURPOSE: 分析开发任务并分解为可执行步骤
Success: 生成 3-7 个具体、可验证的子任务
TASK:
• 分析任务描述: ${state.task_description}
• 识别关键功能点
• 分解为独立子任务
• 为每个子任务指定工具和模式
MODE: analysis
CONTEXT: @package.json @src/**/*.ts (如存在)
EXPECTED:
JSON 格式:
{
"tasks": [
{
"id": "task-001",
"description": "任务描述",
"tool": "gemini",
"mode": "write",
"priority": 1
}
],
"estimated_complexity": "low|medium|high",
"key_files": ["file1.ts", "file2.ts"]
}
CONSTRAINTS: 生成实际可执行的任务
`
const result = await Bash({
command: `ccw cli -p "${analysisPrompt}" --tool gemini --mode analysis --rule planning-breakdown-task-steps`,
run_in_background: false
})
const analysis = JSON.parse(result.stdout)
const tasks = analysis.tasks.map((t, i) => ({
...t,
id: t.id || `task-${String(i + 1).padStart(3, '0')}`,
status: 'pending',
created_at: getUtc8ISOString(),
completed_at: null,
files_changed: []
}))
// 保存任务列表
Write(`${sessionFolder}/develop/tasks.json`, JSON.stringify(tasks, null, 2))
```
### Step 4: 初始化进度文档
```javascript
const progressInitial = `# Development Progress
**Session ID**: ${sessionId}
**Task**: ${state.task_description}
**Started**: ${getUtc8ISOString()}
**Estimated Complexity**: ${analysis.estimated_complexity}
---
## Task List
${tasks.map((t, i) => `${i + 1}. [ ] ${t.description}`).join('\n')}
## Key Files
${analysis.key_files?.map(f => `- \`${f}\``).join('\n') || '- To be determined'}
---
## Progress Timeline
`
Write(`${sessionFolder}/develop/progress.md`, progressInitial)
```
### Step 5: 显示初始化结果
```javascript
console.log(`\n✅ 会话初始化完成`)
console.log(`\n任务列表 (${tasks.length} 项):`)
tasks.forEach((t, i) => {
console.log(` ${i + 1}. ${t.description} [${t.tool}/${t.mode}]`)
})
console.log(`\n预估复杂度: ${analysis.estimated_complexity}`)
console.log(`\n执行 'develop' 开始开发,或 'menu' 查看更多选项`)
```
## State Updates
```javascript
return {
stateUpdates: {
session_id: sessionId,
status: 'running',
initialized: true,
develop: {
tasks: tasks,
current_task_id: null,
completed_count: 0,
total_count: tasks.length,
last_progress_at: null
},
debug: {
current_bug: null,
hypotheses: [],
confirmed_hypothesis: null,
iteration: 0,
last_analysis_at: null,
understanding_updated: false
},
validate: {
test_results: [],
coverage: null,
passed: false,
failed_tests: [],
last_run_at: null
},
context: {
estimated_complexity: analysis.estimated_complexity,
key_files: analysis.key_files
}
},
continue: true,
message: `会话 ${sessionId} 已初始化\n${tasks.length} 个开发任务待执行`
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| 目录创建失败 | 检查权限,重试 |
| Gemini 分析失败 | 提示用户手动输入任务 |
| 任务解析失败 | 使用默认任务列表 |
## Next Actions
- 成功: `action-menu` (显示操作菜单) 或 `action-develop-with-file` (直接开始开发)
- 失败: 报错退出

View File

@@ -0,0 +1,192 @@
# Action: Menu
显示交互式操作菜单,让用户选择下一步操作。
## Purpose
- 显示当前状态摘要
- 提供操作选项
- 接收用户选择
- 返回下一个动作
## Preconditions
- [ ] state.initialized === true
- [ ] state.status === 'running'
## Execution
### Step 1: 生成状态摘要
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
// 开发进度
const developProgress = state.develop.total_count > 0
? `${state.develop.completed_count}/${state.develop.total_count} (${(state.develop.completed_count / state.develop.total_count * 100).toFixed(0)}%)`
: '未开始'
// 调试状态
const debugStatus = state.debug.confirmed_hypothesis
? `✅ 已确认根因`
: state.debug.iteration > 0
? `🔍 迭代 ${state.debug.iteration}`
: '未开始'
// 验证状态
const validateStatus = state.validate.passed
? `✅ 通过`
: state.validate.test_results.length > 0
? `${state.validate.failed_tests.length} 个失败`
: '未运行'
const statusSummary = `
═══════════════════════════════════════════════════════════
CCW Loop - ${state.session_id}
═══════════════════════════════════════════════════════════
任务: ${state.task_description}
迭代: ${state.iteration_count}
┌─────────────────────────────────────────────────────┐
│ 开发 (Develop) │ ${developProgress.padEnd(20)}
│ 调试 (Debug) │ ${debugStatus.padEnd(20)}
│ 验证 (Validate) │ ${validateStatus.padEnd(20)}
└─────────────────────────────────────────────────────┘
═══════════════════════════════════════════════════════════
`
console.log(statusSummary)
```
### Step 2: 显示操作选项
```javascript
const options = [
{
label: "📝 继续开发 (Develop)",
description: state.develop.completed_count < state.develop.total_count
? `执行下一个开发任务`
: "所有任务已完成,可添加新任务",
action: "action-develop-with-file"
},
{
label: "🔍 开始调试 (Debug)",
description: state.debug.iteration > 0
? "继续假设驱动调试"
: "开始新的调试会话",
action: "action-debug-with-file"
},
{
label: "✅ 运行验证 (Validate)",
description: "运行测试并检查覆盖率",
action: "action-validate-with-file"
},
{
label: "📊 查看详情 (Status)",
description: "查看详细进度和文件",
action: "action-status"
},
{
label: "🏁 完成循环 (Complete)",
description: "结束当前循环",
action: "action-complete"
},
{
label: "🚪 退出 (Exit)",
description: "保存状态并退出",
action: "exit"
}
]
const response = await AskUserQuestion({
questions: [{
question: "选择下一步操作:",
header: "操作",
multiSelect: false,
options: options.map(o => ({
label: o.label,
description: o.description
}))
}]
})
const selectedLabel = response["操作"]
const selectedOption = options.find(o => o.label === selectedLabel)
const nextAction = selectedOption?.action || 'action-menu'
```
### Step 3: 处理特殊选项
```javascript
if (nextAction === 'exit') {
console.log('\n保存状态并退出...')
return {
stateUpdates: {
status: 'user_exit'
},
continue: false,
message: '会话已保存,使用 --resume 可继续'
}
}
if (nextAction === 'action-status') {
// 显示详细状态
const sessionFolder = `.workflow/.loop/${state.session_id}`
console.log('\n=== 开发进度 ===')
const progress = Read(`${sessionFolder}/develop/progress.md`)
console.log(progress?.substring(0, 500) + '...')
console.log('\n=== 调试状态 ===')
if (state.debug.hypotheses.length > 0) {
state.debug.hypotheses.forEach(h => {
console.log(` ${h.id}: ${h.status} - ${h.description.substring(0, 50)}...`)
})
} else {
console.log(' 尚未开始调试')
}
console.log('\n=== 验证结果 ===')
if (state.validate.test_results.length > 0) {
const latest = state.validate.test_results[state.validate.test_results.length - 1]
console.log(` 最近运行: ${latest.timestamp}`)
console.log(` 通过率: ${latest.summary.pass_rate}%`)
} else {
console.log(' 尚未运行验证')
}
// 返回菜单
return {
stateUpdates: {},
continue: true,
nextAction: 'action-menu',
message: ''
}
}
```
## State Updates
```javascript
return {
stateUpdates: {
// 不更新状态,仅返回下一个动作
},
continue: true,
nextAction: nextAction,
message: `执行: ${selectedOption?.label || nextAction}`
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| 用户取消 | 返回菜单 |
| 无效选择 | 重新显示菜单 |
## Next Actions
根据用户选择动态决定下一个动作。

View File

@@ -0,0 +1,307 @@
# Action: Validate With File
运行测试并验证实现,记录结果到 validation.md支持 Gemini 辅助分析测试覆盖率和质量。
## Purpose
执行测试验证流程,包括:
- 运行单元测试
- 运行集成测试
- 检查代码覆盖率
- 生成验证报告
- 分析失败原因
## Preconditions
- [ ] state.initialized === true
- [ ] state.status === 'running'
- [ ] state.develop.completed_count > 0 || state.debug.confirmed_hypothesis !== null
## Session Setup
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
const sessionFolder = `.workflow/.loop/${state.session_id}`
const validateFolder = `${sessionFolder}/validate`
const validationPath = `${validateFolder}/validation.md`
const testResultsPath = `${validateFolder}/test-results.json`
const coveragePath = `${validateFolder}/coverage.json`
```
---
## Execution
### Step 1: 运行测试
```javascript
console.log('\n运行测试...')
// 检测测试框架
const packageJson = JSON.parse(Read('package.json'))
const testScript = packageJson.scripts?.test || 'npm test'
// 运行测试并捕获输出
const testResult = await Bash({
command: testScript,
timeout: 300000 // 5分钟
})
// 解析测试输出
const testResults = parseTestOutput(testResult.stdout)
```
### Step 2: 检查覆盖率
```javascript
// 运行覆盖率检查
let coverageData = null
if (packageJson.scripts?.['test:coverage']) {
const coverageResult = await Bash({
command: 'npm run test:coverage',
timeout: 300000
})
// 解析覆盖率报告
coverageData = parseCoverageReport(coverageResult.stdout)
Write(coveragePath, JSON.stringify(coverageData, null, 2))
}
```
### Step 3: Gemini 辅助分析
```bash
ccw cli -p "
PURPOSE: Analyze test results and coverage
Success criteria: Identify quality issues and suggest improvements
TASK:
• Analyze test execution results
• Review code coverage metrics
• Identify missing test cases
• Suggest quality improvements
• Verify requirements coverage
MODE: analysis
CONTEXT:
@${testResultsPath}
@${coveragePath}
@${sessionFolder}/develop/progress.md
EXPECTED:
- Quality assessment report
- Failed tests analysis
- Coverage gaps identification
- Improvement recommendations
- Pass/Fail decision with rationale
CONSTRAINTS: Evidence-based quality assessment
" --tool gemini --mode analysis --rule analysis-review-code-quality
```
### Step 4: 生成验证报告
```javascript
const timestamp = getUtc8ISOString()
const iteration = (state.validate.test_results?.length || 0) + 1
const validationReport = `# Validation Report
**Session ID**: ${state.session_id}
**Task**: ${state.task_description}
**Validated**: ${timestamp}
---
## Iteration ${iteration} - Validation Run
### Test Execution Summary
| Metric | Value |
|--------|-------|
| Total Tests | ${testResults.total} |
| Passed | ${testResults.passed} |
| Failed | ${testResults.failed} |
| Skipped | ${testResults.skipped} |
| Duration | ${testResults.duration_ms}ms |
| **Pass Rate** | **${(testResults.passed / testResults.total * 100).toFixed(1)}%** |
### Coverage Report
${coverageData ? `
| File | Statements | Branches | Functions | Lines |
|------|------------|----------|-----------|-------|
${coverageData.files.map(f => `| ${f.path} | ${f.statements}% | ${f.branches}% | ${f.functions}% | ${f.lines}% |`).join('\n')}
**Overall Coverage**: ${coverageData.overall.statements}%
` : '_No coverage data available_'}
### Failed Tests
${testResults.failed > 0 ? `
${testResults.failures.map(f => `
#### ${f.test_name}
- **Suite**: ${f.suite}
- **Error**: ${f.error_message}
- **Stack**:
\`\`\`
${f.stack_trace}
\`\`\`
`).join('\n')}
` : '_All tests passed_'}
### Gemini Quality Analysis
${geminiAnalysis}
### Recommendations
${recommendations.map(r => `- ${r}`).join('\n')}
---
## Validation Decision
**Result**: ${testResults.passed === testResults.total ? '✅ PASS' : '❌ FAIL'}
**Rationale**: ${validationDecision}
${testResults.passed !== testResults.total ? `
### Next Actions
1. Review failed tests
2. Debug failures using action-debug-with-file
3. Fix issues and re-run validation
` : `
### Next Actions
1. Consider code review
2. Prepare for deployment
3. Update documentation
`}
`
// 写入验证报告
Write(validationPath, validationReport)
```
### Step 5: 保存测试结果
```javascript
const testResultsData = {
iteration,
timestamp,
summary: {
total: testResults.total,
passed: testResults.passed,
failed: testResults.failed,
skipped: testResults.skipped,
pass_rate: (testResults.passed / testResults.total * 100).toFixed(1),
duration_ms: testResults.duration_ms
},
tests: testResults.tests,
failures: testResults.failures,
coverage: coverageData?.overall || null
}
Write(testResultsPath, JSON.stringify(testResultsData, null, 2))
```
---
## State Updates
```javascript
const validationPassed = testResults.failed === 0 && testResults.passed > 0
return {
stateUpdates: {
validate: {
test_results: [...(state.validate.test_results || []), testResultsData],
coverage: coverageData?.overall.statements || null,
passed: validationPassed,
failed_tests: testResults.failures.map(f => f.test_name),
last_run_at: getUtc8ISOString()
},
last_action: 'action-validate-with-file'
},
continue: true,
message: validationPassed
? `验证通过 ✅\n测试: ${testResults.passed}/${testResults.total}\n覆盖率: ${coverageData?.overall.statements || 'N/A'}%`
: `验证失败 ❌\n失败: ${testResults.failed}/${testResults.total}\n建议进入调试模式`
}
```
## Test Output Parsers
### Jest/Vitest Parser
```javascript
function parseJestOutput(stdout) {
const testPattern = /Tests:\s+(\d+) passed.*?(\d+) failed.*?(\d+) total/
const match = stdout.match(testPattern)
return {
total: parseInt(match[3]),
passed: parseInt(match[1]),
failed: parseInt(match[2]),
// ... parse individual test results
}
}
```
### Pytest Parser
```javascript
function parsePytestOutput(stdout) {
const summaryPattern = /(\d+) passed.*?(\d+) failed.*?(\d+) error/
// ... implementation
}
```
## Error Handling
| Error Type | Recovery |
|------------|----------|
| Tests don't run | 检查测试脚本配置,提示用户 |
| All tests fail | 建议进入 debug 模式 |
| Coverage tool missing | 跳过覆盖率检查,仅运行测试 |
| Timeout | 增加超时时间或拆分测试 |
## Validation Report Template
参考 [templates/validation-template.md](../../templates/validation-template.md)
## CLI Integration
### 质量分析
```bash
ccw cli -p "PURPOSE: Analyze test results and coverage...
TASK: • Review results • Identify gaps • Suggest improvements
MODE: analysis
CONTEXT: @test-results.json @coverage.json
EXPECTED: Quality assessment
" --tool gemini --mode analysis --rule analysis-review-code-quality
```
### 测试生成 (如覆盖率低)
```bash
ccw cli -p "PURPOSE: Generate missing test cases...
TASK: • Analyze uncovered code • Write tests
MODE: write
CONTEXT: @coverage.json @src/**/*
EXPECTED: Test code
" --tool gemini --mode write --rule development-generate-tests
```
## Next Actions (Hints)
- 验证通过: `action-complete` (完成循环)
- 验证失败: `action-debug-with-file` (调试失败测试)
- 覆盖率低: `action-develop-with-file` (添加测试)
- 用户选择: `action-menu` (返回菜单)

View File

@@ -0,0 +1,486 @@
# Orchestrator
根据当前状态选择并执行下一个动作,实现无状态循环工作流。与 API (loop-v2-routes.ts) 协作实现控制平面/执行平面分离。
## Role
检查控制信号 → 读取文件状态 → 选择动作 → 执行 → 更新文件 → 循环,直到完成或被外部暂停/停止。
## State Management (Unified Location)
### 读取状态
```javascript
const getUtc8ISOString = () => new Date(Date.now() + 8 * 60 * 60 * 1000).toISOString()
/**
* 读取循环状态 (统一位置)
* @param loopId - Loop ID (e.g., "loop-v2-20260122-abc123")
*/
function readLoopState(loopId) {
const stateFile = `.loop/${loopId}.json`
if (!fs.existsSync(stateFile)) {
return null
}
const state = JSON.parse(Read(stateFile))
return state
}
```
### 更新状态
```javascript
/**
* 更新循环状态 (只更新 skill_state 部分,不修改 API 字段)
* @param loopId - Loop ID
* @param updates - 更新内容 (skill_state 字段)
*/
function updateLoopState(loopId, updates) {
const stateFile = `.loop/${loopId}.json`
const currentState = readLoopState(loopId)
if (!currentState) {
throw new Error(`Loop state not found: ${loopId}`)
}
// 只更新 skill_state 和 updated_at
const newState = {
...currentState,
updated_at: getUtc8ISOString(),
skill_state: {
...currentState.skill_state,
...updates
}
}
Write(stateFile, JSON.stringify(newState, null, 2))
return newState
}
```
### 创建新循环状态 (直接调用时)
```javascript
/**
* 创建新的循环状态 (仅在直接调用时使用API 触发时状态已存在)
*/
function createLoopState(loopId, taskDescription) {
const stateFile = `.loop/${loopId}.json`
const now = getUtc8ISOString()
const state = {
// API 兼容字段
loop_id: loopId,
title: taskDescription.substring(0, 100),
description: taskDescription,
max_iterations: 10,
status: 'running', // 直接调用时设为 running
current_iteration: 0,
created_at: now,
updated_at: now,
// Skill 扩展字段
skill_state: null // 由 action-init 初始化
}
// 确保目录存在
Bash(`mkdir -p ".loop"`)
Bash(`mkdir -p ".loop/${loopId}.progress"`)
Write(stateFile, JSON.stringify(state, null, 2))
return state
}
```
## Control Signal Checking
```javascript
/**
* 检查 API 控制信号
* 必须在每个 Action 开始前调用
* @returns { continue: boolean, reason: string }
*/
function checkControlSignals(loopId) {
const state = readLoopState(loopId)
if (!state) {
return { continue: false, reason: 'state_not_found' }
}
switch (state.status) {
case 'paused':
// API 暂停了循环Skill 应退出等待 resume
console.log(`⏸️ Loop paused by API. Waiting for resume...`)
return { continue: false, reason: 'paused' }
case 'failed':
// API 停止了循环 (用户手动停止)
console.log(`⏹️ Loop stopped by API.`)
return { continue: false, reason: 'stopped' }
case 'completed':
// 已完成
console.log(`✅ Loop already completed.`)
return { continue: false, reason: 'completed' }
case 'created':
// API 创建但未启动 (不应该走到这里)
console.log(`⚠️ Loop not started by API.`)
return { continue: false, reason: 'not_started' }
case 'running':
// 正常继续
return { continue: true, reason: 'running' }
default:
console.log(`⚠️ Unknown status: ${state.status}`)
return { continue: false, reason: 'unknown_status' }
}
}
```
## Decision Logic
```javascript
/**
* 选择下一个 Action (基于 skill_state)
*/
function selectNextAction(state, mode = 'interactive') {
const skillState = state.skill_state
// 1. 终止条件检查 (API status)
if (state.status === 'completed') return null
if (state.status === 'failed') return null
if (state.current_iteration >= state.max_iterations) {
console.warn(`已达到最大迭代次数 (${state.max_iterations})`)
return 'action-complete'
}
// 2. 初始化检查
if (!skillState || !skillState.current_action) {
return 'action-init'
}
// 3. 模式判断
if (mode === 'interactive') {
return 'action-menu' // 显示菜单让用户选择
}
// 4. 自动模式:基于状态自动选择
if (mode === 'auto') {
// 按优先级develop → debug → validate
// 如果有待开发任务
const hasPendingDevelop = skillState.develop?.tasks?.some(t => t.status === 'pending')
if (hasPendingDevelop) {
return 'action-develop-with-file'
}
// 如果开发完成但未调试
if (skillState.last_action === 'action-develop-with-file') {
const needsDebug = skillState.develop?.completed < skillState.develop?.total
if (needsDebug) {
return 'action-debug-with-file'
}
}
// 如果调试完成但未验证
if (skillState.last_action === 'action-debug-with-file' ||
skillState.debug?.confirmed_hypothesis) {
return 'action-validate-with-file'
}
// 如果验证失败,回到开发
if (skillState.last_action === 'action-validate-with-file') {
if (!skillState.validate?.passed) {
return 'action-develop-with-file'
}
}
// 全部通过,完成
if (skillState.validate?.passed && !hasPendingDevelop) {
return 'action-complete'
}
// 默认:开发
return 'action-develop-with-file'
}
// 5. 默认完成
return 'action-complete'
}
```
## Execution Loop
```javascript
/**
* 运行编排器
* @param options.loopId - 现有 Loop ID (API 触发时)
* @param options.task - 任务描述 (直接调用时)
* @param options.mode - 'interactive' | 'auto'
*/
async function runOrchestrator(options = {}) {
const { loopId: existingLoopId, task, mode = 'interactive' } = options
console.log('=== CCW Loop Orchestrator Started ===')
// 1. 确定 loopId
let loopId
let state
if (existingLoopId) {
// API 触发:使用现有 loopId
loopId = existingLoopId
state = readLoopState(loopId)
if (!state) {
console.error(`Loop not found: ${loopId}`)
return { status: 'error', message: 'Loop not found' }
}
console.log(`Resuming loop: ${loopId}`)
console.log(`Status: ${state.status}`)
} else if (task) {
// 直接调用:创建新 loopId
const timestamp = getUtc8ISOString().replace(/[-:]/g, '').split('.')[0]
const random = Math.random().toString(36).substring(2, 10)
loopId = `loop-v2-${timestamp}-${random}`
console.log(`Creating new loop: ${loopId}`)
console.log(`Task: ${task}`)
state = createLoopState(loopId, task)
} else {
console.error('Either --loop-id or task description is required')
return { status: 'error', message: 'Missing loopId or task' }
}
const progressDir = `.loop/${loopId}.progress`
// 2. 主循环
let iteration = state.current_iteration || 0
while (iteration < state.max_iterations) {
iteration++
// ========================================
// CRITICAL: Check control signals first
// ========================================
const control = checkControlSignals(loopId)
if (!control.continue) {
console.log(`\n🛑 Loop terminated: ${control.reason}`)
break
}
// 重新读取状态 (可能被 API 更新)
state = readLoopState(loopId)
console.log(`\n[Iteration ${iteration}] Status: ${state.status}`)
// 选择下一个动作
const actionId = selectNextAction(state, mode)
if (!actionId) {
console.log('No action selected, terminating.')
break
}
console.log(`[Iteration ${iteration}] Executing: ${actionId}`)
// 更新 current_iteration
state = {
...state,
current_iteration: iteration,
updated_at: getUtc8ISOString()
}
Write(`.loop/${loopId}.json`, JSON.stringify(state, null, 2))
// 执行动作
try {
const actionPromptFile = `.claude/skills/ccw-loop/phases/actions/${actionId}.md`
if (!fs.existsSync(actionPromptFile)) {
console.error(`Action file not found: ${actionPromptFile}`)
continue
}
const actionPrompt = Read(actionPromptFile)
// 构建 Agent 提示
const agentPrompt = `
[LOOP CONTEXT]
Loop ID: ${loopId}
State File: .loop/${loopId}.json
Progress Dir: ${progressDir}
[CURRENT STATE]
${JSON.stringify(state, null, 2)}
[ACTION INSTRUCTIONS]
${actionPrompt}
[TASK]
You are executing ${actionId} for loop: ${state.title || state.description}
[CONTROL SIGNALS]
Before executing, check if status is still 'running'.
If status is 'paused' or 'failed', exit gracefully.
[RETURN]
Return JSON with:
- skillStateUpdates: Object with skill_state fields to update
- continue: Boolean indicating if loop should continue
- message: String with user message
`
const result = await Task({
subagent_type: 'universal-executor',
run_in_background: false,
description: `Execute ${actionId}`,
prompt: agentPrompt
})
// 解析结果
const actionResult = JSON.parse(result)
// 更新状态 (只更新 skill_state)
updateLoopState(loopId, {
current_action: null,
last_action: actionId,
completed_actions: [
...(state.skill_state?.completed_actions || []),
actionId
],
...actionResult.skillStateUpdates
})
// 显示消息
if (actionResult.message) {
console.log(`\n${actionResult.message}`)
}
// 检查是否继续
if (actionResult.continue === false) {
console.log('Action requested termination.')
break
}
} catch (error) {
console.error(`Error executing ${actionId}: ${error.message}`)
// 错误处理
updateLoopState(loopId, {
current_action: null,
errors: [
...(state.skill_state?.errors || []),
{
action: actionId,
message: error.message,
timestamp: getUtc8ISOString()
}
]
})
}
}
if (iteration >= state.max_iterations) {
console.log(`\n⚠️ Reached maximum iterations (${state.max_iterations})`)
console.log('Consider breaking down the task or taking a break.')
}
console.log('\n=== CCW Loop Orchestrator Finished ===')
// 返回最终状态
const finalState = readLoopState(loopId)
return {
status: finalState.status,
loop_id: loopId,
iterations: iteration,
final_state: finalState
}
}
```
## Action Catalog
| Action | Purpose | Preconditions | Effects |
|--------|---------|---------------|---------|
| [action-init](actions/action-init.md) | 初始化会话 | status=pending | initialized=true |
| [action-menu](actions/action-menu.md) | 显示操作菜单 | initialized=true | 用户选择下一动作 |
| [action-develop-with-file](actions/action-develop-with-file.md) | 开发任务 | initialized=true | 更新 progress.md |
| [action-debug-with-file](actions/action-debug-with-file.md) | 假设调试 | initialized=true | 更新 understanding.md |
| [action-validate-with-file](actions/action-validate-with-file.md) | 测试验证 | initialized=true | 更新 validation.md |
| [action-complete](actions/action-complete.md) | 完成循环 | validation_passed=true | status=completed |
## Termination Conditions
1. **API 暂停**: `state.status === 'paused'` (Skill 退出,等待 resume)
2. **API 停止**: `state.status === 'failed'` (Skill 终止)
3. **任务完成**: `state.status === 'completed'`
4. **迭代限制**: `state.current_iteration >= state.max_iterations`
5. **Action 请求终止**: `actionResult.continue === false`
## Error Recovery
| Error Type | Recovery Strategy |
|------------|-------------------|
| 动作执行失败 | 记录错误,增加 error_count继续下一动作 |
| 状态文件损坏 | 从其他文件重建状态 (progress.md, understanding.md 等) |
| 用户中止 | 保存当前状态,允许 --resume 恢复 |
| CLI 工具失败 | 回退到手动分析模式 |
## Mode Strategies
### Interactive Mode (默认)
每次显示菜单,让用户选择动作:
```
当前状态: 开发中
可用操作:
1. 继续开发 (develop)
2. 开始调试 (debug)
3. 运行验证 (validate)
4. 查看进度 (status)
5. 退出 (exit)
请选择:
```
### Auto Mode (自动循环)
按预设流程自动执行:
```
Develop → Debug → Validate →
↓ (如验证失败)
Develop (修复) → Debug → Validate → 完成
```
## State Machine (API Status)
```mermaid
stateDiagram-v2
[*] --> created: API creates loop
created --> running: API /start → Trigger Skill
running --> paused: API /pause → Set status
running --> completed: action-complete
running --> failed: API /stop OR error
paused --> running: API /resume → Re-trigger Skill
completed --> [*]
failed --> [*]
note right of paused
Skill checks status before each action
If paused, Skill exits gracefully
end note
note right of running
Skill executes: init → develop → debug → validate
end note
```

View File

@@ -0,0 +1,474 @@
# State Schema
CCW Loop 的状态结构定义(统一版本)。
## 状态文件
**位置**: `.loop/{loopId}.json` (统一位置API + Skill 共享)
**旧版本位置** (仅向后兼容): `.workflow/.loop/{session-id}/state.json`
## 结构定义
### 统一状态接口 (Unified Loop State)
```typescript
/**
* Unified Loop State - API 和 Skill 共享的状态结构
* API (loop-v2-routes.ts) 拥有状态的主控权
* Skill (ccw-loop) 读取和更新此状态
*/
interface LoopState {
// =====================================================
// API FIELDS (from loop-v2-routes.ts)
// 这些字段由 API 管理Skill 只读
// =====================================================
loop_id: string // Loop ID, e.g., "loop-v2-20260122-abc123"
title: string // Loop 标题
description: string // Loop 描述
max_iterations: number // 最大迭代次数
status: 'created' | 'running' | 'paused' | 'completed' | 'failed'
current_iteration: number // 当前迭代次数
created_at: string // 创建时间 (ISO8601)
updated_at: string // 最后更新时间 (ISO8601)
completed_at?: string // 完成时间 (ISO8601)
failure_reason?: string // 失败原因
// =====================================================
// SKILL EXTENSION FIELDS
// 这些字段由 Skill 管理API 只读
// =====================================================
skill_state?: {
// 当前执行动作
current_action: 'init' | 'develop' | 'debug' | 'validate' | 'complete' | null
last_action: string | null
completed_actions: string[]
mode: 'interactive' | 'auto'
// === 开发阶段 ===
develop: {
total: number
completed: number
current_task?: string
tasks: DevelopTask[]
last_progress_at: string | null
}
// === 调试阶段 ===
debug: {
active_bug?: string
hypotheses_count: number
hypotheses: Hypothesis[]
confirmed_hypothesis: string | null
iteration: number
last_analysis_at: string | null
}
// === 验证阶段 ===
validate: {
pass_rate: number // 测试通过率 (0-100)
coverage: number // 覆盖率 (0-100)
test_results: TestResult[]
passed: boolean
failed_tests: string[]
last_run_at: string | null
}
// === 错误追踪 ===
errors: Array<{
action: string
message: string
timestamp: string
}>
}
}
interface DevelopTask {
id: string
description: string
tool: 'gemini' | 'qwen' | 'codex' | 'bash'
mode: 'analysis' | 'write'
status: 'pending' | 'in_progress' | 'completed' | 'failed'
files_changed: string[]
created_at: string
completed_at: string | null
}
interface Hypothesis {
id: string // H1, H2, ...
description: string
testable_condition: string
logging_point: string
evidence_criteria: {
confirm: string
reject: string
}
likelihood: number // 1 = 最可能
status: 'pending' | 'confirmed' | 'rejected' | 'inconclusive'
evidence: Record<string, any> | null
verdict_reason: string | null
}
interface TestResult {
test_name: string
suite: string
status: 'passed' | 'failed' | 'skipped'
duration_ms: number
error_message: string | null
stack_trace: string | null
}
```
## 初始状态
### 由 API 创建时 (Dashboard 触发)
```json
{
"loop_id": "loop-v2-20260122-abc123",
"title": "Implement user authentication",
"description": "Add login/logout functionality",
"max_iterations": 10,
"status": "created",
"current_iteration": 0,
"created_at": "2026-01-22T10:00:00+08:00",
"updated_at": "2026-01-22T10:00:00+08:00"
}
```
### 由 Skill 初始化后 (action-init)
```json
{
"loop_id": "loop-v2-20260122-abc123",
"title": "Implement user authentication",
"description": "Add login/logout functionality",
"max_iterations": 10,
"status": "running",
"current_iteration": 0,
"created_at": "2026-01-22T10:00:00+08:00",
"updated_at": "2026-01-22T10:00:05+08:00",
"skill_state": {
"current_action": "init",
"last_action": null,
"completed_actions": [],
"mode": "auto",
"develop": {
"total": 3,
"completed": 0,
"current_task": null,
"tasks": [
{ "id": "task-001", "description": "Create auth component", "status": "pending" }
],
"last_progress_at": null
},
"debug": {
"active_bug": null,
"hypotheses_count": 0,
"hypotheses": [],
"confirmed_hypothesis": null,
"iteration": 0,
"last_analysis_at": null
},
"validate": {
"pass_rate": 0,
"coverage": 0,
"test_results": [],
"passed": false,
"failed_tests": [],
"last_run_at": null
},
"errors": []
}
}
```
## 控制信号检查 (Control Signals)
Skill 在每个 Action 开始前必须检查控制信号:
```javascript
/**
* 检查 API 控制信号
* @returns { continue: boolean, action: 'pause_exit' | 'stop_exit' | 'continue' }
*/
function checkControlSignals(loopId) {
const state = JSON.parse(Read(`.loop/${loopId}.json`))
switch (state.status) {
case 'paused':
// API 暂停了循环Skill 应退出等待 resume
return { continue: false, action: 'pause_exit' }
case 'failed':
// API 停止了循环 (用户手动停止)
return { continue: false, action: 'stop_exit' }
case 'running':
// 正常继续
return { continue: true, action: 'continue' }
default:
// 异常状态
return { continue: false, action: 'stop_exit' }
}
}
```
### 在 Action 中使用
```markdown
## Execution
### Step 1: Check Control Signals
\`\`\`javascript
const control = checkControlSignals(loopId)
if (!control.continue) {
// 输出退出原因
console.log(`Loop ${control.action}: status = ${state.status}`)
// 如果是 pause_exit保存当前进度
if (control.action === 'pause_exit') {
updateSkillState(loopId, { current_action: 'paused' })
}
return // 退出 Action
}
\`\`\`
### Step 2: Execute Action Logic
...
```
## 状态转换规则
### 1. 初始化 (action-init)
```javascript
// Skill 初始化后
{
// API 字段更新
status: 'created' 'running', // 或保持 'running' 如果 API 已设置
updated_at: timestamp,
// Skill 字段初始化
skill_state: {
current_action: 'init',
mode: 'auto',
develop: {
tasks: [...parsed_tasks],
total: N,
completed: 0
}
}
}
```
### 2. 开发进行中 (action-develop-with-file)
```javascript
// 开发任务执行后
{
updated_at: timestamp,
current_iteration: state.current_iteration + 1,
skill_state: {
current_action: 'develop',
last_action: 'action-develop-with-file',
completed_actions: [...state.skill_state.completed_actions, 'action-develop-with-file'],
develop: {
current_task: 'task-xxx',
completed: N+1,
last_progress_at: timestamp
}
}
}
```
### 3. 调试进行中 (action-debug-with-file)
```javascript
// 调试执行后
{
updated_at: timestamp,
current_iteration: state.current_iteration + 1,
skill_state: {
current_action: 'debug',
last_action: 'action-debug-with-file',
debug: {
active_bug: '...',
hypotheses_count: N,
hypotheses: [...new_hypotheses],
iteration: N+1,
last_analysis_at: timestamp
}
}
}
```
### 4. 验证完成 (action-validate-with-file)
```javascript
// 验证执行后
{
updated_at: timestamp,
current_iteration: state.current_iteration + 1,
skill_state: {
current_action: 'validate',
last_action: 'action-validate-with-file',
validate: {
test_results: [...results],
pass_rate: 95.5,
coverage: 85.0,
passed: true | false,
failed_tests: ['test1', 'test2'],
last_run_at: timestamp
}
}
}
```
### 5. 完成 (action-complete)
```javascript
// 循环完成后
{
status: 'running' 'completed',
completed_at: timestamp,
updated_at: timestamp,
skill_state: {
current_action: 'complete',
last_action: 'action-complete'
}
}
```
## 状态派生字段
以下字段可从状态计算得出,不需要存储:
```javascript
// 开发完成度
const developProgress = state.develop.total_count > 0
? (state.develop.completed_count / state.develop.total_count) * 100
: 0
// 是否有待开发任务
const hasPendingDevelop = state.develop.tasks.some(t => t.status === 'pending')
// 调试是否完成
const debugCompleted = state.debug.confirmed_hypothesis !== null
// 验证是否通过
const validationPassed = state.validate.passed && state.validate.test_results.length > 0
// 整体进度
const overallProgress = (
(developProgress * 0.5) +
(debugCompleted ? 25 : 0) +
(validationPassed ? 25 : 0)
)
```
## 文件同步
### 统一位置 (Unified Location)
状态与文件的对应关系:
| 状态字段 | 同步文件 | 同步时机 |
|----------|----------|----------|
| 整个 LoopState | `.loop/{loopId}.json` | 每次状态变更 (主文件) |
| `skill_state.develop` | `.loop/{loopId}.progress/develop.md` | 每次开发操作后 |
| `skill_state.debug` | `.loop/{loopId}.progress/debug.md` | 每次调试操作后 |
| `skill_state.validate` | `.loop/{loopId}.progress/validate.md` | 每次验证操作后 |
| 代码变更日志 | `.loop/{loopId}.progress/changes.log` | 每次文件修改 (NDJSON) |
| 调试日志 | `.loop/{loopId}.progress/debug.log` | 每次调试日志 (NDJSON) |
### 文件结构示例
```
.loop/
├── loop-v2-20260122-abc123.json # 主状态文件 (API + Skill)
├── loop-v2-20260122-abc123.tasks.jsonl # 任务列表 (API 管理)
└── loop-v2-20260122-abc123.progress/ # Skill 进度文件
├── develop.md # 开发进度
├── debug.md # 调试理解
├── validate.md # 验证报告
├── changes.log # 代码变更 (NDJSON)
└── debug.log # 调试日志 (NDJSON)
```
## 状态恢复
如果主状态文件 `.loop/{loopId}.json` 损坏,可以从进度文件重建 skill_state:
```javascript
function rebuildSkillStateFromProgress(loopId) {
const progressDir = `.loop/${loopId}.progress`
// 尝试从进度文件解析状态
const skill_state = {
develop: parseProgressFile(`${progressDir}/develop.md`),
debug: parseProgressFile(`${progressDir}/debug.md`),
validate: parseProgressFile(`${progressDir}/validate.md`)
}
return skill_state
}
// 解析进度 Markdown 文件
function parseProgressFile(filePath) {
const content = Read(filePath)
if (!content) return null
// 从 Markdown 表格和结构中提取数据
// ... implementation
}
```
### 恢复策略
1. **API 字段**: 无法恢复 - 需要从 API 重新获取或用户手动输入
2. **skill_state 字段**: 可以从 `.progress/` 目录的 Markdown 文件解析
3. **任务列表**: 从 `.loop/{loopId}.tasks.jsonl` 恢复
## 状态验证
```javascript
function validateState(state) {
const errors = []
// 必需字段
if (!state.session_id) errors.push('Missing session_id')
if (!state.task_description) errors.push('Missing task_description')
// 状态一致性
if (state.initialized && state.status === 'pending') {
errors.push('Inconsistent: initialized but status is pending')
}
if (state.status === 'completed' && !state.validate.passed) {
errors.push('Inconsistent: completed but validation not passed')
}
// 开发任务一致性
const completedTasks = state.develop.tasks.filter(t => t.status === 'completed').length
if (completedTasks !== state.develop.completed_count) {
errors.push('Inconsistent: completed_count mismatch')
}
return { valid: errors.length === 0, errors }
}
```

View File

@@ -0,0 +1,300 @@
# Action Catalog
CCW Loop 所有可用动作的目录和说明。
## Available Actions
| Action | Purpose | Preconditions | Effects | CLI Integration |
|--------|---------|---------------|---------|-----------------|
| [action-init](../phases/actions/action-init.md) | 初始化会话 | status=pending, initialized=false | status→running, initialized→true, 创建目录和任务列表 | Gemini 任务分解 |
| [action-menu](../phases/actions/action-menu.md) | 显示操作菜单 | initialized=true, status=running | 返回用户选择的动作 | - |
| [action-develop-with-file](../phases/actions/action-develop-with-file.md) | 执行开发任务 | initialized=true, pending tasks > 0 | 更新 progress.md, 完成一个任务 | Gemini 代码实现 |
| [action-debug-with-file](../phases/actions/action-debug-with-file.md) | 假设驱动调试 | initialized=true | 更新 understanding.md, hypotheses.json | Gemini 假设生成和证据分析 |
| [action-validate-with-file](../phases/actions/action-validate-with-file.md) | 运行测试验证 | initialized=true, develop > 0 or debug confirmed | 更新 validation.md, test-results.json | Gemini 质量分析 |
| [action-complete](../phases/actions/action-complete.md) | 完成循环 | initialized=true | status→completed, 生成 summary.md | - |
## Action Dependencies Graph
```mermaid
graph TD
START([用户启动 /ccw-loop]) --> INIT[action-init]
INIT --> MENU[action-menu]
MENU --> DEVELOP[action-develop-with-file]
MENU --> DEBUG[action-debug-with-file]
MENU --> VALIDATE[action-validate-with-file]
MENU --> STATUS[action-status]
MENU --> COMPLETE[action-complete]
MENU --> EXIT([退出])
DEVELOP --> MENU
DEBUG --> MENU
VALIDATE --> MENU
STATUS --> MENU
COMPLETE --> END([结束])
EXIT --> END
style INIT fill:#e1f5fe
style MENU fill:#fff3e0
style DEVELOP fill:#e8f5e9
style DEBUG fill:#fce4ec
style VALIDATE fill:#f3e5f5
style COMPLETE fill:#c8e6c9
```
## Action Execution Matrix
### Interactive Mode
| State | Auto-Selected Action | User Options |
|-------|---------------------|--------------|
| pending | action-init | - |
| running, !initialized | action-init | - |
| running, initialized | action-menu | All actions |
### Auto Mode
| Condition | Selected Action |
|-----------|----------------|
| pending_develop_tasks > 0 | action-develop-with-file |
| last_action=develop, !debug_completed | action-debug-with-file |
| last_action=debug, !validation_completed | action-validate-with-file |
| validation_failed | action-develop-with-file (fix) |
| validation_passed, no pending | action-complete |
## Action Inputs/Outputs
### action-init
**Inputs**:
- state.task_description
- User input (optional)
**Outputs**:
- meta.json
- state.json (初始化)
- develop/tasks.json
- develop/progress.md
**State Changes**:
```javascript
{
status: 'pending' 'running',
initialized: false true,
develop.tasks: [] [task1, task2, ...]
}
```
### action-develop-with-file
**Inputs**:
- state.develop.tasks
- User selection (如有多个待处理任务)
**Outputs**:
- develop/progress.md (追加)
- develop/tasks.json (更新)
- develop/changes.log (追加)
**State Changes**:
```javascript
{
develop.current_task_id: null 'task-xxx' null,
develop.completed_count: N N+1,
last_action: X 'action-develop-with-file'
}
```
### action-debug-with-file
**Inputs**:
- Bug description (用户输入或从测试失败获取)
- debug.log (如已有)
**Outputs**:
- debug/understanding.md (追加)
- debug/hypotheses.json (更新)
- Code changes (添加日志或修复)
**State Changes**:
```javascript
{
debug.current_bug: null 'bug description',
debug.hypotheses: [...updated],
debug.iteration: N N+1,
debug.confirmed_hypothesis: null 'H1' (如确认)
}
```
### action-validate-with-file
**Inputs**:
- 测试脚本 (从 package.json)
- 覆盖率工具 (可选)
**Outputs**:
- validate/validation.md (追加)
- validate/test-results.json (更新)
- validate/coverage.json (更新)
**State Changes**:
```javascript
{
validate.test_results: [...new results],
validate.coverage: null 85.5,
validate.passed: false true,
validate.failed_tests: ['test1', 'test2'] []
}
```
### action-complete
**Inputs**:
- state (完整状态)
- User choices (扩展选项)
**Outputs**:
- summary.md
- Issues (如选择扩展)
**State Changes**:
```javascript
{
status: 'running' 'completed',
completed_at: null timestamp
}
```
## Action Sequences
### Typical Happy Path
```
action-init
→ action-develop-with-file (task 1)
→ action-develop-with-file (task 2)
→ action-develop-with-file (task 3)
→ action-validate-with-file
→ PASS
→ action-complete
```
### Debug Iteration Path
```
action-init
→ action-develop-with-file (task 1)
→ action-validate-with-file
→ FAIL
→ action-debug-with-file (探索)
→ action-debug-with-file (分析)
→ Root cause found
→ action-validate-with-file
→ PASS
→ action-complete
```
### Multi-Iteration Path
```
action-init
→ action-develop-with-file (task 1)
→ action-debug-with-file
→ action-develop-with-file (task 2)
→ action-validate-with-file
→ FAIL
→ action-debug-with-file
→ action-validate-with-file
→ PASS
→ action-complete
```
## Error Scenarios
### CLI Tool Failure
```
action-develop-with-file
→ Gemini CLI fails
→ Fallback to manual implementation
→ Prompt user for code
→ Continue
```
### Test Failure
```
action-validate-with-file
→ Tests fail
→ Record failed tests
→ Suggest action-debug-with-file
→ User chooses debug or manual fix
```
### Max Iterations Reached
```
state.iteration_count >= 10
→ Warning message
→ Suggest break or task split
→ Allow continue or exit
```
## Action Extensions
### Adding New Actions
To add a new action:
1. Create `phases/actions/action-{name}.md`
2. Define preconditions, execution, state updates
3. Add to this catalog
4. Update orchestrator.md decision logic
5. Add to action-menu.md options
### Action Template
```markdown
# Action: {Name}
{Brief description}
## Purpose
{Detailed purpose}
## Preconditions
- [ ] condition1
- [ ] condition2
## Execution
### Step 1: {Step Name}
\`\`\`javascript
// code
\`\`\`
## State Updates
\`\`\`javascript
return {
stateUpdates: {
// updates
},
continue: true,
message: "..."
}
\`\`\`
## Error Handling
| Error Type | Recovery |
|------------|----------|
| ... | ... |
## Next Actions (Hints)
- condition: next_action
```

View File

@@ -0,0 +1,192 @@
# Loop Requirements Specification
CCW Loop 的核心需求和约束定义。
## Core Requirements
### 1. 无状态循环
**Requirement**: 每次执行从文件读取状态,执行后写回文件,不依赖内存状态。
**Rationale**: 支持随时中断和恢复,状态持久化。
**Validation**:
- [ ] 每个 action 开始时从文件读取状态
- [ ] 每个 action 结束时将状态写回文件
- [ ] 无全局变量或内存状态依赖
### 2. 文件驱动进度
**Requirement**: 所有进度、理解、验证结果都记录在专用 Markdown 文件中。
**Rationale**: 可审计、可回顾、团队可见。
**Validation**:
- [ ] develop/progress.md 记录开发进度
- [ ] debug/understanding.md 记录理解演变
- [ ] validate/validation.md 记录验证结果
- [ ] 所有文件使用 Markdown 格式,易读
### 3. CLI 工具集成
**Requirement**: 关键决策点使用 Gemini/CLI 进行深度分析。
**Rationale**: 利用 LLM 能力提高质量。
**Validation**:
- [ ] 任务分解使用 Gemini
- [ ] 假设生成使用 Gemini
- [ ] 证据分析使用 Gemini
- [ ] 质量评估使用 Gemini
### 4. 用户控制循环
**Requirement**: 支持交互式和自动循环两种模式,用户可随时介入。
**Rationale**: 灵活性,适应不同场景。
**Validation**:
- [ ] 交互模式:每步显示菜单
- [ ] 自动模式:按预设流程执行
- [ ] 用户可随时退出
- [ ] 状态可恢复
### 5. 可恢复性
**Requirement**: 任何时候中断后,可以从上次位置继续。
**Rationale**: 长时间任务支持,意外中断恢复。
**Validation**:
- [ ] 状态保存在 state.json
- [ ] 使用 --resume 可继续
- [ ] 历史记录完整保留
## Quality Standards
### Completeness
| Dimension | Threshold |
|-----------|-----------|
| 进度文档完整性 | 每个任务都有记录 |
| 理解文档演变 | 每次迭代都有更新 |
| 验证报告详尽 | 包含所有测试结果 |
### Consistency
| Dimension | Threshold |
|-----------|-----------|
| 文件格式一致 | 所有 Markdown 文件使用相同模板 |
| 状态同步一致 | state.json 与文件内容匹配 |
| 时间戳格式 | 统一使用 ISO8601 格式 |
### Usability
| Dimension | Threshold |
|-----------|-----------|
| 菜单易用性 | 选项清晰,描述准确 |
| 进度可见性 | 随时可查看当前状态 |
| 错误提示 | 错误消息清晰,提供恢复建议 |
## Constraints
### 1. 文件结构约束
```
.workflow/.loop/{session-id}/
├── meta.json # 只写一次,不再修改
├── state.json # 每次 action 后更新
├── develop/
│ ├── progress.md # 只追加,不删除
│ ├── tasks.json # 任务状态更新
│ └── changes.log # NDJSON 格式,只追加
├── debug/
│ ├── understanding.md # 只追加,记录时间线
│ ├── hypotheses.json # 更新假设状态
│ └── debug.log # NDJSON 格式
└── validate/
├── validation.md # 每次验证追加
├── test-results.json # 累积测试结果
└── coverage.json # 最新覆盖率
```
### 2. 命名约束
- Session ID: `LOOP-{slug}-{YYYY-MM-DD}`
- Task ID: `task-{NNN}` (三位数字)
- Hypothesis ID: `H{N}` (单字母+数字)
### 3. 状态转换约束
```
pending → running → completed
user_exit
failed
```
Only allow: `pending→running`, `running→completed/user_exit/failed`
### 4. 错误限制约束
- 最大错误次数: 3
- 超过 3 次错误 → 自动终止
- 每次错误 → 记录到 state.errors[]
### 5. 迭代限制约束
- 最大迭代次数: 10 (警告)
- 超过 10 次 → 警告用户,但不强制停止
- 建议拆分任务或休息
## Integration Requirements
### 1. Dashboard 集成
**Requirement**: 与 CCW Dashboard Loop Monitor 无缝集成。
**Specification**:
- Dashboard 创建 Loop → 调用此 Skill
- state.json → Dashboard 实时显示
- 任务列表双向同步
- 状态控制按钮映射到 actions
### 2. Issue 系统集成
**Requirement**: 完成后可扩展为 Issue。
**Specification**:
- 支持维度: test, enhance, refactor, doc
- 调用 `/issue:new "{summary} - {dimension}"`
- 自动填充上下文
### 3. CLI 工具集成
**Requirement**: 使用 CCW CLI 工具进行分析和实现。
**Specification**:
- 任务分解: `--rule planning-breakdown-task-steps`
- 代码实现: `--rule development-implement-feature`
- 根因分析: `--rule analysis-diagnose-bug-root-cause`
- 质量评估: `--rule analysis-review-code-quality`
## Non-Functional Requirements
### Performance
- Session 初始化: < 5s
- Action 执行: < 30s (不含 CLI 调用)
- 状态读写: < 1s
### Reliability
- 状态文件损坏恢复: 支持从其他文件重建
- CLI 工具失败降级: 回退到手动模式
- 错误重试: 支持一次自动重试
### Maintainability
- 文档化: 所有 action 都有清晰说明
- 模块化: 每个 action 独立可测
- 可扩展: 易于添加新 action

View File

@@ -0,0 +1,175 @@
# Progress Document Template
开发进度文档的标准模板。
## Template Structure
```markdown
# Development Progress
**Session ID**: {{session_id}}
**Task**: {{task_description}}
**Started**: {{started_at}}
**Estimated Complexity**: {{complexity}}
---
## Task List
{{#each tasks}}
{{@index}}. [{{#if completed}}x{{else}} {{/if}}] {{description}}
{{/each}}
## Key Files
{{#each key_files}}
- `{{this}}`
{{/each}}
---
## Progress Timeline
{{#each iterations}}
### Iteration {{@index}} - {{task_name}} ({{timestamp}})
#### Task Details
- **ID**: {{task_id}}
- **Tool**: {{tool}}
- **Mode**: {{mode}}
#### Implementation Summary
{{summary}}
#### Files Changed
{{#each files_changed}}
- `{{this}}`
{{/each}}
#### Status: {{status}}
---
{{/each}}
## Current Statistics
| Metric | Value |
|--------|-------|
| Total Tasks | {{total_tasks}} |
| Completed | {{completed_tasks}} |
| In Progress | {{in_progress_tasks}} |
| Pending | {{pending_tasks}} |
| Progress | {{progress_percentage}}% |
---
## Next Steps
{{#each next_steps}}
- [ ] {{this}}
{{/each}}
```
## Template Variables
| Variable | Type | Source | Description |
|----------|------|--------|-------------|
| `session_id` | string | state.session_id | 会话 ID |
| `task_description` | string | state.task_description | 任务描述 |
| `started_at` | string | state.created_at | 开始时间 |
| `complexity` | string | state.context.estimated_complexity | 预估复杂度 |
| `tasks` | array | state.develop.tasks | 任务列表 |
| `key_files` | array | state.context.key_files | 关键文件 |
| `iterations` | array | 从文件解析 | 迭代历史 |
| `total_tasks` | number | state.develop.total_count | 总任务数 |
| `completed_tasks` | number | state.develop.completed_count | 已完成数 |
## Usage Example
```javascript
const progressTemplate = Read('.claude/skills/ccw-loop/templates/progress-template.md')
function renderProgress(state) {
let content = progressTemplate
// 替换简单变量
content = content.replace('{{session_id}}', state.session_id)
content = content.replace('{{task_description}}', state.task_description)
content = content.replace('{{started_at}}', state.created_at)
content = content.replace('{{complexity}}', state.context?.estimated_complexity || 'unknown')
// 替换任务列表
const taskList = state.develop.tasks.map((t, i) => {
const checkbox = t.status === 'completed' ? 'x' : ' '
return `${i + 1}. [${checkbox}] ${t.description}`
}).join('\n')
content = content.replace('{{#each tasks}}...{{/each}}', taskList)
// 替换统计
content = content.replace('{{total_tasks}}', state.develop.total_count)
content = content.replace('{{completed_tasks}}', state.develop.completed_count)
// ...
return content
}
```
## Section Templates
### Task Entry
```markdown
### Iteration {{N}} - {{task_name}} ({{timestamp}})
#### Task Details
- **ID**: {{task_id}}
- **Tool**: {{tool}}
- **Mode**: {{mode}}
#### Implementation Summary
{{summary}}
#### Files Changed
{{#each files}}
- `{{this}}`
{{/each}}
#### Status: COMPLETED
---
```
### Statistics Table
```markdown
## Current Statistics
| Metric | Value |
|--------|-------|
| Total Tasks | {{total}} |
| Completed | {{completed}} |
| In Progress | {{in_progress}} |
| Pending | {{pending}} |
| Progress | {{percentage}}% |
```
### Next Steps
```markdown
## Next Steps
{{#if all_completed}}
- [ ] Run validation tests
- [ ] Code review
- [ ] Update documentation
{{else}}
- [ ] Complete remaining {{pending}} tasks
- [ ] Review completed work
{{/if}}
```

View File

@@ -0,0 +1,303 @@
# Understanding Document Template
调试理解演变文档的标准模板。
## Template Structure
```markdown
# Understanding Document
**Session ID**: {{session_id}}
**Bug Description**: {{bug_description}}
**Started**: {{started_at}}
---
## Exploration Timeline
{{#each iterations}}
### Iteration {{number}} - {{title}} ({{timestamp}})
{{#if is_exploration}}
#### Current Understanding
Based on bug description and initial code search:
- Error pattern: {{error_pattern}}
- Affected areas: {{affected_areas}}
- Initial hypothesis: {{initial_thoughts}}
#### Evidence from Code Search
{{#each search_results}}
**Keyword: "{{keyword}}"**
- Found in: {{files}}
- Key findings: {{insights}}
{{/each}}
{{/if}}
{{#if has_hypotheses}}
#### Hypotheses Generated (Gemini-Assisted)
{{#each hypotheses}}
**{{id}}** (Likelihood: {{likelihood}}): {{description}}
- Logging at: {{logging_point}}
- Testing: {{testable_condition}}
- Evidence to confirm: {{confirm_criteria}}
- Evidence to reject: {{reject_criteria}}
{{/each}}
**Gemini Insights**: {{gemini_insights}}
{{/if}}
{{#if is_analysis}}
#### Log Analysis Results
{{#each results}}
**{{id}}**: {{verdict}}
- Evidence: {{evidence}}
- Reasoning: {{reason}}
{{/each}}
#### Corrected Understanding
Previous misunderstandings identified and corrected:
{{#each corrections}}
- ~~{{wrong}}~~ → {{corrected}}
- Why wrong: {{reason}}
- Evidence: {{evidence}}
{{/each}}
#### New Insights
{{#each insights}}
- {{this}}
{{/each}}
#### Gemini Analysis
{{gemini_analysis}}
{{/if}}
{{#if root_cause_found}}
#### Root Cause Identified
**{{hypothesis_id}}**: {{description}}
Evidence supporting this conclusion:
{{supporting_evidence}}
{{else}}
#### Next Steps
{{next_steps}}
{{/if}}
---
{{/each}}
## Current Consolidated Understanding
### What We Know
{{#each valid_understandings}}
- {{this}}
{{/each}}
### What Was Disproven
{{#each disproven}}
- ~~{{assumption}}~~ (Evidence: {{evidence}})
{{/each}}
### Current Investigation Focus
{{current_focus}}
### Remaining Questions
{{#each questions}}
- {{this}}
{{/each}}
```
## Template Variables
| Variable | Type | Source | Description |
|----------|------|--------|-------------|
| `session_id` | string | state.session_id | 会话 ID |
| `bug_description` | string | state.debug.current_bug | Bug 描述 |
| `iterations` | array | 从文件解析 | 迭代历史 |
| `hypotheses` | array | state.debug.hypotheses | 假设列表 |
| `valid_understandings` | array | 从 Gemini 分析 | 有效理解 |
| `disproven` | array | 从假设状态 | 被否定的假设 |
## Section Templates
### Exploration Section
```markdown
### Iteration {{N}} - Initial Exploration ({{timestamp}})
#### Current Understanding
Based on bug description and initial code search:
- Error pattern: {{pattern}}
- Affected areas: {{areas}}
- Initial hypothesis: {{thoughts}}
#### Evidence from Code Search
{{#each search_results}}
**Keyword: "{{keyword}}"**
- Found in: {{files}}
- Key findings: {{insights}}
{{/each}}
#### Next Steps
- Generate testable hypotheses
- Add instrumentation
- Await reproduction
```
### Hypothesis Section
```markdown
#### Hypotheses Generated (Gemini-Assisted)
| ID | Description | Likelihood | Status |
|----|-------------|------------|--------|
{{#each hypotheses}}
| {{id}} | {{description}} | {{likelihood}} | {{status}} |
{{/each}}
**Details:**
{{#each hypotheses}}
**{{id}}**: {{description}}
- Logging at: `{{logging_point}}`
- Testing: {{testable_condition}}
- Confirm: {{evidence_criteria.confirm}}
- Reject: {{evidence_criteria.reject}}
{{/each}}
```
### Analysis Section
```markdown
### Iteration {{N}} - Evidence Analysis ({{timestamp}})
#### Log Analysis Results
{{#each results}}
**{{id}}**: **{{verdict}}**
- Evidence: \`{{evidence}}\`
- Reasoning: {{reason}}
{{/each}}
#### Corrected Understanding
| Previous Assumption | Corrected To | Reason |
|---------------------|--------------|--------|
{{#each corrections}}
| ~~{{wrong}}~~ | {{corrected}} | {{reason}} |
{{/each}}
#### Gemini Analysis
{{gemini_analysis}}
```
### Consolidated Understanding Section
```markdown
## Current Consolidated Understanding
### What We Know
{{#each valid}}
- {{this}}
{{/each}}
### What Was Disproven
{{#each disproven}}
- ~~{{this.assumption}}~~ (Evidence: {{this.evidence}})
{{/each}}
### Current Investigation Focus
{{focus}}
### Remaining Questions
{{#each questions}}
- {{this}}
{{/each}}
```
### Resolution Section
```markdown
### Resolution ({{timestamp}})
#### Fix Applied
- Modified files: {{files}}
- Fix description: {{description}}
- Root cause addressed: {{root_cause}}
#### Verification Results
{{verification}}
#### Lessons Learned
{{#each lessons}}
{{@index}}. {{this}}
{{/each}}
#### Key Insights for Future
{{#each insights}}
- {{this}}
{{/each}}
```
## Consolidation Rules
更新 "Current Consolidated Understanding" 时遵循以下规则:
1. **简化被否定项**: 移到 "What Was Disproven",只保留单行摘要
2. **保留有效见解**: 将确认的发现提升到 "What We Know"
3. **避免重复**: 不在合并部分重复时间线细节
4. **关注当前状态**: 描述现在知道什么,而不是过程
5. **保留关键纠正**: 保留重要的 wrong→right 转换供学习
## Anti-Patterns
**错误示例 (冗余)**:
```markdown
## Current Consolidated Understanding
In iteration 1 we thought X, but in iteration 2 we found Y, then in iteration 3...
Also we checked A and found B, and then we checked C...
```
**正确示例 (精简)**:
```markdown
## Current Consolidated Understanding
### What We Know
- Error occurs during runtime update, not initialization
- Config value is None (not missing key)
### What Was Disproven
- ~~Initialization error~~ (Timing evidence)
- ~~Missing key hypothesis~~ (Key exists)
### Current Investigation Focus
Why is config value None during update?
```

View File

@@ -0,0 +1,258 @@
# Validation Report Template
验证报告的标准模板。
## Template Structure
```markdown
# Validation Report
**Session ID**: {{session_id}}
**Task**: {{task_description}}
**Validated**: {{timestamp}}
---
## Iteration {{iteration}} - Validation Run
### Test Execution Summary
| Metric | Value |
|--------|-------|
| Total Tests | {{total_tests}} |
| Passed | {{passed_tests}} |
| Failed | {{failed_tests}} |
| Skipped | {{skipped_tests}} |
| Duration | {{duration}}ms |
| **Pass Rate** | **{{pass_rate}}%** |
### Coverage Report
{{#if has_coverage}}
| File | Statements | Branches | Functions | Lines |
|------|------------|----------|-----------|-------|
{{#each coverage_files}}
| {{path}} | {{statements}}% | {{branches}}% | {{functions}}% | {{lines}}% |
{{/each}}
**Overall Coverage**: {{overall_coverage}}%
{{else}}
_No coverage data available_
{{/if}}
### Failed Tests
{{#if has_failures}}
{{#each failures}}
#### {{test_name}}
- **Suite**: {{suite}}
- **Error**: {{error_message}}
- **Stack**:
\`\`\`
{{stack_trace}}
\`\`\`
{{/each}}
{{else}}
_All tests passed_
{{/if}}
### Gemini Quality Analysis
{{gemini_analysis}}
### Recommendations
{{#each recommendations}}
- {{this}}
{{/each}}
---
## Validation Decision
**Result**: {{#if passed}}✅ PASS{{else}}❌ FAIL{{/if}}
**Rationale**: {{rationale}}
{{#if not_passed}}
### Next Actions
1. Review failed tests
2. Debug failures using action-debug-with-file
3. Fix issues and re-run validation
{{else}}
### Next Actions
1. Consider code review
2. Prepare for deployment
3. Update documentation
{{/if}}
```
## Template Variables
| Variable | Type | Source | Description |
|----------|------|--------|-------------|
| `session_id` | string | state.session_id | 会话 ID |
| `task_description` | string | state.task_description | 任务描述 |
| `timestamp` | string | 当前时间 | 验证时间 |
| `iteration` | number | 从文件计算 | 验证迭代次数 |
| `total_tests` | number | 测试输出 | 总测试数 |
| `passed_tests` | number | 测试输出 | 通过数 |
| `failed_tests` | number | 测试输出 | 失败数 |
| `pass_rate` | number | 计算得出 | 通过率 |
| `coverage_files` | array | 覆盖率报告 | 文件覆盖率 |
| `failures` | array | 测试输出 | 失败测试详情 |
| `gemini_analysis` | string | Gemini CLI | 质量分析 |
| `recommendations` | array | Gemini CLI | 建议列表 |
## Section Templates
### Test Summary
```markdown
### Test Execution Summary
| Metric | Value |
|--------|-------|
| Total Tests | {{total}} |
| Passed | {{passed}} |
| Failed | {{failed}} |
| Skipped | {{skipped}} |
| Duration | {{duration}}ms |
| **Pass Rate** | **{{rate}}%** |
```
### Coverage Table
```markdown
### Coverage Report
| File | Statements | Branches | Functions | Lines |
|------|------------|----------|-----------|-------|
{{#each files}}
| `{{path}}` | {{statements}}% | {{branches}}% | {{functions}}% | {{lines}}% |
{{/each}}
**Overall Coverage**: {{overall}}%
**Coverage Thresholds**:
- ✅ Good: ≥ 80%
- ⚠️ Warning: 60-79%
- ❌ Poor: < 60%
```
### Failed Test Details
```markdown
### Failed Tests
{{#each failures}}
#### ❌ {{test_name}}
| Field | Value |
|-------|-------|
| Suite | {{suite}} |
| Error | {{error_message}} |
| Duration | {{duration}}ms |
**Stack Trace**:
\`\`\`
{{stack_trace}}
\`\`\`
**Possible Causes**:
{{#each possible_causes}}
- {{this}}
{{/each}}
---
{{/each}}
```
### Quality Analysis
```markdown
### Gemini Quality Analysis
#### Code Quality Assessment
| Dimension | Score | Status |
|-----------|-------|--------|
| Correctness | {{correctness}}/10 | {{correctness_status}} |
| Completeness | {{completeness}}/10 | {{completeness_status}} |
| Reliability | {{reliability}}/10 | {{reliability_status}} |
| Maintainability | {{maintainability}}/10 | {{maintainability_status}} |
#### Key Findings
{{#each findings}}
- **{{severity}}**: {{description}}
{{/each}}
#### Recommendations
{{#each recommendations}}
{{@index}}. {{this}}
{{/each}}
```
### Decision Section
```markdown
## Validation Decision
**Result**: {{#if passed}}✅ PASS{{else}}❌ FAIL{{/if}}
**Rationale**:
{{rationale}}
**Confidence Level**: {{confidence}}
### Decision Matrix
| Criteria | Status | Weight | Score |
|----------|--------|--------|-------|
| All tests pass | {{tests_pass}} | 40% | {{tests_score}} |
| Coverage ≥ 80% | {{coverage_pass}} | 30% | {{coverage_score}} |
| No critical issues | {{no_critical}} | 20% | {{critical_score}} |
| Quality analysis pass | {{quality_pass}} | 10% | {{quality_score}} |
| **Total** | | 100% | **{{total_score}}** |
**Threshold**: 70% to pass
### Next Actions
{{#if passed}}
1. ✅ Code review (recommended)
2. ✅ Update documentation
3. ✅ Prepare for deployment
{{else}}
1. ❌ Review failed tests
2. ❌ Debug failures
3. ❌ Fix issues and re-run
{{/if}}
```
## Historical Comparison
```markdown
## Validation History
| Iteration | Date | Pass Rate | Coverage | Status |
|-----------|------|-----------|----------|--------|
{{#each history}}
| {{iteration}} | {{date}} | {{pass_rate}}% | {{coverage}}% | {{status}} |
{{/each}}
### Trend Analysis
{{#if improving}}
📈 **Improving**: Pass rate increased from {{previous_rate}}% to {{current_rate}}%
{{else if declining}}
📉 **Declining**: Pass rate decreased from {{previous_rate}}% to {{current_rate}}%
{{else}}
➡️ **Stable**: Pass rate remains at {{current_rate}}%
{{/if}}
```

View File

@@ -1,388 +0,0 @@
---
name: command-guide
description: Workflow command guide for Claude Code Workflow (78 commands). Search/browse commands, get next-step recommendations, view documentation, report issues. Triggers "CCW-help", "CCW-issue", "ccw-help", "ccw-issue", "ccw"
allowed-tools: Read, Grep, Glob, AskUserQuestion
version: 5.8.0
---
# Command Guide Skill
Comprehensive command guide for Claude Code Workflow (CCW) system covering 78 commands across 5 categories (workflow, cli, memory, task, general).
## 🆕 What's New in v5.8.0
### Major Features
**🎨 UI Design Style Memory Workflow** (Primary Focus)
- **`/memory:style-skill-memory`** - Generate reusable SKILL packages from design systems
- **`/workflow:ui-design:codify-style`** - Extract design tokens from code with automatic file discovery
- **`/workflow:ui-design:reference-page-generator`** - Generate multi-component reference pages
- **Workflow**: Design extraction → Token documentation → SKILL package → Easy loading
**`/workflow:lite-plan`** - Intelligent Planning & Execution (Testing Phase)
- Dynamic workflow adaptation (smart exploration, adaptive planning, progressive clarification)
- Two-dimensional confirmation (task approval + execution method selection)
- Direct execution with live TodoWrite progress tracking
- Faster than `/workflow:plan` (1-3 min vs 5-10 min) for simple to medium tasks
**🗺️ `/memory:code-map-memory`** - Code Flow Mapping Generator (Testing Phase)
- Uses cli-explore-agent for deep code flow analysis with dual-source strategy
- Generates Mermaid diagrams for architecture, functions, data flow, conditional paths
- Creates feature-specific SKILL packages for code understanding
- Progressive loading (2K → 30K tokens) for efficient context management
### Agent
- **cli-explore-agent** - Specialized code exploration with Deep Scan mode (Bash + Gemini)
- **cli-planning-agent** - Enhanced task generation with improved context handling
- **ui-design-agent** - Major refactoring for better design system extraction
### Additional Improvements
- Enhanced brainstorming workflows with parallel execution
- Improved test workflow documentation and task attachment models
- Updated CLI tool default models (Gemini 2.5-pro)
## 🧠 Core Principle: Intelligent Integration
**⚠️ IMPORTANT**: This SKILL provides **reference materials** for intelligent integration, NOT templates for direct copying.
**Response Strategy**:
1. **Analyze user's specific context** - Understand their exact need, workflow stage, and technical level
2. **Extract relevant information** - Select only the pertinent parts from reference guides
3. **Synthesize and customize** - Combine multiple sources, add context-specific examples
4. **Deliver targeted response** - Provide concise, actionable guidance tailored to the user's situation
**Never**:
- ❌ Copy-paste entire template sections verbatim
- ❌ Return raw reference documentation without processing
- ❌ Provide generic responses that ignore user context
**Always**:
- ✅ Understand the user's specific situation first
- ✅ Integrate information from multiple sources (indexes, guides, reference docs)
- ✅ Customize examples and explanations to match user's use case
- ✅ Provide progressive depth - brief answers with "more detail available" prompts
---
## 🎯 Operation Modes
### Mode 1: Command Search 🔍
**When**: User searches by keyword, category, or use-case
**Triggers**: "搜索命令", "find command", "planning 相关", "search"
**Process**:
1. Identify search type (keyword/category/use-case)
2. Query appropriate index (all-commands/by-category/by-use-case)
3. **Intelligently filter and rank** results based on user's implied context
4. **Synthesize concise response** with command names, brief descriptions, and use-case fit
5. **Suggest next steps** - related commands or workflow patterns
**Example**: "搜索 planning 命令" → Analyze user's likely goal → Present top 3-5 most relevant planning commands with context-specific usage hints, NOT raw JSON dump
---
### Mode 2: Smart Recommendations 🤖
**When**: User asks for next steps after a command
**Triggers**: "下一步", "what's next", "after /workflow:plan", "推荐"
**Process**:
1. **Analyze workflow context** - Understand where user is in their development cycle
2. Query `index/command-relationships.json` for possible next commands
3. **Evaluate and prioritize** recommendations based on:
- User's stated goals
- Common workflow patterns
- Project complexity indicators
4. **Craft contextual guidance** - Explain WHY each recommendation fits, not just WHAT to run
5. **Provide workflow examples** - Show complete flow, not isolated commands
**Example**: "执行完 /workflow:plan 后做什么?" → Analyze plan output quality → Recommend `/workflow:action-plan-verify` (if complex) OR `/workflow:execute` (if straightforward) with reasoning for each choice
---
### Mode 3: Full Documentation 📖
**When**: User requests command details
**Triggers**: "参数说明", "怎么用", "how to use", "详情"
**Process**:
1. Locate command in `index/all-commands.json`
2. Read original command file for full details
3. **Extract user-relevant sections** - Focus on what they asked about (parameters OR examples OR workflow)
4. **Enhance with context** - Add use-case specific examples if user's scenario is clear
5. **Progressive disclosure** - Provide core info first, offer "need more details?" prompts
**Example**: "/workflow:plan 的参数是什么?" → Identify user's experience level → Present parameters with context-appropriate explanations (beginner: verbose + examples; advanced: concise + edge cases), NOT raw documentation dump
---
### Mode 4: Beginner Onboarding 🎓
**When**: New user needs guidance
**Triggers**: "新手", "getting started", "如何开始", "常用命令", **"从0到1"**, **"全新项目"**
**Process**:
1. **Assess user background** - Ask clarifying questions if needed (coding experience? project type?)
2. **⚠️ Identify project stage** - FROM-ZERO-TO-ONE vs FEATURE-ADDITION:
- **从0到1场景** (全新项目/产品/架构决策) → **MUST START with brainstorming workflow**
- **功能新增场景** (已有项目中添加功能) → Start with planning workflow
3. **Design personalized learning path** based on their goals and stage
4. **Curate essential commands** from `index/essential-commands.json` - Select 3-5 most relevant for their use case
5. **Provide guided first example** - Walk through ONE complete workflow with explanation, **emphasizing brainstorming for 0-to-1 scenarios**
6. **Set clear next steps** - What to try next, where to get help
**Example 1 (从0到1)**: "我是新手,如何开始全新项目?" → Identify as FROM-ZERO-TO-ONE → Emphasize brainstorming workflow (`/workflow:brainstorm:artifacts`) as mandatory first step → Explain brainstorm → plan → execute flow
**Example 2 (功能新增)**: "我是新手,如何在已有项目中添加功能?" → Identify as FEATURE-ADDITION → Guide to planning workflow (`/workflow:plan`) → Explain plan → execute → test flow
**Example 3 (探索)**: "我是新手,如何开始?" → Ask clarifying question: "是全新项目启动从0到1还是在已有项目中添加功能" → Based on answer, route to appropriate workflow
---
### Mode 5: Issue Reporting 📝
**When**: User wants to report issue or request feature
**Triggers**: **"CCW-issue"**, **"CCW-help"**, **"ccw-issue"**, **"ccw-help"**, **"ccw"**, "报告 bug", "功能建议", "问题咨询", "交互式诊断"
**Process**:
1. **Understand issue context** - Use AskUserQuestion to confirm type AND gather initial context
2. **Intelligently guide information collection**:
- Adapt questions based on previous answers
- Skip irrelevant sections
- Probe for missing critical details
3. **Select and customize template**:
- `issue-diagnosis.md`, `issue-bug.md`, `issue-feature.md`, or `issue-question.md`
- **Adapt template sections** to match user's specific scenario
4. **Synthesize coherent issue report**:
- Integrate collected information with appropriate template sections
- **Highlight key details** - Don't bury critical info in boilerplate
- Add privacy-protected command history
5. **Provide actionable next steps** - Immediate troubleshooting OR submission guidance
**Example**: "CCW-issue" → Detect user frustration level → For urgent: fast-track to critical info collection; For exploratory: comprehensive diagnostic flow, NOT one-size-fits-all questionnaire
**🆕 Enhanced Features**:
- Complete command history with privacy protection
- Interactive diagnostic checklists
- Decision tree navigation (diagnosis template)
- Execution environment capture
---
### Mode 6: Deep Command Analysis 🔬
**When**: User asks detailed questions about specific commands or agents
**Triggers**: "详细说明", "命令原理", "agent 如何工作", "实现细节", specific command/agent name mentioned
**Data Sources**:
- `reference/agents/*.md` - All agent documentation (11 agents)
- `reference/commands/**/*.md` - All command documentation (69 commands)
**Process**:
**Simple Query** (direct documentation lookup):
1. Identify target command/agent from user query
2. Locate corresponding markdown file in `reference/`
3. **Extract contextually relevant sections** - Not entire document
4. **Synthesize focused explanation**:
- Address user's specific question
- Add context-appropriate examples
- Link related concepts
5. **Offer progressive depth** - "Want to know more about X?"
**Complex Query** (CLI-assisted analysis):
1. **Detect complexity indicators** (多个命令对比、工作流程分析、最佳实践)
2. **Design targeted analysis prompt** for gemini/qwen via CCW:
- Frame user's question precisely
- Specify required analysis depth
- Request structured comparison/synthesis
```bash
ccw cli -p "
PURPOSE: Analyze command documentation to answer user query
TASK: • [extracted user question with context]
MODE: analysis
CONTEXT: @**/*
EXPECTED: Comprehensive answer with examples and recommendations
RULES: $(cat ~/.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt) | Focus on practical usage | analysis=READ-ONLY
" --tool gemini --cd ~/.claude/skills/command-guide/reference
```
Note: Use `--cd` with absolute path `~/.claude/skills/command-guide/reference` for reference documentation access
3. **Process and integrate CLI analysis**:
- Extract key insights from CLI output
- Add context-specific examples
- Synthesize actionable recommendations
4. **Deliver tailored response** - Not raw CLI output
**Query Classification**:
- **Simple**: Single command explanation, parameter list, basic usage
- **Complex**: Cross-command workflows, performance comparison, architectural analysis, best practices across multiple commands
**Examples**:
*Simple Query*:
```
User: "action-planning-agent 如何工作?"
→ Read reference/agents/action-planning-agent.md
→ **Identify user's knowledge gap** (mechanism? inputs/outputs? when to use?)
→ **Extract relevant sections** addressing their need
→ **Synthesize focused explanation** with examples
→ NOT: Dump entire agent documentation
```
*Complex Query*:
```
User: "对比 workflow:plan 和 workflow:tdd-plan 的使用场景和最佳实践"
→ Detect: 多命令对比 + 最佳实践
→ **Design comparison framework** (when to use, trade-offs, workflow integration)
→ Use gemini to analyze both commands with structured comparison prompt
→ **Synthesize insights** into decision matrix and usage guidelines
→ NOT: Raw command documentation side-by-side
```
---
## 📚 Index Files
All command metadata is stored in JSON indexes for fast querying:
- **all-commands.json** - Complete catalog (69 commands) with full metadata
- **by-category.json** - Hierarchical organization (workflow/cli/memory/task)
- **by-use-case.json** - Grouped by scenario (planning/implementation/testing/docs/session)
- **essential-commands.json** - Top 14 most-used commands
- **command-relationships.json** - Next-step recommendations and dependencies
📖 Detailed structure: [Index Structure Reference](guides/index-structure.md)
---
## 🗂️ Supporting Guides
- **[Getting Started](guides/getting-started.md)** - 5-minute quickstart for beginners
- **[Workflow Patterns](guides/workflow-patterns.md)** - Common workflow examples (Plan→Execute, TDD, UI design)
- **[CLI Tools Guide](guides/cli-tools-guide.md)** - Gemini/Qwen/Codex usage
- **[Troubleshooting](guides/troubleshooting.md)** - Common issues and solutions
- **[Implementation Details](guides/implementation-details.md)** - Detailed logic for each mode
- **[Usage Examples](guides/examples.md)** - Example dialogues and edge cases
## 📦 Reference Documentation
Complete backup of all command and agent documentation for deep analysis:
- **[reference/agents/](reference/agents/)** - 14 agent markdown files with implementation details
- **New in v5.8**: cli-explore-agent (code exploration), cli-planning-agent (enhanced)
- **[reference/commands/](reference/commands/)** - 78 command markdown files organized by category
- `cli/` - CLI tool commands (10 files) - **New**: document-analysis mode
- `memory/` - Memory management commands (12 files) - **New**: docs-full-cli, docs-related-cli, code-map-memory, style-skill-memory
- `task/` - Task management commands (4 files)
- `workflow/` - Workflow commands (50 files) - **New**: lite-plan, lite-fix, ui-design enhancements
**Installation Path**: `~/.claude/skills/command-guide/` (skill designed for global installation)
**Absolute Reference Path**: `~/.claude/skills/command-guide/reference/`
**Usage**: Mode 6 queries these files directly for detailed command/agent analysis, or uses CLI tools (gemini/qwen) with absolute paths for complex cross-command analysis.
---
## 🛠️ Issue Templates
Generate standardized GitHub issue templates with **execution flow emphasis**:
- **[Interactive Diagnosis](templates/issue-diagnosis.md)** - 🆕 Comprehensive diagnostic workflow with decision tree, checklists, and full command history
- **[Bug Report](templates/issue-bug.md)** - Report command errors with complete execution flow and environment details
- **[Feature Request](templates/issue-feature.md)** - Suggest improvements with current workflow analysis and pain points
- **[Question](templates/issue-question.md)** - Ask usage questions with detailed attempt history and context
**All templates now include**:
- ✅ Complete command history sections (with privacy protection)
- ✅ Execution environment details
- ✅ Interactive problem-locating checklists
- ✅ Structured troubleshooting guidance
Templates are auto-populated during Mode 5 (Issue Reporting) interaction.
---
## 📊 System Statistics
- **Total Commands**: 78
- **Total Agents**: 14
- **Categories**: 5 (workflow: 50, cli: 10, memory: 12, task: 4, general: 2)
- **Use Cases**: 7 (planning, implementation, testing, documentation, session-management, analysis, general)
- **Difficulty Levels**: 3 (Beginner, Intermediate, Advanced)
- **Essential Commands**: 13
- **Reference Docs**: 92 markdown files (14 agents + 78 commands)
---
## 🔧 Maintenance
### Updating Indexes
When commands are added/modified/removed:
```bash
cd /d/Claude_dms3/.claude/skills/command-guide
python scripts/analyze_commands.py
```
This script:
1. Scans all command files in `../../commands/`
2. Extracts metadata from YAML frontmatter
3. Analyzes command relationships
4. Regenerates all 5 index files
### Committing Updates
```bash
git add .claude/skills/command-guide/
git commit -m "docs: update command indexes"
git push
```
Team members get latest indexes via `git pull`.
---
## 📖 Related Documentation
- [Workflow Architecture](../../workflows/workflow-architecture.md) - System design overview
- [Intelligent Tools Strategy](../../workflows/intelligent-tools-strategy.md) - CLI tool selection
- [Context Search Strategy](../../workflows/context-search-strategy.md) - Search patterns
- [Task Core](../../workflows/task-core.md) - Task system fundamentals
---
## 🔄 Maintenance
### Documentation Updates
This SKILL documentation is kept in sync with command implementations through a standardized update process.
**Update Guideline**: See [UPDATE-GUIDELINE.md](UPDATE-GUIDELINE.md) for the complete documentation maintenance process.
**Update Process**:
1. **Analyze**: Identify changed commands/agents from git commits
2. **Extract**: Gather change information and impact assessment
3. **Update**: Sync reference docs, guides, and examples
4. **Regenerate**: Run `scripts/analyze_commands.py` to rebuild indexes
5. **Validate**: Test examples and verify consistency
6. **Commit**: Follow standardized commit message format
**Key Capabilities**:
- 6 operation modes (Search, Recommendations, Full Docs, Onboarding, Issue Reporting, Deep Analysis)
- 80 reference documentation files (11 agents + 69 commands)
- 5 JSON indexes for fast command lookup
- 8 comprehensive guides covering all workflow patterns
- 4 issue templates for standardized problem reporting
- CLI-assisted complex query analysis with gemini/qwen integration
**Maintainer**: CCW Team

View File

@@ -1,592 +0,0 @@
# Command Guide Update Guideline
## 📋 Purpose
This document defines a **standardized, repeatable process** for updating command-guide documentation when command changes are detected. Use this guideline every time you need to update command-guide SKILL documentation to ensure consistency and completeness.
---
## 🎯 Update Trigger Conditions
Execute this update process when ANY of the following conditions are met:
1. **New commands added** to `.claude/commands/`
2. **Command parameters changed** (new flags, modified behavior)
3. **Command architecture refactored** (workflow reorganization)
4. **Agent implementations updated** in `.claude/agents/`
5. **User explicitly requests** command-guide update
---
## 📊 Phase 1: Analysis & Discovery
### Step 1.1: Identify Changed Files
**Objective**: Discover what has changed since last update
**Actions**:
```bash
# Find recent commits affecting commands/agents
git log --oneline --since="<last-update-date>" --grep="command\|agent\|workflow" -20
# Show detailed changes
git diff <last-commit>..<current-commit> --stat .claude/commands/ .claude/agents/
# Identify modified command files
git diff <last-commit>..<current-commit> --name-only .claude/commands/
```
**Output**: List of changed files and commit messages
**Document**:
- Changed command files
- Changed agent files
- Key commit messages
- Change patterns (new features, refactoring, fixes)
---
### Step 1.2: Analyze Change Scope
**Objective**: Understand the nature and impact of changes
**Questions to Answer**:
1. **What changed?** (parameters, workflow, architecture, behavior)
2. **Why changed?** (new feature, optimization, bug fix, refactoring)
3. **Impact scope?** (single command, workflow pattern, system-wide)
4. **User-facing?** (affects user commands, internal only)
**Analysis Matrix**:
| Change Type | Detection Method | Impact Level |
|-------------|--------------------|--------------|
| **New Parameter** | Diff `argument-hint` field | Medium |
| **Workflow Reorganization** | Multiple command changes | High |
| **Architecture Change** | Agent file changes + command changes | High |
| **Bug Fix** | Single file, small change | Low |
| **New Command** | New file in `.claude/commands/` | Medium-High |
**Output**: Change classification and impact assessment
---
### Step 1.3: Map Affected Documentation
**Objective**: Identify which documentation files need updates
**Mapping Rules**:
**Command Changes** → Affects:
- `reference/commands/<category>/<command-name>.md` (copy from source)
- `index/all-commands.json` (regenerate)
- `index/by-category.json` (if new category)
- `guides/ui-design-workflow-guide.md` (if UI workflow affected)
- `guides/workflow-patterns.md` (if workflow pattern changed)
**Agent Changes** → Affects:
- `reference/agents/<agent-name>.md` (copy from source)
- `guides/implementation-details.md` (if agent behavior changed)
**Workflow Reorganization** → Affects:
- All related command references
- Workflow guides
- Examples in guides
**Output**: Checklist of files to update
---
## 🔧 Phase 2: Content Preparation
### Step 2.1: Extract Key Information
**Objective**: Gather information needed for documentation updates
**Extract from Git Commits**:
```bash
# Get commit details
git show <commit-hash> --stat
# Extract commit message
git log --format=%B -n 1 <commit-hash>
```
**Information to Extract**:
1. **Feature Name** (from commit message)
2. **Change Description** (what was added/modified/removed)
3. **Rationale** (why the change was made)
4. **New Parameters** (from diff)
5. **Breaking Changes** (backward compatibility impact)
6. **Usage Examples** (from commit or command file)
**Output**: Structured data for documentation
---
### Step 2.2: Categorize Changes
**Objective**: Organize changes into logical categories
**Categories**:
1. **Major Features**
- New commands
- New workflows
- Architecture changes
- User-facing feature additions
2. **Enhancements**
- New parameters
- Improved behavior
- Performance optimizations
- Better error handling
3. **Refactoring**
- Code reorganization (no user impact)
- Internal structure changes
- Consistency improvements
4. **Bug Fixes**
- Corrected behavior
- Fixed edge cases
- Parameter validation fixes
5. **Documentation**
- Updated descriptions
- New examples
- Clarified usage
**Output**: Changes grouped by category with priority
---
### Step 2.3: Analyze User Impact
**Objective**: Determine what users need to know
**User Impact Questions**:
1. **Do existing workflows break?** → Migration guide needed
2. **Are new features optional?** → Enhancement documentation
3. **Is behavior significantly different?** → Usage pattern updates
4. **Do examples need updates?** → Example refresh required
**Impact Levels**:
- **Critical** (Breaking changes, migration required)
- **Important** (New features users should adopt)
- **Nice-to-have** (Enhancements, optional)
- **Internal** (No user action needed)
**Output**: User-facing change summary with impact levels
---
## 📝 Phase 3: Documentation Updates
### Step 3.1: Update Reference Documentation
**Objective**: Sync reference docs with source command files
**Actions**:
1. **Run Python Script to Sync & Rebuild**:
```bash
cd /d/Claude_dms3/.claude/skills/command-guide
python scripts/analyze_commands.py
```
This script automatically:
- Deletes existing `reference/` directory
- Copies all agent files from `.claude/agents/` to `reference/agents/`
- Copies all command files from `.claude/commands/` to `reference/commands/`
- Regenerates all 5 index files with updated metadata
2. **Verify Completeness**:
- Check sync output for file counts (11 agents + 70 commands)
- Verify all 5 index files regenerated successfully
- Ensure YAML frontmatter integrity in copied files
**Output**: Updated reference documentation matching source + regenerated indexes
---
### Step 3.2: Update Workflow Guides
**Objective**: Reflect changes in user-facing workflow guides
**Workflow Guide Update Pattern**:
**IF** (UI workflow commands changed):
1. Open `guides/ui-design-workflow-guide.md`
2. Locate affected workflow pattern sections
3. Update examples to use new parameters/behavior
4. Add "New!" badges for new features
5. Update performance metrics if applicable
6. Add troubleshooting entries for new issues
**IF** (General workflow patterns changed):
1. Open `guides/workflow-patterns.md`
2. Update affected workflow examples
3. Add new pattern sections if applicable
**Update Template for New Features**:
```markdown
### [Feature Name] (New!)
**Purpose**: [What this feature enables]
**Usage**:
```bash
[Example command with new feature]
```
**Benefits**:
- [Benefit 1]
- [Benefit 2]
**When to Use**:
- [Use case 1]
- [Use case 2]
```
**Output**: Updated workflow guides with new features documented
---
### Step 3.3: Update Examples and Best Practices
**Objective**: Ensure examples reflect current best practices
**Example Update Checklist**:
- [ ] Remove deprecated parameter usage
- [ ] Add examples for new parameters
- [ ] Update command syntax if changed
- [ ] Verify all examples are runnable
- [ ] Add "Note" sections for common pitfalls
**Best Practices Update**:
- [ ] Add recommendations for new features
- [ ] Update "When to Use" guidelines
- [ ] Revise performance optimization tips
- [ ] Update troubleshooting entries
**Output**: Current, runnable examples
---
### Step 3.4: Update SKILL.md Metadata
**Objective**: Keep SKILL.md current without version-specific details
**Update Sections**:
1. **Supporting Guides** (if new guide added):
```markdown
- **[New Guide Name](guides/new-guide.md)** - Description
```
2. **System Statistics** (if counts changed):
```markdown
- **Total Commands**: <new-count>
- **Total Agents**: <new-count>
```
3. **Remove Old Changelog Entries**:
- Keep only last 3 changelog entries
- Archive older entries to separate file if needed
**DO NOT**:
- Add version numbers
- Add specific dates
- Create time-based changelog entries
**Output**: Updated SKILL.md metadata
---
## 🧪 Phase 4: Validation
### Step 4.1: Consistency Check
**Objective**: Ensure documentation is internally consistent
**Checklist**:
- [ ] All command references use correct names
- [ ] Parameter descriptions match command files
- [ ] Examples use valid parameter combinations
- [ ] Links between documents are not broken
- [ ] Index files reflect current command count
**Validation Commands**:
```bash
# Check for broken internal links
grep -r "\[.*\](.*\.md)" guides/ reference/ | grep -v "http"
# Verify command count consistency
actual=$(find ../../commands -name "*.md" | wc -l)
indexed=$(jq '.commands | length' index/all-commands.json)
echo "Actual: $actual, Indexed: $indexed"
```
**Output**: Validation report
---
### Step 4.2: Example Testing
**Objective**: Verify all examples are runnable
**Test Cases**:
- [ ] Copy example commands from guides
- [ ] Run in test environment
- [ ] Verify expected output
- [ ] Document any prerequisites
**Note**: Some examples may be illustrative only; mark these clearly
**Output**: Tested examples
---
### Step 4.3: Peer Review Checklist
**Objective**: Prepare documentation for review
**Review Points**:
- [ ] Is the change clearly explained?
- [ ] Are examples helpful and clear?
- [ ] Is migration guidance complete (if breaking)?
- [ ] Are troubleshooting tips adequate?
- [ ] Is the documentation easy to scan?
**Output**: Review-ready documentation
---
## 📤 Phase 5: Commit & Distribution
### Step 5.1: Git Commit Structure
**Objective**: Create clear, traceable commits
**Commit Pattern**:
```bash
git add .claude/skills/command-guide/
# Commit message format
git commit -m "docs(command-guide): update for <feature-name> changes
- Update reference docs for <changed-commands>
- Enhance <guide-name> with <feature> documentation
- Regenerate indexes (new count: <count>)
- Add troubleshooting for <new-issues>
Refs: <commit-hashes-of-source-changes>
"
```
**Commit Message Rules**:
- **Type**: `docs(command-guide)`
- **Scope**: Always `command-guide`
- **Summary**: Concise, imperative mood
- **Body**: Bullet points for each change type
- **Refs**: Link to source change commits
**Output**: Clean commit history
---
### Step 5.2: Update Distribution
**Objective**: Make updates available to users
**Actions**:
```bash
# Push to remote
git push origin main
# Verify GitHub reflects changes
# Check: https://github.com/<org>/<repo>/tree/main/.claude/skills/command-guide
```
**User Notification** (if breaking changes):
- Update project README
- Add note to main documentation
- Consider announcement in team channels
**Output**: Published updates
---
## 🔄 Phase 6: Iteration & Improvement
### Step 6.1: Gather Feedback
**Objective**: Improve documentation based on usage
**Feedback Sources**:
- User questions about changed commands
- Confusion points in examples
- Missing information requests
- Error reports
**Track**:
- Common questions → Add to troubleshooting
- Confusing examples → Simplify or expand
- Missing use cases → Add to guides
**Output**: Improvement backlog
---
### Step 6.2: Continuous Refinement
**Objective**: Keep documentation evolving
**Regular Tasks**:
- [ ] Review index statistics monthly
- [ ] Update examples with real-world usage
- [ ] Consolidate redundant sections
- [ ] Expand troubleshooting based on issues
- [ ] Refresh screenshots/outputs if UI changed
**Output**: Living documentation
---
## 📐 Update Decision Matrix
Use this matrix to determine update depth:
| Change Scope | Reference Docs | Workflow Guides | Examples | Indexes | Migration Guide |
|--------------|----------------|-----------------|----------|---------|-----------------|
| **New Parameter** | Update command file | Add parameter note | Add usage example | Regenerate | No |
| **Workflow Refactor** | Update all affected | Major revision | Update all examples | Regenerate | If breaking |
| **New Command** | Copy new file | Add workflow pattern | Add examples | Regenerate | No |
| **Architecture Change** | Update all affected | Major revision | Comprehensive update | Regenerate | Yes |
| **Bug Fix** | Update description | Add note if user-visible | Fix incorrect examples | No change | No |
| **New Feature** | Update affected files | Add feature section | Add feature examples | Regenerate | No |
---
## 🎯 Quality Gates
Before considering documentation update complete, verify:
### Gate 1: Completeness
- [ ] All changed commands have updated reference docs
- [ ] All new features are documented in guides
- [ ] All examples are current and correct
- [ ] Indexes reflect current state
### Gate 2: Clarity
- [ ] Non-expert can understand changes
- [ ] Examples demonstrate key use cases
- [ ] Migration path is clear (if breaking)
- [ ] Troubleshooting covers common issues
### Gate 3: Consistency
- [ ] Terminology is consistent across docs
- [ ] Parameter descriptions match everywhere
- [ ] Cross-references are accurate
- [ ] Formatting follows established patterns
### Gate 4: Accessibility
- [ ] Table of contents is current
- [ ] Search/navigation works
- [ ] Related docs are linked
- [ ] Issue templates reference new content
---
## 🚀 Quick Start Template
When updates are needed, follow this abbreviated workflow:
```bash
# 1. ANALYZE (5 min)
git log --oneline --since="<last-update>" --grep="command\|agent" -20
# → Identify what changed
# 2. EXTRACT (10 min)
git show <commit-hash> --stat
git diff <commit>..HEAD --stat .claude/commands/
# → Understand changes
# 3. UPDATE (30 min)
# - Update affected guide sections (ui-design-workflow-guide.md, etc.)
# - Add examples for new features
# - Document parameter changes
# 4. SYNC & REGENERATE (2 min)
cd /d/Claude_dms3/.claude/skills/command-guide
python scripts/analyze_commands.py
# → Syncs reference docs + regenerates all 5 indexes
# 5. VALIDATE (10 min)
# - Test examples
# - Check consistency
# - Verify links
# 6. COMMIT (5 min)
git add .claude/skills/command-guide/
git commit -m "docs(command-guide): update for <feature> changes"
git push origin main
```
**Total Time**: ~1 hour for typical update
---
## 🔗 Related Resources
- **Python Index Script**: `.claude/skills/command-guide/scripts/analyze_commands.py`
- **Issue Templates**: `.claude/skills/command-guide/templates/`
- **SKILL Entry Point**: `.claude/skills/command-guide/SKILL.md`
- **Reference Source**: `.claude/commands/` and `.claude/agents/`
---
## 📌 Appendix: Common Patterns
### Pattern 1: New Parameter Addition
**Example**: `--interactive` flag added to `explore-auto`
**Update Sequence**:
1. Update `guides/ui-design-workflow-guide.md` with interactive examples
2. Add "When to Use" guidance
3. Run Python script to sync reference docs and regenerate indexes
4. Update argument-hint in examples
---
### Pattern 2: Workflow Reorganization
**Example**: Layout extraction split into concept generation + selection
**Update Sequence**:
1. Major revision of workflow guide section
2. Update all workflow examples
3. Add migration notes for existing users
4. Update troubleshooting
5. Run Python script to sync and regenerate indexes
---
### Pattern 3: Architecture Change
**Example**: Agent execution model changed
**Update Sequence**:
1. Update `guides/implementation-details.md`
2. Revise all workflow patterns using affected agents
3. Create migration guide
4. Update examples comprehensively
5. Run Python script to sync and regenerate indexes
6. Add extensive troubleshooting
---
**End of Update Guideline**
This guideline is a living document. Improve it based on update experience.

Some files were not shown because too many files have changed in this diff Show More