Remove outdated references to .active-session marker files that are no longer used in the workflow implementation. The system now uses directory-based session management where active sessions are identified by their location in .workflow/active/ directory.
Changes:
- WORKFLOW_DIAGRAMS.md: Replace .active-session marker with actual directory structure
- COMMAND_SPEC.md: Update session:complete description to reflect directory-based archival
The .archiving marker is still valid and used for transactional session completion.
Removed all URL-related parameters and functionality from UI design commands
as they are no longer supported. All commands now only accept local files.
Changes:
- style-extract.md: Removed --urls parameter and all URL mode logic
- layout-extract.md: Removed --urls parameter and DOM extraction via URLs
- COMMAND_SPEC.md: Deleted capture and explore-layers commands, updated syntax
Affected commands:
- /workflow:ui-design:style-extract: Only accepts --images and --prompt
- /workflow:ui-design:layout-extract: Only accepts --images and --prompt
- Removed: /workflow:ui-design:capture (command deleted)
- Removed: /workflow:ui-design:explore-layers (command deleted)
All UI workflow commands now require manual input of local resources
(images, code files, HTML, CSS, JS) instead of fetching from URLs.
The /workflow:ui-design:imitate-auto command no longer supports URL input.
Updated all documentation to reflect that it now only accepts:
- Local image files (glob patterns)
- Local code files/directories
- Text prompts
Changes:
- COMMAND_SPEC.md: Updated syntax and examples
- WORKFLOW_DECISION_GUIDE.md/.._EN.md: Replaced URL examples with local file examples
- EXAMPLES.md: Updated design system creation example
- GETTING_STARTED.md/.._CN.md: Fixed command descriptions
- ui-design-workflow-guide.md: Updated multiple sections and examples
Note: layout-extract still supports --urls parameter (not changed)
Add new CLI mode for systematic technical document analysis with:
- CLI command: /cli:mode:document-analysis for Gemini/Qwen/Codex
- Comprehensive analysis template with 6-phase protocol
- Support for README, API docs, research papers, specifications, tutorials
- Evidence-based analysis with pre-planning and self-critique requirements
- Precise language constraints and structured output format
Template features:
- Pre-analysis planning phase for approach definition
- Multi-phase analysis: assessment, extraction, critical analysis, synthesis
- Self-critique requirement before final output
- Mandatory section references and evidence citations
- Output length control proportional to document size
Add comprehensive explanation of how CLI tool results can be saved and
reused as context for subsequent operations:
- Result persistence in workflow sessions (.chat/ directory)
- Using analysis results as planning basis
- Using analysis results as implementation basis
- Cross-session references
- Memory update loops with iterative optimization
- Visual memory flow diagram showing phase-to-phase context passing
- Best practices for maintaining continuity and quality
This enables intelligent workflows where Gemini/Qwen analysis informs
Codex implementation, and all results accumulate as project memory for
future decision-making. Integrates with /workflow:plan and
/workflow:lite-plan commands.
Add comprehensive section on multi-model CLI collaboration (Gemini/Qwen/Codex):
- Three execution modes: serial, parallel, and hybrid
- Semantic invocation vs command invocation patterns
- Integration examples with Lite and Full workflows
- Best practices for tool selection and execution strategies
Updates both Chinese and English versions with practical examples showing
how to leverage ultra-long context models (Gemini/Qwen) for analysis and
Codex for precise code implementation.
Add --dashboard parameter to /workflow:status command that generates
an interactive HTML task board displaying active and archived sessions.
Features:
- Responsive layout with modern CSS design
- Real-time statistics for sessions and tasks
- Task cards with status indicators (pending/in_progress/completed)
- Progress bars for each session
- Search and filter functionality
- Dark/light theme toggle
- Separate panels for active and archived sessions
Implementation:
- Added Dashboard Mode section to .claude/commands/workflow/status.md
- Created HTML template at .claude/templates/workflow-dashboard.html
- Template uses data injection pattern with {{WORKFLOW_DATA}} placeholder
- Generated dashboard saved to .workflow/dashboard.html
Usage:
/workflow:status --dashboard
The dashboard provides a visual overview of all workflow sessions
and their tasks, making it easier to track project progress.
Changed all Chinese text to English for consistency:
- Table headers: "适用场景" → "Use Case", "流程特点" → "Workflow Characteristics"
- Example comments: Chinese descriptions → English descriptions
- All mixed language content now fully in English
Maintains same structure and functionality (707 lines).
Add WORKFLOW_DECISION_GUIDE_EN.md with complete English translation of the workflow decision guide, including:
- Full lifecycle command selection flowchart
- Decision point explanations with examples
- Testing and review strategies
- Complete flows for typical scenarios
- Quick reference tables by knowledge level, project phase, and work mode
- Best practices and common pitfalls
Optimize the Phase 2 output filename in /memory:docs command for better clarity:
- Old: phase2-analysis.json (generic, non-descriptive)
- New: doc-planning-data.json (clear purpose, self-documenting)
The new name better reflects that this file contains comprehensive
documentation planning data including folder analysis, grouping
information, existing docs, and statistics.
Updated all references in command documentation and skill guides.
Major improvements to workflow understanding and guidance:
1. New Document: WORKFLOW_DECISION_GUIDE.md
- Comprehensive decision flowchart for full software lifecycle
- Interactive Mermaid diagram with 40+ decision points
- Clear guidance on when to use each command
- Real-world scenarios for all workflow types
- Quick reference tables by knowledge level, project stage, and mode
- Expert tips and common pitfalls
2. Clarified Brainstorm vs Plan Relationship
Core concept correction:
- Brainstorm: Use when you know WHAT to build, NOT HOW
- Plan: Use when you know both WHAT and HOW
- Plan can accept user input OR brainstorm output
3. Updated Documentation Files
- GETTING_STARTED.md: Added clear distinction and decision criteria
- GETTING_STARTED_CN.md: Chinese version with same clarifications
- FAQ.md: Enhanced brainstorm usage explanation with workflow comparison table
- README.md: Added Workflow Decision Guide link
- README_CN.md: Added Chinese link to decision guide
4. Key Improvements
When to Use Brainstorming:
- Unclear solution approach (multiple ways to solve)
- Architectural exploration needed
- Requirements clarification (high-level clear, details not)
- Multiple trade-offs to analyze
- Unfamiliar domain
When to Skip Brainstorming:
- Clear implementation approach
- Similar to existing code patterns
- Well-defined requirements
- Simple features
5. Decision Flowchart Covers:
- Ideation phase (know what to build?)
- Design phase (know how to build?)
- UI design phase (need UI design?)
- Planning phase (complexity level?)
- Testing phase (TDD, post-test, test-fix?)
- Review phase (security, architecture, quality?)
- Completion
Benefits:
- Eliminates confusion about brainstorm usage
- Provides clear decision criteria for all commands
- Visual flowchart helps users navigate workflows
- Comprehensive coverage of all development stages
- Reduces trial-and-error in workflow selection
Files modified: 5
Files added: 1 (WORKFLOW_DECISION_GUIDE.md)
Add four new comprehensive documentation files and update READMEs:
New Documentation:
- ARCHITECTURE.md: High-level system architecture overview
* Design philosophy and core principles
* System components and data flow
* Multi-agent system details
* CLI tool integration strategy
* Session and memory management
* Performance optimizations and best practices
- CONTRIBUTING.md: Contributor guidelines
* Code of conduct
* Development setup instructions
* Coding standards and best practices
* Testing guidelines
* Documentation requirements
* Pull request process
* Release process
- FAQ.md: Frequently asked questions
* General questions about CCW
* Installation and setup
* Usage and workflows
* Commands and syntax
* Sessions and tasks
* Agents and tools
* Memory system
* Troubleshooting
* Advanced topics
- EXAMPLES.md: Real-world use cases
* Quick start examples
* Web development (Express, React, e-commerce)
* API development (REST, GraphQL)
* Testing & quality assurance (TDD, test generation)
* Refactoring (monolith to microservices)
* UI/UX design (design systems, landing pages)
* Bug fixes (simple and complex)
* Documentation generation
* DevOps & automation (CI/CD, Docker)
* Complex projects (chat app, analytics dashboard)
Updated Documentation:
- README.md: Added comprehensive documentation section
* Organized docs into categories
* Links to all new documentation files
* Improved navigation structure
- README_CN.md: Added documentation section (Chinese)
* Same organization as English version
* Links to all documentation resources
Benefits:
- Provides clear entry points for new users
- Comprehensive reference for all features
- Real-world examples for practical learning
- Complete contributor onboarding
- Better project discoverability
Remove unnecessary Core Principles sections that reference task-core.md
and workflow-architecture.md from both workflow:replan and task:replan
documentation to align with execute.md style and maintain simplicity.
Removed 104 lines of version history and enhancement documentation (lines 420-523):
- TDD Workflow Enhancements section
- Key Improvements (adopted features from test-gen and plan workflows)
- Workflow Comparison table (Previous vs Current)
- Migration Notes and backward compatibility info
- Configuration examples
This content represented ~19% of the file and was historical/evolutionary
information rather than core command functionality. Focuses the documentation
on what the command does, not how it evolved.
Improves task focus and documentation clarity as identified in audit report.
