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.
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.
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.
- Simplify Phase 1-3: Use unified principles (Detect→Classify→Store) to avoid string concatenation and escaping
- Reduce Phase 1-3 from 70+ lines to 30 lines with clear priority chains
- Remove Phase 11 (preview generation): Delegated to generate.md command to eliminate duplication
- Update workflow from 11 phases to 10 phases
- Convert all content to English for internationalization
- Update TodoWrite pattern from 5 tasks to 4 tasks (remove preview generation task)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Updated output paths in various command files to reflect the new structure: `.workflow/sessions/{session_id}/` instead of `.workflow/{session_id}/`.
- Adjusted documentation and code comments to ensure consistency across all agents and commands.
- Ensured that all references to session-related files are correctly pointing to the new directory format.
Restructure lite-plan.md (844→668 lines, -176) and lite-execute.md (597→569 lines, -28) following agent document patterns. Move Data Structures sections to end as reference, simplify repeated content, improve hierarchical organization. All original content preserved.
Key changes:
- Data Structures moved to end (from beginning)
- Simplified Execution Process to avoid duplication
- Improved section hierarchy and flow
- Consistent structure across both documents
Restructure cli-lite-planning-agent.md and cli-planning-agent.md following action-planning-agent.md's clear hierarchical pattern. Merge duplicate content, consolidate sections, and improve readability while preserving all original information.
Issue found by Gemini analysis:
- executionContext.planObject.tasks was incorrectly documented as string[]
- Actual runtime structure is array of structured task objects (7 fields)
- This caused documentation mismatch between lite-plan and lite-execute
Fix:
- Update executionContext definition to show full task object structure
- Add comment clarifying it's an array of structured objects (7 fields each)
- Aligns with actual implementation and lite-execute consumption logic
Impact: Documentation only (no code changes, runtime behavior was already correct)
Major changes:
- Add cli-lite-planning-agent.md for generating structured task objects
- Upgrade planObject.tasks from string[] to structured objects with 7 fields:
- title, file, action, description (what to do)
- implementation (3-7 steps on how to do it)
- reference (pattern, files, examples to follow)
- acceptance (verification criteria)
- Update lite-execute.md to format structured tasks for Agent/Codex execution
- Clean up agent files: remove "how to call me" sections (cli-planning-agent, cli-explore-agent)
- Update lite-plan.md to use cli-lite-planning-agent for Medium/High complexity tasks
Benefits:
- Execution agents receive complete "how to do" guidance instead of vague descriptions
- Each task includes specific file paths, implementation steps, and verification criteria
- Clear separation of concerns: agents only describe what they do, not how they are called
- Architecture validated by Gemini: 100% consistency, no responsibility leakage
Breaking changes: None (backward compatible via task.title || task fallback in lite-execute)
Changes:
1. Initialize previousExecutionResults array in Step 5.1
2. Add id field to executionCalls objects (format: [Method-Index])
3. Add execution loop structure in Step 5.2 showing sequential processing
4. Clarify executionId comes from executionCalls[currentIndex].id
5. Add comments explaining ID storage for result collection
Benefits:
- Clear definition of where executionId comes from
- Explicit initialization of tracking variables
- Better understanding of execution flow and result collection
- Proper context continuity across multiple execution calls
Improvements:
1. Add plan summary in confirmation question for quick review
2. Add previousExecutionResults tracking for multi-execution flows
3. Include execution result collection mechanism after each call
4. Update both Agent and Codex execution prompts with context continuity
Benefits:
- Subsequent executions can see what previous calls completed
- Avoid duplicate work across multiple execution calls
- Better dependency management and task flow
- Clear context propagation: executionId, status, tasks, outputs, notes
Change Phase 4 confirmation flow from single-step to two-step process:
- Step 4.1: Display complete plan as readable text output
- Step 4.2: Collect three-dimensional input via AskUserQuestion
Benefits:
- Clearer plan presentation (not embedded in question)
- Simpler question interface focused on user decisions
- Better user experience with logical separation
- Deleted the `list` command for design runs.
- Removed the `update` command and its associated documentation.
- Introduced `design-sync` command to synchronize finalized design system references to brainstorming artifacts.
- Updated command references in `COMMAND_REFERENCE.md`, `GETTING_STARTED.md`, and `GETTING_STARTED_CN.md` to reflect the new command structure.
- Ensured all related documentation and output styles are consistent with the new command naming and functionality.
