fix: use ~/.claude path format for template reference

Update template path from .claude/templates to ~/.claude/templates
to follow project convention for path references.

.claude/commands/memory/docs.md

@@ -89,7 +89,7 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${project_name} -type f -name "*.md" ! -path "*/README.md" ! -path "*/ARCHITECTURE.md" ! -path "*/EXAMPLES.md" ! -path "*/api/*" 2>/dev/null | xargs cat 2>/dev/null; fi)
 ```
 
-**Data Processing**: Parse bash outputs, calculate statistics, use **Write tool** to create `${session_dir}/.process/phase2-analysis.json` with structure:
+**Data Processing**: Parse bash outputs, calculate statistics, use **Write tool** to create `${session_dir}/.process/doc-planning-data.json` with structure:
 
 ```json
 {
@@ -118,7 +118,7 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 
 **Then** use **Edit tool** to update `workflow-session.json` adding analysis field.
 
-**Output**: Single `phase2-analysis.json` with all analysis data (no temp files or Python scripts).
+**Output**: Single `doc-planning-data.json` with all analysis data (no temp files or Python scripts).
 
 **Auto-skipped**: Tests (`**/test/**`, `**/*.test.*`), Build (`**/node_modules/**`, `**/dist/**`), Config (root-level files), Vendor directories.
 
@@ -127,8 +127,8 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 **Commands**:
 
 ```bash
-# Count existing docs from phase2-analysis.json
-bash(cat .workflow/active/WFS-docs-{timestamp}/.process/phase2-analysis.json | jq '.existing_docs.file_list | length')
+# Count existing docs from doc-planning-data.json
+bash(cat .workflow/active/WFS-docs-{timestamp}/.process/doc-planning-data.json | jq '.existing_docs.file_list | length')
 ```
 
 **Data Processing**: Use count result, then use **Edit tool** to update `workflow-session.json`:
@@ -182,8 +182,8 @@ Large Projects (single dir >10 docs):
 **Commands**:
 
 ```bash
-# 1. Get top-level directories from phase2-analysis.json
-bash(cat .workflow/active/WFS-docs-{timestamp}/.process/phase2-analysis.json | jq -r '.top_level_dirs[]')
+# 1. Get top-level directories from doc-planning-data.json
+bash(cat .workflow/active/WFS-docs-{timestamp}/.process/doc-planning-data.json | jq -r '.top_level_dirs[]')
 
 # 2. Get mode from workflow-session.json
 bash(cat .workflow/active/WFS-docs-{timestamp}/workflow-session.json | jq -r '.mode // "full"')
@@ -201,7 +201,7 @@ bash(grep -r "router\.|@Get\|@Post" src/ 2>/dev/null && echo "API_FOUND" || echo
    - If total ≤10 docs: create group
    - If total >10 docs: split to 1 dir/group or subdivide
    - If single dir >10 docs: split by subdirectories
-3. Use **Edit tool** to update `phase2-analysis.json` adding groups field:
+3. Use **Edit tool** to update `doc-planning-data.json` adding groups field:
    ```json
    "groups": {
      "count": 3,
@@ -215,7 +215,7 @@ bash(grep -r "router\.|@Get\|@Post" src/ 2>/dev/null && echo "API_FOUND" || echo
 
 **Task ID Calculation**:
 ```bash
-group_count=$(jq '.groups.count' .workflow/active/WFS-docs-{timestamp}/.process/phase2-analysis.json)
+group_count=$(jq '.groups.count' .workflow/active/WFS-docs-{timestamp}/.process/doc-planning-data.json)
 readme_id=$((group_count + 1))   # Next ID after groups
 arch_id=$((group_count + 2))
 api_id=$((group_count + 3))
@@ -237,7 +237,7 @@ api_id=$((group_count + 3))
 
 **Generation Process**:
 1. Read configuration values (tool, cli_execute, mode) from workflow-session.json
-2. Read group assignments from phase2-analysis.json
+2. Read group assignments from doc-planning-data.json
 3. Generate Level 1 tasks (IMPL-001 to IMPL-N, one per group)
 4. Generate Level 2+ tasks if mode=full (README, ARCHITECTURE, HTTP API)
 
@@ -262,14 +262,14 @@ api_id=$((group_count + 3))
   },
   "context": {
     "requirements": [
-      "Process directories from group ${group_number} in phase2-analysis.json",
+      "Process directories from group ${group_number} in doc-planning-data.json",
       "Generate docs to .workflow/docs/${project_name}/ (mirrored structure)",
       "Code folders: API.md + README.md; Navigation folders: README.md only",
       "Use pre-analyzed data from Phase 2 (no redundant analysis)"
     ],
     "focus_paths": ["${group_dirs_from_json}"],
     "precomputed_data": {
-      "phase2_analysis": "${session_dir}/.process/phase2-analysis.json"
+      "phase2_analysis": "${session_dir}/.process/doc-planning-data.json"
     }
   },
   "flow_control": {
@@ -278,8 +278,8 @@ api_id=$((group_count + 3))
         "step": "load_precomputed_data",
         "action": "Load Phase 2 analysis and extract group directories",
         "commands": [
-          "bash(cat ${session_dir}/.process/phase2-analysis.json)",
-          "bash(jq '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories' ${session_dir}/.process/phase2-analysis.json)"
+          "bash(cat ${session_dir}/.process/doc-planning-data.json)",
+          "bash(jq '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories' ${session_dir}/.process/doc-planning-data.json)"
         ],
         "output_to": "phase2_context",
         "note": "Single JSON file contains all Phase 2 analysis results"
@@ -324,7 +324,7 @@ api_id=$((group_count + 3))
 {
   "step": 2,
   "title": "Batch generate documentation via CLI",
-  "command": "bash(dirs=$(jq -r '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories[]' ${session_dir}/.process/phase2-analysis.json); for dir in $dirs; do cd \"$dir\" && gemini --approval-mode yolo -p \"PURPOSE: Generate module docs\\nTASK: Create documentation\\nMODE: write\\nCONTEXT: @**/* [phase2_context]\\nEXPECTED: API.md and README.md\\nRULES: Mirror structure\" || echo \"Failed: $dir\"; cd -; done)",
+  "command": "bash(dirs=$(jq -r '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories[]' ${session_dir}/.process/doc-planning-data.json); for dir in $dirs; do cd \"$dir\" && gemini --approval-mode yolo -p \"PURPOSE: Generate module docs\\nTASK: Create documentation\\nMODE: write\\nCONTEXT: @**/* [phase2_context]\\nEXPECTED: API.md and README.md\\nRULES: Mirror structure\" || echo \"Failed: $dir\"; cd -; done)",
   "depends_on": [1],
   "output": "generated_docs"
 }
@@ -464,7 +464,7 @@ api_id=$((group_count + 3))
     ├── IMPL_PLAN.md
     ├── TODO_LIST.md
     ├── .process/
-    │   └── phase2-analysis.json         # All Phase 2 analysis data (replaces 7+ files)
+    │   └── doc-planning-data.json       # All Phase 2 analysis data (replaces 7+ files)
     └── .task/
         ├── IMPL-001.json                # Small: all modules | Large: group 1
         ├── IMPL-00N.json                # (Large only: groups 2-N)
@@ -473,7 +473,7 @@ api_id=$((group_count + 3))
         └── IMPL-{N+3}.json              # HTTP API (optional)
 ```
 
-**phase2-analysis.json Structure**:
+**doc-planning-data.json Structure**:
 ```json
 {
   "metadata": {

.claude/commands/workflow/status.md

@@ -1,15 +1,16 @@
 ---
 name: workflow:status
 description: Generate on-demand views for project overview and workflow tasks with optional task-id filtering for detailed view
-argument-hint: "[optional: --project|task-id|--validate]"
+argument-hint: "[optional: --project|task-id|--validate|--dashboard]"
 ---
 
 # Workflow Status Command (/workflow:status)
 
 ## Overview
-Generates on-demand views from project and session data. Supports two modes:
+Generates on-demand views from project and session data. Supports multiple modes:
 1. **Project Overview** (`--project`): Shows completed features and project statistics
 2. **Workflow Tasks** (default): Shows current session task progress
+3. **HTML Dashboard** (`--dashboard`): Generates interactive HTML task board with active and archived sessions
 
 No synchronization needed - all views are calculated from current JSON state.
 
@@ -19,6 +20,7 @@ No synchronization needed - all views are calculated from current JSON state.
 /workflow:status --project          # Show project-level feature registry
 /workflow:status impl-1             # Show specific task details
 /workflow:status --validate         # Validate workflow integrity
+/workflow:status --dashboard        # Generate HTML dashboard board
 ```
 
 ## Implementation Flow
@@ -192,4 +194,135 @@ find .workflow/active/WFS-session/.summaries/ -name "*.md" -type f 2>/dev/null |
 
 ## Completed Tasks
 - [COMPLETED] impl-0: Setup completed
+```
+
+## Dashboard Mode (HTML Board)
+
+### Step 1: Check for --dashboard flag
+```bash
+# If --dashboard flag present → Execute Dashboard Mode
+```
+
+### Step 2: Collect Workflow Data
+
+**Collect Active Sessions**:
+```bash
+# Find all active sessions
+find .workflow/active/ -name "WFS-*" -type d 2>/dev/null
+
+# For each active session, read metadata and tasks
+for session in $(find .workflow/active/ -name "WFS-*" -type d 2>/dev/null); do
+  cat "$session/workflow-session.json"
+  find "$session/.task/" -name "*.json" -type f 2>/dev/null
+done
+```
+
+**Collect Archived Sessions**:
+```bash
+# Find all archived sessions
+find .workflow/archives/ -name "WFS-*" -type d 2>/dev/null
+
+# Read manifest if exists
+cat .workflow/archives/manifest.json 2>/dev/null
+
+# For each archived session, read metadata
+for archive in $(find .workflow/archives/ -name "WFS-*" -type d 2>/dev/null); do
+  cat "$archive/workflow-session.json" 2>/dev/null
+  # Count completed tasks
+  find "$archive/.task/" -name "*.json" -type f 2>/dev/null | wc -l
+done
+```
+
+### Step 3: Process and Structure Data
+
+**Build data structure for dashboard**:
+```javascript
+const dashboardData = {
+  activeSessions: [],
+  archivedSessions: [],
+  generatedAt: new Date().toISOString()
+};
+
+// Process active sessions
+for each active_session in active_sessions:
+  const sessionData = JSON.parse(Read(active_session/workflow-session.json));
+  const tasks = [];
+
+  // Load all tasks for this session
+  for each task_file in find(active_session/.task/*.json):
+    const taskData = JSON.parse(Read(task_file));
+    tasks.push({
+      task_id: taskData.task_id,
+      title: taskData.title,
+      status: taskData.status,
+      type: taskData.type
+    });
+
+  dashboardData.activeSessions.push({
+    session_id: sessionData.session_id,
+    project: sessionData.project,
+    status: sessionData.status,
+    created_at: sessionData.created_at || sessionData.initialized_at,
+    tasks: tasks
+  });
+
+// Process archived sessions
+for each archived_session in archived_sessions:
+  const sessionData = JSON.parse(Read(archived_session/workflow-session.json));
+  const taskCount = bash(find archived_session/.task/*.json | wc -l);
+
+  dashboardData.archivedSessions.push({
+    session_id: sessionData.session_id,
+    project: sessionData.project,
+    archived_at: sessionData.completed_at || sessionData.archived_at,
+    taskCount: parseInt(taskCount),
+    archive_path: archived_session
+  });
+```
+
+### Step 4: Generate HTML from Template
+
+**Load template and inject data**:
+```javascript
+// Read the HTML template
+const template = Read("~/.claude/templates/workflow-dashboard.html");
+
+// Prepare data for injection
+const dataJson = JSON.stringify(dashboardData, null, 2);
+
+// Replace placeholder with actual data
+const htmlContent = template.replace('{{WORKFLOW_DATA}}', dataJson);
+
+// Ensure .workflow directory exists
+bash(mkdir -p .workflow);
+```
+
+### Step 5: Write HTML File
+
+```bash
+# Write the generated HTML to .workflow/dashboard.html
+Write({
+  file_path: ".workflow/dashboard.html",
+  content: htmlContent
+})
+```
+
+### Step 6: Display Success Message
+
+```markdown
+Dashboard generated successfully!
+
+Location: .workflow/dashboard.html
+
+Open in browser:
+  file://$(pwd)/.workflow/dashboard.html
+
+Features:
+- 📊 Active sessions overview
+- 📦 Archived sessions history
+- 🔍 Search and filter
+- 📈 Progress tracking
+- 🎨 Dark/light theme
+
+Refresh data: Re-run /workflow:status --dashboard
 ```

.claude/skills/command-guide/reference/commands/memory/docs.md

@@ -89,7 +89,7 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${project_name} -type f -name "*.md" ! -path "*/README.md" ! -path "*/ARCHITECTURE.md" ! -path "*/EXAMPLES.md" ! -path "*/api/*" 2>/dev/null | xargs cat 2>/dev/null; fi)
 ```
 
-**Data Processing**: Parse bash outputs, calculate statistics, use **Write tool** to create `${session_dir}/.process/phase2-analysis.json` with structure:
+**Data Processing**: Parse bash outputs, calculate statistics, use **Write tool** to create `${session_dir}/.process/doc-planning-data.json` with structure:
 
 ```json
 {
@@ -118,7 +118,7 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 
 **Then** use **Edit tool** to update `workflow-session.json` adding analysis field.
 
-**Output**: Single `phase2-analysis.json` with all analysis data (no temp files or Python scripts).
+**Output**: Single `doc-planning-data.json` with all analysis data (no temp files or Python scripts).
 
 **Auto-skipped**: Tests (`**/test/**`, `**/*.test.*`), Build (`**/node_modules/**`, `**/dist/**`), Config (root-level files), Vendor directories.
 
@@ -127,8 +127,8 @@ bash(if [ -d .workflow/docs/\${project_name} ]; then find .workflow/docs/\${proj
 **Commands**:
 
 ```bash
-# Count existing docs from phase2-analysis.json
-bash(cat .workflow/WFS-docs-{timestamp}/.process/phase2-analysis.json | jq '.existing_docs.file_list | length')
+# Count existing docs from doc-planning-data.json
+bash(cat .workflow/WFS-docs-{timestamp}/.process/doc-planning-data.json | jq '.existing_docs.file_list | length')
 ```
 
 **Data Processing**: Use count result, then use **Edit tool** to update `workflow-session.json`:
@@ -182,8 +182,8 @@ Large Projects (single dir >10 docs):
 **Commands**:
 
 ```bash
-# 1. Get top-level directories from phase2-analysis.json
-bash(cat .workflow/WFS-docs-{timestamp}/.process/phase2-analysis.json | jq -r '.top_level_dirs[]')
+# 1. Get top-level directories from doc-planning-data.json
+bash(cat .workflow/WFS-docs-{timestamp}/.process/doc-planning-data.json | jq -r '.top_level_dirs[]')
 
 # 2. Get mode from workflow-session.json
 bash(cat .workflow/WFS-docs-{timestamp}/workflow-session.json | jq -r '.mode // "full"')
@@ -201,7 +201,7 @@ bash(grep -r "router\.|@Get\|@Post" src/ 2>/dev/null && echo "API_FOUND" || echo
    - If total ≤10 docs: create group
    - If total >10 docs: split to 1 dir/group or subdivide
    - If single dir >10 docs: split by subdirectories
-3. Use **Edit tool** to update `phase2-analysis.json` adding groups field:
+3. Use **Edit tool** to update `doc-planning-data.json` adding groups field:
    ```json
    "groups": {
      "count": 3,
@@ -215,7 +215,7 @@ bash(grep -r "router\.|@Get\|@Post" src/ 2>/dev/null && echo "API_FOUND" || echo
 
 **Task ID Calculation**:
 ```bash
-group_count=$(jq '.groups.count' .workflow/WFS-docs-{timestamp}/.process/phase2-analysis.json)
+group_count=$(jq '.groups.count' .workflow/WFS-docs-{timestamp}/.process/doc-planning-data.json)
 readme_id=$((group_count + 1))   # Next ID after groups
 arch_id=$((group_count + 2))
 api_id=$((group_count + 3))
@@ -237,7 +237,7 @@ api_id=$((group_count + 3))
 
 **Generation Process**:
 1. Read configuration values (tool, cli_execute, mode) from workflow-session.json
-2. Read group assignments from phase2-analysis.json
+2. Read group assignments from doc-planning-data.json
 3. Generate Level 1 tasks (IMPL-001 to IMPL-N, one per group)
 4. Generate Level 2+ tasks if mode=full (README, ARCHITECTURE, HTTP API)
 
@@ -262,14 +262,14 @@ api_id=$((group_count + 3))
   },
   "context": {
     "requirements": [
-      "Process directories from group ${group_number} in phase2-analysis.json",
+      "Process directories from group ${group_number} in doc-planning-data.json",
       "Generate docs to .workflow/docs/${project_name}/ (mirrored structure)",
       "Code folders: API.md + README.md; Navigation folders: README.md only",
       "Use pre-analyzed data from Phase 2 (no redundant analysis)"
     ],
     "focus_paths": ["${group_dirs_from_json}"],
     "precomputed_data": {
-      "phase2_analysis": "${session_dir}/.process/phase2-analysis.json"
+      "phase2_analysis": "${session_dir}/.process/doc-planning-data.json"
     }
   },
   "flow_control": {
@@ -278,8 +278,8 @@ api_id=$((group_count + 3))
         "step": "load_precomputed_data",
         "action": "Load Phase 2 analysis and extract group directories",
         "commands": [
-          "bash(cat ${session_dir}/.process/phase2-analysis.json)",
-          "bash(jq '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories' ${session_dir}/.process/phase2-analysis.json)"
+          "bash(cat ${session_dir}/.process/doc-planning-data.json)",
+          "bash(jq '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories' ${session_dir}/.process/doc-planning-data.json)"
         ],
         "output_to": "phase2_context",
         "note": "Single JSON file contains all Phase 2 analysis results"
@@ -324,7 +324,7 @@ api_id=$((group_count + 3))
 {
   "step": 2,
   "title": "Batch generate documentation via CLI",
-  "command": "bash(dirs=$(jq -r '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories[]' ${session_dir}/.process/phase2-analysis.json); for dir in $dirs; do cd \"$dir\" && gemini --approval-mode yolo -p \"PURPOSE: Generate module docs\\nTASK: Create documentation\\nMODE: write\\nCONTEXT: @**/* [phase2_context]\\nEXPECTED: API.md and README.md\\nRULES: Mirror structure\" || echo \"Failed: $dir\"; cd -; done)",
+  "command": "bash(dirs=$(jq -r '.groups.assignments[] | select(.group_id == \"${group_number}\") | .directories[]' ${session_dir}/.process/doc-planning-data.json); for dir in $dirs; do cd \"$dir\" && gemini --approval-mode yolo -p \"PURPOSE: Generate module docs\\nTASK: Create documentation\\nMODE: write\\nCONTEXT: @**/* [phase2_context]\\nEXPECTED: API.md and README.md\\nRULES: Mirror structure\" || echo \"Failed: $dir\"; cd -; done)",
   "depends_on": [1],
   "output": "generated_docs"
 }
@@ -464,7 +464,7 @@ api_id=$((group_count + 3))
     ├── IMPL_PLAN.md
     ├── TODO_LIST.md
     ├── .process/
-    │   └── phase2-analysis.json         # All Phase 2 analysis data (replaces 7+ files)
+    │   └── doc-planning-data.json         # All Phase 2 analysis data (replaces 7+ files)
     └── .task/
         ├── IMPL-001.json                # Small: all modules | Large: group 1
         ├── IMPL-00N.json                # (Large only: groups 2-N)
@@ -473,7 +473,7 @@ api_id=$((group_count + 3))
         └── IMPL-{N+3}.json              # HTTP API (optional)
 ```
 
-**phase2-analysis.json Structure**:
+**doc-planning-data.json Structure**:
 ```json
 {
   "metadata": {

.claude/templates/workflow-dashboard.html

@@ -0,0 +1,664 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta charset="UTF-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <title>Workflow Dashboard - Task Board</title>
+    <style>
+        :root {
+            --bg-primary: #f5f7fa;
+            --bg-secondary: #ffffff;
+            --bg-card: #ffffff;
+            --text-primary: #1a202c;
+            --text-secondary: #718096;
+            --border-color: #e2e8f0;
+            --accent-color: #4299e1;
+            --success-color: #48bb78;
+            --warning-color: #ed8936;
+            --danger-color: #f56565;
+            --shadow: 0 1px 3px 0 rgba(0, 0, 0, 0.1), 0 1px 2px 0 rgba(0, 0, 0, 0.06);
+            --shadow-lg: 0 10px 15px -3px rgba(0, 0, 0, 0.1), 0 4px 6px -2px rgba(0, 0, 0, 0.05);
+        }
+
+        [data-theme="dark"] {
+            --bg-primary: #1a202c;
+            --bg-secondary: #2d3748;
+            --bg-card: #2d3748;
+            --text-primary: #f7fafc;
+            --text-secondary: #a0aec0;
+            --border-color: #4a5568;
+            --shadow: 0 1px 3px 0 rgba(0, 0, 0, 0.3), 0 1px 2px 0 rgba(0, 0, 0, 0.2);
+            --shadow-lg: 0 10px 15px -3px rgba(0, 0, 0, 0.3), 0 4px 6px -2px rgba(0, 0, 0, 0.2);
+        }
+
+        * {
+            margin: 0;
+            padding: 0;
+            box-sizing: border-box;
+        }
+
+        body {
+            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
+            background-color: var(--bg-primary);
+            color: var(--text-primary);
+            line-height: 1.6;
+            transition: background-color 0.3s, color 0.3s;
+        }
+
+        .container {
+            max-width: 1400px;
+            margin: 0 auto;
+            padding: 20px;
+        }
+
+        header {
+            background-color: var(--bg-secondary);
+            box-shadow: var(--shadow);
+            padding: 20px;
+            margin-bottom: 30px;
+            border-radius: 8px;
+        }
+
+        h1 {
+            font-size: 2rem;
+            margin-bottom: 10px;
+            color: var(--accent-color);
+        }
+
+        .header-controls {
+            display: flex;
+            gap: 15px;
+            flex-wrap: wrap;
+            align-items: center;
+            margin-top: 15px;
+        }
+
+        .search-box {
+            flex: 1;
+            min-width: 250px;
+            position: relative;
+        }
+
+        .search-box input {
+            width: 100%;
+            padding: 10px 15px;
+            border: 1px solid var(--border-color);
+            border-radius: 6px;
+            background-color: var(--bg-primary);
+            color: var(--text-primary);
+            font-size: 0.95rem;
+        }
+
+        .filter-group {
+            display: flex;
+            gap: 10px;
+            flex-wrap: wrap;
+        }
+
+        .btn {
+            padding: 10px 20px;
+            border: none;
+            border-radius: 6px;
+            cursor: pointer;
+            font-size: 0.9rem;
+            font-weight: 500;
+            transition: all 0.2s;
+            background-color: var(--bg-card);
+            color: var(--text-primary);
+            border: 1px solid var(--border-color);
+        }
+
+        .btn:hover {
+            transform: translateY(-1px);
+            box-shadow: var(--shadow);
+        }
+
+        .btn.active {
+            background-color: var(--accent-color);
+            color: white;
+            border-color: var(--accent-color);
+        }
+
+        .stats-grid {
+            display: grid;
+            grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
+            gap: 20px;
+            margin-bottom: 30px;
+        }
+
+        .stat-card {
+            background-color: var(--bg-card);
+            padding: 20px;
+            border-radius: 8px;
+            box-shadow: var(--shadow);
+            transition: transform 0.2s;
+        }
+
+        .stat-card:hover {
+            transform: translateY(-2px);
+            box-shadow: var(--shadow-lg);
+        }
+
+        .stat-value {
+            font-size: 2rem;
+            font-weight: bold;
+            color: var(--accent-color);
+        }
+
+        .stat-label {
+            color: var(--text-secondary);
+            font-size: 0.9rem;
+            margin-top: 5px;
+        }
+
+        .section {
+            margin-bottom: 40px;
+        }
+
+        .section-header {
+            display: flex;
+            justify-content: space-between;
+            align-items: center;
+            margin-bottom: 20px;
+        }
+
+        .section-title {
+            font-size: 1.5rem;
+            font-weight: 600;
+        }
+
+        .sessions-grid {
+            display: grid;
+            grid-template-columns: repeat(auto-fill, minmax(350px, 1fr));
+            gap: 20px;
+        }
+
+        .session-card {
+            background-color: var(--bg-card);
+            border-radius: 8px;
+            box-shadow: var(--shadow);
+            padding: 20px;
+            transition: all 0.3s;
+        }
+
+        .session-card:hover {
+            transform: translateY(-4px);
+            box-shadow: var(--shadow-lg);
+        }
+
+        .session-header {
+            display: flex;
+            justify-content: space-between;
+            align-items: start;
+            margin-bottom: 15px;
+        }
+
+        .session-title {
+            font-size: 1.2rem;
+            font-weight: 600;
+            color: var(--text-primary);
+            margin-bottom: 5px;
+        }
+
+        .session-status {
+            padding: 4px 12px;
+            border-radius: 12px;
+            font-size: 0.75rem;
+            font-weight: 600;
+            text-transform: uppercase;
+        }
+
+        .status-active {
+            background-color: #c6f6d5;
+            color: #22543d;
+        }
+
+        .status-archived {
+            background-color: #e2e8f0;
+            color: #4a5568;
+        }
+
+        [data-theme="dark"] .status-active {
+            background-color: #22543d;
+            color: #c6f6d5;
+        }
+
+        [data-theme="dark"] .status-archived {
+            background-color: #4a5568;
+            color: #e2e8f0;
+        }
+
+        .session-meta {
+            display: flex;
+            gap: 15px;
+            font-size: 0.85rem;
+            color: var(--text-secondary);
+            margin-bottom: 15px;
+        }
+
+        .progress-bar {
+            width: 100%;
+            height: 8px;
+            background-color: var(--bg-primary);
+            border-radius: 4px;
+            overflow: hidden;
+            margin: 15px 0;
+        }
+
+        .progress-fill {
+            height: 100%;
+            background: linear-gradient(90deg, var(--accent-color), var(--success-color));
+            transition: width 0.3s;
+        }
+
+        .tasks-list {
+            margin-top: 15px;
+        }
+
+        .task-item {
+            display: flex;
+            align-items: center;
+            padding: 10px;
+            margin-bottom: 8px;
+            background-color: var(--bg-primary);
+            border-radius: 6px;
+            border-left: 3px solid var(--border-color);
+            transition: all 0.2s;
+        }
+
+        .task-item:hover {
+            transform: translateX(4px);
+        }
+
+        .task-item.completed {
+            border-left-color: var(--success-color);
+            opacity: 0.8;
+        }
+
+        .task-item.in_progress {
+            border-left-color: var(--warning-color);
+        }
+
+        .task-item.pending {
+            border-left-color: var(--text-secondary);
+        }
+
+        .task-checkbox {
+            width: 20px;
+            height: 20px;
+            border-radius: 50%;
+            border: 2px solid var(--border-color);
+            margin-right: 12px;
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            flex-shrink: 0;
+        }
+
+        .task-item.completed .task-checkbox {
+            background-color: var(--success-color);
+            border-color: var(--success-color);
+        }
+
+        .task-item.completed .task-checkbox::after {
+            content: '✓';
+            color: white;
+            font-size: 0.8rem;
+            font-weight: bold;
+        }
+
+        .task-item.in_progress .task-checkbox {
+            border-color: var(--warning-color);
+            background-color: var(--warning-color);
+        }
+
+        .task-item.in_progress .task-checkbox::after {
+            content: '⟳';
+            color: white;
+            font-size: 0.9rem;
+        }
+
+        .task-title {
+            flex: 1;
+            font-size: 0.9rem;
+        }
+
+        .task-id {
+            font-size: 0.75rem;
+            color: var(--text-secondary);
+            font-family: monospace;
+            margin-left: 10px;
+        }
+
+        .empty-state {
+            text-align: center;
+            padding: 60px 20px;
+            color: var(--text-secondary);
+        }
+
+        .empty-state-icon {
+            font-size: 4rem;
+            margin-bottom: 20px;
+            opacity: 0.5;
+        }
+
+        .theme-toggle {
+            position: fixed;
+            bottom: 30px;
+            right: 30px;
+            width: 60px;
+            height: 60px;
+            border-radius: 50%;
+            background-color: var(--accent-color);
+            color: white;
+            border: none;
+            cursor: pointer;
+            font-size: 1.5rem;
+            box-shadow: var(--shadow-lg);
+            transition: all 0.3s;
+            z-index: 1000;
+        }
+
+        .theme-toggle:hover {
+            transform: scale(1.1);
+        }
+
+        @media (max-width: 768px) {
+            .sessions-grid {
+                grid-template-columns: 1fr;
+            }
+
+            .stats-grid {
+                grid-template-columns: repeat(2, 1fr);
+            }
+
+            h1 {
+                font-size: 1.5rem;
+            }
+
+            .header-controls {
+                flex-direction: column;
+                align-items: stretch;
+            }
+
+            .search-box {
+                width: 100%;
+            }
+        }
+
+        .badge {
+            display: inline-block;
+            padding: 2px 8px;
+            border-radius: 4px;
+            font-size: 0.75rem;
+            font-weight: 500;
+            margin-left: 8px;
+        }
+
+        .badge-count {
+            background-color: var(--accent-color);
+            color: white;
+        }
+
+        .session-footer {
+            margin-top: 15px;
+            padding-top: 15px;
+            border-top: 1px solid var(--border-color);
+            font-size: 0.85rem;
+            color: var(--text-secondary);
+        }
+    </style>
+</head>
+<body>
+    <div class="container">
+        <header>
+            <h1>🚀 Workflow Dashboard</h1>
+            <p style="color: var(--text-secondary);">Task Board - Active and Archived Sessions</p>
+
+            <div class="header-controls">
+                <div class="search-box">
+                    <input type="text" id="searchInput" placeholder="🔍 Search tasks or sessions..." />
+                </div>
+
+                <div class="filter-group">
+                    <button class="btn active" data-filter="all">All</button>
+                    <button class="btn" data-filter="active">Active</button>
+                    <button class="btn" data-filter="archived">Archived</button>
+                </div>
+            </div>
+        </header>
+
+        <div class="stats-grid">
+            <div class="stat-card">
+                <div class="stat-value" id="totalSessions">0</div>
+                <div class="stat-label">Total Sessions</div>
+            </div>
+            <div class="stat-card">
+                <div class="stat-value" id="activeSessions">0</div>
+                <div class="stat-label">Active Sessions</div>
+            </div>
+            <div class="stat-card">
+                <div class="stat-value" id="totalTasks">0</div>
+                <div class="stat-label">Total Tasks</div>
+            </div>
+            <div class="stat-card">
+                <div class="stat-value" id="completedTasks">0</div>
+                <div class="stat-label">Completed Tasks</div>
+            </div>
+        </div>
+
+        <div class="section" id="activeSectionContainer">
+            <div class="section-header">
+                <h2 class="section-title">📋 Active Sessions</h2>
+            </div>
+            <div class="sessions-grid" id="activeSessions"></div>
+        </div>
+
+        <div class="section" id="archivedSectionContainer">
+            <div class="section-header">
+                <h2 class="section-title">📦 Archived Sessions</h2>
+            </div>
+            <div class="sessions-grid" id="archivedSessions"></div>
+        </div>
+    </div>
+
+    <button class="theme-toggle" id="themeToggle">🌙</button>
+
+    <script>
+        // Workflow data will be injected here
+        const workflowData = {{WORKFLOW_DATA}};
+
+        // Theme management
+        function initTheme() {
+            const savedTheme = localStorage.getItem('theme') || 'light';
+            document.documentElement.setAttribute('data-theme', savedTheme);
+            updateThemeIcon(savedTheme);
+        }
+
+        function toggleTheme() {
+            const currentTheme = document.documentElement.getAttribute('data-theme');
+            const newTheme = currentTheme === 'dark' ? 'light' : 'dark';
+            document.documentElement.setAttribute('data-theme', newTheme);
+            localStorage.setItem('theme', newTheme);
+            updateThemeIcon(newTheme);
+        }
+
+        function updateThemeIcon(theme) {
+            document.getElementById('themeToggle').textContent = theme === 'dark' ? '☀️' : '🌙';
+        }
+
+        // Statistics calculation
+        function updateStatistics() {
+            const stats = {
+                totalSessions: workflowData.activeSessions.length + workflowData.archivedSessions.length,
+                activeSessions: workflowData.activeSessions.length,
+                totalTasks: 0,
+                completedTasks: 0
+            };
+
+            workflowData.activeSessions.forEach(session => {
+                stats.totalTasks += session.tasks.length;
+                stats.completedTasks += session.tasks.filter(t => t.status === 'completed').length;
+            });
+
+            workflowData.archivedSessions.forEach(session => {
+                stats.totalTasks += session.taskCount || 0;
+                stats.completedTasks += session.taskCount || 0;
+            });
+
+            document.getElementById('totalSessions').textContent = stats.totalSessions;
+            document.getElementById('activeSessions').textContent = stats.activeSessions;
+            document.getElementById('totalTasks').textContent = stats.totalTasks;
+            document.getElementById('completedTasks').textContent = stats.completedTasks;
+        }
+
+        // Render session card
+        function createSessionCard(session, isActive) {
+            const card = document.createElement('div');
+            card.className = 'session-card';
+            card.dataset.sessionType = isActive ? 'active' : 'archived';
+
+            const completedTasks = isActive
+                ? session.tasks.filter(t => t.status === 'completed').length
+                : (session.taskCount || 0);
+            const totalTasks = isActive ? session.tasks.length : (session.taskCount || 0);
+            const progress = totalTasks > 0 ? (completedTasks / totalTasks * 100) : 0;
+
+            let tasksHtml = '';
+            if (isActive && session.tasks.length > 0) {
+                tasksHtml = `
+                    <div class="tasks-list">
+                        ${session.tasks.map(task => `
+                            <div class="task-item ${task.status}">
+                                <div class="task-checkbox"></div>
+                                <div class="task-title">${task.title || 'Untitled Task'}</div>
+                                <span class="task-id">${task.task_id || ''}</span>
+                            </div>
+                        `).join('')}
+                    </div>
+                `;
+            }
+
+            card.innerHTML = `
+                <div class="session-header">
+                    <div>
+                        <h3 class="session-title">${session.session_id || 'Unknown Session'}</h3>
+                        <div style="color: var(--text-secondary); font-size: 0.9rem; margin-top: 5px;">
+                            ${session.project || ''}
+                        </div>
+                    </div>
+                    <span class="session-status ${isActive ? 'status-active' : 'status-archived'}">
+                        ${isActive ? 'Active' : 'Archived'}
+                    </span>
+                </div>
+
+                <div class="session-meta">
+                    <span>📅 ${session.created_at || session.archived_at || 'N/A'}</span>
+                    <span>📊 ${completedTasks}/${totalTasks} tasks</span>
+                </div>
+
+                ${totalTasks > 0 ? `
+                    <div class="progress-bar">
+                        <div class="progress-fill" style="width: ${progress}%"></div>
+                    </div>
+                    <div style="text-align: center; font-size: 0.85rem; color: var(--text-secondary);">
+                        ${Math.round(progress)}% Complete
+                    </div>
+                ` : ''}
+
+                ${tasksHtml}
+
+                ${!isActive && session.archive_path ? `
+                    <div class="session-footer">
+                        📁 Archive: ${session.archive_path}
+                    </div>
+                ` : ''}
+            `;
+
+            return card;
+        }
+
+        // Render all sessions
+        function renderSessions(filter = 'all') {
+            const activeContainer = document.getElementById('activeSessions');
+            const archivedContainer = document.getElementById('archivedSessions');
+
+            activeContainer.innerHTML = '';
+            archivedContainer.innerHTML = '';
+
+            if (filter === 'all' || filter === 'active') {
+                if (workflowData.activeSessions.length === 0) {
+                    activeContainer.innerHTML = `
+                        <div class="empty-state">
+                            <div class="empty-state-icon">📭</div>
+                            <p>No active sessions</p>
+                        </div>
+                    `;
+                } else {
+                    workflowData.activeSessions.forEach(session => {
+                        activeContainer.appendChild(createSessionCard(session, true));
+                    });
+                }
+            }
+
+            if (filter === 'all' || filter === 'archived') {
+                if (workflowData.archivedSessions.length === 0) {
+                    archivedContainer.innerHTML = `
+                        <div class="empty-state">
+                            <div class="empty-state-icon">📦</div>
+                            <p>No archived sessions</p>
+                        </div>
+                    `;
+                } else {
+                    workflowData.archivedSessions.forEach(session => {
+                        archivedContainer.appendChild(createSessionCard(session, false));
+                    });
+                }
+            }
+
+            // Show/hide sections
+            document.getElementById('activeSectionContainer').style.display =
+                (filter === 'all' || filter === 'active') ? 'block' : 'none';
+            document.getElementById('archivedSectionContainer').style.display =
+                (filter === 'all' || filter === 'archived') ? 'block' : 'none';
+        }
+
+        // Search functionality
+        function setupSearch() {
+            const searchInput = document.getElementById('searchInput');
+            searchInput.addEventListener('input', (e) => {
+                const query = e.target.value.toLowerCase();
+                const cards = document.querySelectorAll('.session-card');
+
+                cards.forEach(card => {
+                    const text = card.textContent.toLowerCase();
+                    card.style.display = text.includes(query) ? 'block' : 'none';
+                });
+            });
+        }
+
+        // Filter functionality
+        function setupFilters() {
+            const filterButtons = document.querySelectorAll('[data-filter]');
+            filterButtons.forEach(btn => {
+                btn.addEventListener('click', () => {
+                    filterButtons.forEach(b => b.classList.remove('active'));
+                    btn.classList.add('active');
+                    renderSessions(btn.dataset.filter);
+                });
+            });
+        }
+
+        // Initialize
+        document.addEventListener('DOMContentLoaded', () => {
+            initTheme();
+            updateStatistics();
+            renderSessions();
+            setupSearch();
+            setupFilters();
+
+            document.getElementById('themeToggle').addEventListener('click', toggleTheme);
+        });
+    </script>
+</body>
+</html>

COMMAND_AMBIGUITY_ANALYSIS.md

@@ -1,374 +0,0 @@
-# Command Ambiguity Analysis
-
-## Executive Summary
-
-Analysis of 74 commands reveals **5 major ambiguity clusters** that could cause user confusion. The primary issues involve overlapping functionality in planning, execution, and analysis commands, with inconsistent parameter usage and unclear decision criteria.
-
----
-
-## Critical Ambiguities (HIGH Priority)
-
-### 1. Planning Command Overload ⚠️ CRITICAL
-
-**Problem**: 5 different "plan" commands with overlapping but distinct purposes
-
-| Command | Purpose | Outputs | Mode |
-|---------|---------|---------|------|
-| `/workflow:plan` | 5-phase planning workflow | IMPL_PLAN.md + task JSONs | Autonomous |
-| `/workflow:lite-plan` | Lightweight interactive planning | In-memory plan | Interactive |
-| `/workflow:replan` | Modify existing plans | Updates existing artifacts | Interactive |
-| `/cli:mode:plan` | Architecture planning | .chat/plan-*.md | Read-only |
-| `/cli:discuss-plan` | Multi-round collaborative planning | .chat/discuss-plan-*.md | Multi-model discussion |
-
-**Ambiguities**:
-- ❌ **Intent confusion**: Users don't know which to use for "planning"
-- ❌ **Output confusion**: Some create tasks, some don't
-- ❌ **Workflow confusion**: Different levels of automation
-- ❌ **Scope confusion**: Project-level vs architecture-level vs modification planning
-
-**User Questions**:
-- "I want to plan my project - which command do I use?"
-- "What's the difference between `/workflow:plan` and `/workflow:lite-plan`?"
-- "When should I use `/cli:mode:plan` vs `/workflow:plan`?"
-
-**Recommendations**:
-1. ✅ Create decision tree documentation
-2. ✅ Rename commands to clarify scope:
-   - `/workflow:plan` → `/workflow:project-plan` (full workflow)
-   - `/workflow:lite-plan` → `/workflow:quick-plan` (fast planning)
-   - `/cli:mode:plan` → `/cli:architecture-plan` (read-only)
-3. ✅ Add command hints in descriptions about when to use each
-
----
-
-### 2. Execution Command Confusion ⚠️ CRITICAL
-
-**Problem**: 5 different "execute" commands with different behaviors
-
-| Command | Input | Modifies Code | Auto-Approval | Context |
-|---------|-------|---------------|---------------|---------|
-| `/workflow:execute` | Session | Via agents | No | Full workflow |
-| `/workflow:lite-execute` | Plan/prompt/file | Via agent/codex | User choice | Lightweight |
-| `/cli:execute` | Description/task-id | YES | YOLO | Direct implementation |
-| `/cli:codex-execute` | Description | YES | YOLO | Multi-stage Codex |
-| `/task:execute` | task-id | Via agent | No | Single task |
-
-**Ambiguities**:
-- ❌ **Safety confusion**: Some have YOLO auto-approval, others don't
-- ❌ **Input confusion**: Different input formats
-- ❌ **Scope confusion**: Workflow vs task vs direct execution
-- ❌ **Tool confusion**: Agent vs CLI tool execution
-
-**Critical Risk**:
-- Users may accidentally use `/cli:execute` (YOLO) when they meant `/workflow:execute` (controlled)
-- This could result in unwanted code modifications
-
-**User Questions**:
-- "I have a workflow session - do I use `/workflow:execute` or `/task:execute`?"
-- "What's the difference between `/cli:execute` and `/workflow:lite-execute`?"
-- "Which execute command is safest for production code?"
-
-**Recommendations**:
-1. 🚨 Add safety warnings to YOLO commands
-2. ✅ Clear documentation on execution modes:
-   - **Workflow execution**: `/workflow:execute` (controlled, session-based)
-   - **Quick execution**: `/workflow:lite-execute` (flexible input)
-   - **Direct implementation**: `/cli:execute` (⚠️ YOLO auto-approval)
-3. ✅ Consider renaming:
-   - `/cli:execute` → `/cli:implement-auto` (emphasizes auto-approval)
-   - `/cli:codex-execute` → `/cli:codex-multi-stage`
-
----
-
-### 3. Analysis Command Overlap ⚠️ MEDIUM
-
-**Problem**: Multiple analysis commands with unclear distinctions
-
-| Command | Tool | Purpose | Output |
-|---------|------|---------|--------|
-| `/cli:analyze` | Gemini/Qwen/Codex | General codebase analysis | .chat/analyze-*.md |
-| `/cli:mode:code-analysis` | Gemini/Qwen/Codex | Execution path tracing | .chat/code-analysis-*.md |
-| `/cli:mode:bug-diagnosis` | Gemini/Qwen/Codex | Bug root cause analysis | .chat/bug-diagnosis-*.md |
-| `/cli:chat` | Gemini/Qwen/Codex | Q&A interaction | .chat/chat-*.md |
-
-**Ambiguities**:
-- ❌ **Use case overlap**: When to use general analysis vs specialized modes
-- ❌ **Template confusion**: Different templates but similar outputs
-- ❌ **Mode naming**: "mode" prefix adds extra layer of confusion
-
-**User Questions**:
-- "Should I use `/cli:analyze` or `/cli:mode:code-analysis` to understand this code?"
-- "What's special about the 'mode' commands?"
-
-**Recommendations**:
-1. ✅ Consolidate or clarify:
-   - Keep `/cli:analyze` for general use
-   - Document `/cli:mode:*` as specialized templates
-2. ✅ Add use case examples in descriptions
-3. ✅ Consider flattening:
-   - `/cli:mode:code-analysis` → `/cli:trace-execution`
-   - `/cli:mode:bug-diagnosis` → `/cli:diagnose-bug`
-
----
-
-## Medium Priority Ambiguities
-
-### 4. Task vs Workflow Command Overlap
-
-**Problem**: Parallel command hierarchies
-
-**Workflow Commands**:
-- `/workflow:plan` - Create workflow with tasks
-- `/workflow:execute` - Execute all tasks
-- `/workflow:replan` - Modify workflow
-
-**Task Commands**:
-- `/task:create` - Create individual task
-- `/task:execute` - Execute single task
-- `/task:replan` - Modify task
-
-**Ambiguities**:
-- ❌ **Scope confusion**: When to use workflow vs task commands
-- ❌ **Execution confusion**: `/task:execute` vs `/workflow:execute`
-
-**Recommendations**:
-1. ✅ Document relationship clearly:
-   - Workflow commands: Multi-task orchestration
-   - Task commands: Single-task operations
-2. ✅ Add cross-references in documentation
-
----
-
-### 5. Tool Selection Confusion (`--tool` flag)
-
-**Problem**: Many commands accept `--tool codex|gemini|qwen` without clear criteria
-
-**Commands with --tool**:
-- `/cli:execute --tool`
-- `/cli:analyze --tool`
-- `/cli:mode:plan --tool`
-- `/memory:update-full --tool`
-- And more...
-
-**Ambiguities**:
-- ❌ **Selection criteria**: No clear guidance on when to use which tool
-- ❌ **Default inconsistency**: Different defaults across commands
-- ❌ **Capability confusion**: What each tool is best for
-
-**Recommendations**:
-1. ✅ Create tool selection guide:
-   - **Gemini**: Best for analysis, planning (default for most)
-   - **Qwen**: Fallback when Gemini unavailable
-   - **Codex**: Best for complex implementation, multi-stage execution
-2. ✅ Add tool selection hints to command descriptions
-3. ✅ Document tool capabilities clearly
-
----
-
-### 6. Enhancement Flag Inconsistency
-
-**Problem**: Different enhancement flags with different meanings
-
-| Command | Flag | Meaning |
-|---------|------|---------|
-| `/cli:execute` | `--enhance` | Enhance prompt via `/enhance-prompt` |
-| `/cli:analyze` | `--enhance` | Enhance prompt via `/enhance-prompt` |
-| `/workflow:lite-plan` | `-e` or `--explore` | Force code exploration |
-| `/memory:skill-memory` | `--regenerate` | Regenerate existing files |
-
-**Ambiguities**:
-- ❌ **Flag meaning**: `-e` means different things
-- ❌ **Inconsistent naming**: `--enhance` vs `--explore` vs `--regenerate`
-
-**Recommendations**:
-1. ✅ Standardize flags:
-   - Use `--enhance` consistently for prompt enhancement
-   - Use `--explore` specifically for codebase exploration
-   - Use `--regenerate` for file regeneration
-2. ✅ Avoid short flags (`-e`) that could be ambiguous
-
----
-
-## Low Priority Observations
-
-### 7. Session Management Commands (Well-Designed ✅)
-
-**Commands**:
-- `/workflow:session:start`
-- `/workflow:session:resume`
-- `/workflow:session:complete`
-- `/workflow:session:list`
-
-**Analysis**: These are **well-designed** with clear, distinct purposes. No ambiguity found.
-
----
-
-### 8. Memory Commands (Acceptable)
-
-Memory commands follow consistent patterns but could benefit from better organization:
-- `/memory:load`
-- `/memory:docs`
-- `/memory:skill-memory`
-- `/memory:code-map-memory`
-- `/memory:update-full`
-- `/memory:update-related`
-
-**Minor Issue**: Many memory commands, but purposes are relatively clear.
-
----
-
-## Parameter Ambiguity Analysis
-
-### Common Parameter Patterns
-
-| Parameter | Commands Using It | Ambiguity Level |
-|-----------|-------------------|-----------------|
-| `--tool` | 10+ commands | HIGH - Inconsistent defaults |
-| `--enhance` | 5+ commands | MEDIUM - Similar but not identical |
-| `--session` | 8+ commands | LOW - Consistent meaning |
-| `--cli-execute` | 3+ commands | LOW - Clear meaning |
-| `-e` / `--explore` | 2+ commands | HIGH - Different meanings |
-
----
-
-## Output Ambiguity Analysis
-
-### Output Location Confusion
-
-Multiple commands output to similar locations:
-
-**`.chat/` outputs** (read-only analysis):
-- `/cli:analyze` → `.chat/analyze-*.md`
-- `/cli:mode:plan` → `.chat/plan-*.md`
-- `/cli:discuss-plan` → `.chat/discuss-plan-*.md`
-- `/cli:execute` → `.chat/execute-*.md` (❌ Misleading - actually modifies code!)
-
-**Ambiguity**:
-- Users might think all `.chat/` outputs are read-only
-- `/cli:execute` outputs to `.chat/` but modifies code (YOLO)
-
-**Recommendation**:
-- ✅ Separate execution logs from analysis logs
-- ✅ Use different directory for code-modifying operations
-
----
-
-## Decision Tree Recommendations
-
-### When to Use Planning Commands
-
-```
-START: I need to plan something
-│
-├─ Is this a new full project workflow?
-│  └─ YES → /workflow:plan (5-phase, creates tasks)
-│
-├─ Do I need quick planning without full workflow?
-│  └─ YES → /workflow:lite-plan (fast, interactive)
-│
-├─ Do I need architecture-level planning only?
-│  └─ YES → /cli:mode:plan (read-only, no tasks)
-│
-├─ Do I need multi-perspective discussion?
-│  └─ YES → /cli:discuss-plan (Gemini + Codex + Claude)
-│
-└─ Am I modifying an existing plan?
-   └─ YES → /workflow:replan (modify artifacts)
-```
-
-### When to Use Execution Commands
-
-```
-START: I need to execute/implement something
-│
-├─ Do I have an active workflow session with tasks?
-│  └─ YES → /workflow:execute (execute all tasks)
-│
-├─ Do I have a single task ID to execute?
-│  └─ YES → /task:execute IMPL-N (single task)
-│
-├─ Do I have a plan or description to execute quickly?
-│  └─ YES → /workflow:lite-execute (flexible input)
-│
-├─ Do I want direct, autonomous implementation (⚠️ YOLO)?
-│  ├─ Single-stage → /cli:execute (auto-approval)
-│  └─ Multi-stage → /cli:codex-execute (complex tasks)
-│
-└─ ⚠️ WARNING: CLI execute commands modify code without confirmation
-```
-
-### When to Use Analysis Commands
-
-```
-START: I need to analyze code
-│
-├─ General codebase understanding?
-│  └─ /cli:analyze (broad analysis)
-│
-├─ Specific execution path tracing?
-│  └─ /cli:mode:code-analysis (detailed flow)
-│
-├─ Bug diagnosis?
-│  └─ /cli:mode:bug-diagnosis (root cause)
-│
-└─ Quick Q&A?
-   └─ /cli:chat (interactive)
-```
-
----
-
-## Summary of Findings
-
-### Ambiguity Count by Severity
-
-| Severity | Count | Commands Affected |
-|----------|-------|-------------------|
-| 🚨 CRITICAL | 2 | Planning (5 cmds), Execution (5 cmds) |
-| ⚠️ HIGH | 2 | Tool selection, Enhancement flags |
-| ℹ️ MEDIUM | 3 | Analysis, Task/Workflow overlap, Output locations |
-| ✅ LOW | Multiple | Most other commands acceptable |
-
-### Key Recommendations Priority
-
-1. **🚨 URGENT**: Add safety warnings to YOLO execution commands
-2. **🚨 URGENT**: Create decision trees for planning and execution commands
-3. **⚠️ HIGH**: Standardize tool selection criteria documentation
-4. **⚠️ HIGH**: Clarify enhancement flag meanings
-5. **ℹ️ MEDIUM**: Reorganize output directories by operation type
-6. **ℹ️ MEDIUM**: Consider renaming most ambiguous commands
-
----
-
-## Recommended Actions
-
-### Immediate (Week 1)
-1. ✅ Add decision trees to documentation
-2. ✅ Add ⚠️ WARNING labels to YOLO commands
-3. ✅ Create "Which command should I use?" guide
-
-### Short-term (Month 1)
-1. ✅ Standardize flag meanings across commands
-2. ✅ Add tool selection guide
-3. ✅ Clarify command descriptions
-
-### Long-term (Future)
-1. 🤔 Consider command consolidation or renaming
-2. 🤔 Reorganize output directory structure
-3. 🤔 Add interactive command selector tool
-
----
-
-## Conclusion
-
-The command system is **powerful but complex**. The main ambiguities stem from:
-- Multiple commands with similar names serving different purposes
-- Inconsistent parameter usage
-- Unclear decision criteria for command selection
-
-**Overall Assessment**: The codebase has a well-structured command system, but would benefit significantly from:
-1. Better documentation (decision trees, use case examples)
-2. Clearer naming conventions
-3. Consistent parameter patterns
-4. Safety warnings for destructive operations
-
-**Risk Level**: MEDIUM - Experienced users can navigate, but new users will struggle. The YOLO execution commands pose the highest risk of accidental misuse.

OUTPUT_DIRECTORY_REORGANIZATION.md

@@ -1,654 +0,0 @@
-# Output Directory Reorganization Recommendations
-
-## Executive Summary
-
-Current output directory structure mixes different operation types (read-only analysis, code modifications, planning artifacts) in the same directories, leading to confusion and poor organization. This document proposes a **semantic directory structure** that separates outputs by purpose and operation type.
-
-**Impact**: Affects 30+ commands, requires phased migration
-**Priority**: MEDIUM (improves clarity, not critical functionality)
-**Effort**: 2-4 weeks for full implementation
-
----
-
-## Current Structure Analysis
-
-### Active Session Structure
-
-```
-.workflow/active/WFS-{session-id}/
-├── workflow-session.json          # Session metadata
-├── IMPL_PLAN.md                   # Planning document
-├── TODO_LIST.md                   # Progress tracking
-│
-├── .chat/                         # ⚠️ MIXED PURPOSE
-│   ├── analyze-*.md               # Read-only analysis
-│   ├── plan-*.md                  # Read-only planning
-│   ├── discuss-plan-*.md          # Read-only discussion
-│   ├── execute-*.md               # ⚠️ Code-modifying execution
-│   └── chat-*.md                  # Q&A interactions
-│
-├── .summaries/                    # Task completion summaries
-│   ├── IMPL-*-summary.md
-│   └── TEST-FIX-*-summary.md
-│
-├── .task/                         # Task definitions
-│   ├── IMPL-001.json
-│   └── IMPL-001.1.json
-│
-└── .process/                      # ⚠️ MIXED PURPOSE
-    ├── context-package.json       # Planning context
-    ├── test-context-package.json  # Test context
-    ├── phase2-analysis.json       # Temporary analysis
-    ├── CONFLICT_RESOLUTION.md     # Planning artifact
-    ├── ACTION_PLAN_VERIFICATION.md # Verification report
-    └── backup/                    # Backup storage
-        └── replan-{timestamp}/
-```
-
-### Scratchpad Structure (No Session)
-
-```
-.workflow/.scratchpad/
-├── analyze-*.md
-├── execute-*.md
-├── chat-*.md
-└── plan-*.md
-```
-
----
-
-## Problems Identified
-
-### 1. **Semantic Confusion** 🚨 CRITICAL
-
-**Problem**: `.chat/` directory contains both:
-- ✅ Read-only operations (analyze, chat, plan)
-- ⚠️ Code-modifying operations (execute)
-
-**Impact**: Users assume `.chat/` is safe (read-only), but some files represent dangerous operations
-
-**Example**:
-```bash
-# These both output to .chat/ but have VERY different impacts:
-/cli:analyze "review auth code"        # Read-only → .chat/analyze-*.md
-/cli:execute "implement auth feature"  # ⚠️ MODIFIES CODE → .chat/execute-*.md
-```
-
-### 2. **Purpose Overload**
-
-**Problem**: `.process/` used for multiple unrelated purposes:
-- Planning artifacts (context-package.json)
-- Temporary analysis (phase2-analysis.json)
-- Verification reports (ACTION_PLAN_VERIFICATION.md)
-- Backup storage (backup/)
-
-**Impact**: Difficult to understand what's in `.process/`
-
-### 3. **Inconsistent Organization**
-
-**Problem**: Different commands use different naming patterns:
-- Some use timestamps: `analyze-{timestamp}.md`
-- Some use topics: `plan-{topic}.md`
-- Some use task IDs: `IMPL-001-summary.md`
-
-**Impact**: Hard to find specific outputs
-
-### 4. **No Operation Type Distinction**
-
-**Problem**: Can't distinguish operation type from directory structure:
-- Analysis outputs mixed with execution logs
-- Planning discussions mixed with implementation records
-- No clear audit trail
-
-**Impact**: Poor traceability, difficult debugging
-
----
-
-## Proposed New Structure
-
-### Design Principles
-
-1. **Semantic Organization**: Directories reflect operation type and safety level
-2. **Clear Hierarchy**: Separate by purpose → type → chronology
-3. **Safety Indicators**: Code-modifying operations clearly separated
-4. **Consistent Naming**: Standard patterns across all commands
-5. **Backward Compatible**: Old structure accessible during migration
-
----
-
-## Recommended Structure v2.0
-
-```
-.workflow/active/WFS-{session-id}/
-│
-├── ## Core Artifacts (Root Level)
-├── workflow-session.json
-├── IMPL_PLAN.md
-├── TODO_LIST.md
-│
-├── ## Task Definitions
-├── tasks/                         # (renamed from .task/)
-│   ├── IMPL-001.json
-│   └── IMPL-001.1.json
-│
-├── ## 🟢 READ-ONLY Operations (Safe)
-├── analysis/                      # (split from .chat/)
-│   ├── code/
-│   │   ├── 2024-01-15T10-30-auth-patterns.md
-│   │   └── 2024-01-15T11-45-api-structure.md
-│   ├── architecture/
-│   │   └── 2024-01-14T09-00-caching-layer.md
-│   └── bugs/
-│       └── 2024-01-16T14-20-login-bug-diagnosis.md
-│
-├── planning/                      # (split from .chat/)
-│   ├── discussions/
-│   │   └── 2024-01-13T15-00-auth-strategy-3rounds.md
-│   ├── architecture/
-│   │   └── 2024-01-13T16-30-database-design.md
-│   └── revisions/
-│       └── 2024-01-17T10-00-replan-add-2fa.md
-│
-├── interactions/                  # (split from .chat/)
-│   ├── 2024-01-15T10-00-question-about-jwt.md
-│   └── 2024-01-15T14-30-how-to-test-auth.md
-│
-├── ## ⚠️ CODE-MODIFYING Operations (Dangerous)
-├── executions/                    # (split from .chat/)
-│   ├── implementations/
-│   │   ├── 2024-01-15T11-00-impl-jwt-auth.md
-│   │   ├── 2024-01-15T12-30-impl-user-api.md
-│   │   └── metadata.json          # Execution metadata
-│   ├── test-fixes/
-│   │   └── 2024-01-16T09-00-fix-auth-tests.md
-│   └── refactors/
-│       └── 2024-01-16T15-00-refactor-middleware.md
-│
-├── ## Completion Records
-├── summaries/                     # (kept same)
-│   ├── implementations/
-│   │   ├── IMPL-001-jwt-authentication.md
-│   │   └── IMPL-002-user-endpoints.md
-│   ├── tests/
-│   │   └── TEST-FIX-001-auth-validation.md
-│   └── index.json                 # Quick lookup
-│
-├── ## Planning Context & Artifacts
-├── context/                       # (split from .process/)
-│   ├── project/
-│   │   ├── context-package.json
-│   │   └── test-context-package.json
-│   ├── brainstorm/
-│   │   ├── guidance-specification.md
-│   │   ├── synthesis-output.md
-│   │   └── roles/
-│   │       ├── api-designer-analysis.md
-│   │       └── system-architect-analysis.md
-│   └── conflicts/
-│       └── 2024-01-14T10-00-resolution.md
-│
-├── ## Verification & Quality
-├── quality/                       # (split from .process/)
-│   ├── verifications/
-│   │   └── 2024-01-15T09-00-action-plan-verify.md
-│   ├── reviews/
-│   │   ├── 2024-01-17T11-00-security-review.md
-│   │   └── 2024-01-17T12-00-architecture-review.md
-│   └── tdd-compliance/
-│       └── 2024-01-16T16-00-cycle-analysis.md
-│
-├── ## History & Backups
-├── history/                       # (renamed from .process/backup/)
-│   ├── replans/
-│   │   └── 2024-01-17T10-00-add-2fa/
-│   │       ├── MANIFEST.md
-│   │       ├── IMPL_PLAN.md
-│   │       └── tasks/
-│   └── snapshots/
-│       └── 2024-01-15T00-00-milestone-1/
-│
-└── ## Temporary Working Data
-    └── temp/                      # (for transient analysis)
-        └── phase2-analysis.json
-```
-
-### Scratchpad Structure v2.0
-
-```
-.workflow/.scratchpad/
-├── analysis/
-├── planning/
-├── interactions/
-└── executions/          # ⚠️ Code-modifying
-```
-
----
-
-## Directory Purpose Reference
-
-| Directory | Purpose | Safety | Retention |
-|-----------|---------|--------|-----------|
-| `analysis/` | Code understanding, bug diagnosis | 🟢 Read-only | Keep indefinitely |
-| `planning/` | Architecture plans, discussions | 🟢 Read-only | Keep indefinitely |
-| `interactions/` | Q&A, chat sessions | 🟢 Read-only | Keep 30 days |
-| `executions/` | Implementation logs | ⚠️ Modifies code | Keep indefinitely |
-| `summaries/` | Task completion records | 🟢 Reference | Keep indefinitely |
-| `context/` | Planning context, brainstorm | 🟢 Reference | Keep indefinitely |
-| `quality/` | Reviews, verifications | 🟢 Reference | Keep indefinitely |
-| `history/` | Backups, snapshots | 🟢 Archive | Keep indefinitely |
-| `temp/` | Transient analysis data | 🟢 Temporary | Clean on completion |
-
----
-
-## Naming Convention Standards
-
-### Timestamp-based Files
-
-**Format**: `YYYY-MM-DDTHH-MM-{description}.md`
-
-**Examples**:
-- `2024-01-15T10-30-auth-patterns.md`
-- `2024-01-15T11-45-jwt-implementation.md`
-
-**Benefits**:
-- Chronological sorting
-- Unique identifiers
-- Easy to find by date
-
-### Task-based Files
-
-**Format**: `{TASK-ID}-{description}.md`
-
-**Examples**:
-- `IMPL-001-jwt-authentication.md`
-- `TEST-FIX-002-login-validation.md`
-
-**Benefits**:
-- Clear task association
-- Easy to find by task ID
-
-### Metadata Files
-
-**Format**: `{type}.json` or `{type}-metadata.json`
-
-**Examples**:
-- `context-package.json`
-- `execution-metadata.json`
-- `index.json`
-
----
-
-## Command Output Mapping
-
-### Analysis Commands → `analysis/`
-
-| Command | Old Location | New Location |
-|---------|-------------|--------------|
-| `/cli:analyze` | `.chat/analyze-*.md` | `analysis/code/{timestamp}-{topic}.md` |
-| `/cli:mode:code-analysis` | `.chat/code-analysis-*.md` | `analysis/code/{timestamp}-{topic}.md` |
-| `/cli:mode:bug-diagnosis` | `.chat/bug-diagnosis-*.md` | `analysis/bugs/{timestamp}-{topic}.md` |
-
-### Planning Commands → `planning/`
-
-| Command | Old Location | New Location |
-|---------|-------------|--------------|
-| `/cli:mode:plan` | `.chat/plan-*.md` | `planning/architecture/{timestamp}-{topic}.md` |
-| `/cli:discuss-plan` | `.chat/discuss-plan-*.md` | `planning/discussions/{timestamp}-{topic}.md` |
-| `/workflow:replan` | (modifies artifacts) | `planning/revisions/{timestamp}-{reason}.md` |
-
-### Execution Commands → `executions/`
-
-| Command | Old Location | New Location |
-|---------|-------------|--------------|
-| `/cli:execute` | `.chat/execute-*.md` | `executions/implementations/{timestamp}-{description}.md` |
-| `/cli:codex-execute` | `.chat/codex-*.md` | `executions/implementations/{timestamp}-{description}.md` |
-| `/workflow:execute` | (multiple) | `executions/implementations/{timestamp}-{task-id}.md` |
-| `/workflow:test-cycle-execute` | (various) | `executions/test-fixes/{timestamp}-cycle-{n}.md` |
-
-### Quality Commands → `quality/`
-
-| Command | Old Location | New Location |
-|---------|-------------|--------------|
-| `/workflow:action-plan-verify` | `.process/ACTION_PLAN_VERIFICATION.md` | `quality/verifications/{timestamp}-action-plan.md` |
-| `/workflow:review` | (inline) | `quality/reviews/{timestamp}-{type}.md` |
-| `/workflow:tdd-verify` | (inline) | `quality/tdd-compliance/{timestamp}-verify.md` |
-
-### Context Commands → `context/`
-
-| Data Type | Old Location | New Location |
-|-----------|-------------|--------------|
-| Context packages | `.process/context-package.json` | `context/project/context-package.json` |
-| Brainstorm artifacts | `.process/` | `context/brainstorm/` |
-| Conflict resolution | `.process/CONFLICT_RESOLUTION.md` | `context/conflicts/{timestamp}-resolution.md` |
-
----
-
-## Migration Strategy
-
-### Phase 1: Dual Write (Week 1-2)
-
-**Goal**: Write to both old and new locations
-
-**Implementation**:
-```bash
-# Example for /cli:analyze
-old_path=".workflow/active/$session/.chat/analyze-$timestamp.md"
-new_path=".workflow/active/$session/analysis/code/$timestamp-$topic.md"
-
-# Write to both locations
-Write($old_path, content)
-Write($new_path, content)
-
-# Add migration notice to old location
-echo "⚠️ This file has moved to: $new_path" >> $old_path
-```
-
-**Changes**:
-- Update all commands to write to new structure
-- Keep writing to old structure for compatibility
-- Add deprecation notices
-
-**Commands to Update**: 30+ commands
-
-### Phase 2: Dual Read (Week 3)
-
-**Goal**: Read from new location, fallback to old
-
-**Implementation**:
-```bash
-# Example read logic
-if [ -f "$new_path" ]; then
-  content=$(cat "$new_path")
-elif [ -f "$old_path" ]; then
-  content=$(cat "$old_path")
-  # Migrate on read
-  mkdir -p "$(dirname "$new_path")"
-  cp "$old_path" "$new_path"
-  echo "✓ Migrated: $old_path → $new_path"
-fi
-```
-
-**Changes**:
-- Update read logic in all commands
-- Automatic migration on read
-- Log migrations for verification
-
-### Phase 3: Legacy Deprecation (Week 4)
-
-**Goal**: Stop writing to old locations
-
-**Implementation**:
-```bash
-# Stop dual write, only write to new structure
-new_path=".workflow/active/$session/analysis/code/$timestamp-$topic.md"
-Write($new_path, content)
-
-# No longer write to old_path
-```
-
-**Changes**:
-- Remove old write logic
-- Keep read fallback for 1 release cycle
-- Update documentation
-
-### Phase 4: Full Migration (Future Release)
-
-**Goal**: Remove old structure entirely
-
-**Implementation**:
-```bash
-# One-time migration script
-/workflow:migrate-outputs --session all --dry-run
-/workflow:migrate-outputs --session all --execute
-```
-
-**Migration Script**:
-```bash
-#!/bin/bash
-# migrate-outputs.sh
-
-session_dir="$1"
-
-# Migrate .chat/ files
-for file in "$session_dir/.chat"/*; do
-  case "$file" in
-    *analyze*)
-      mv "$file" "$session_dir/analysis/code/"
-      ;;
-    *execute*)
-      mv "$file" "$session_dir/executions/implementations/"
-      ;;
-    *plan*)
-      mv "$file" "$session_dir/planning/architecture/"
-      ;;
-    *chat*)
-      mv "$file" "$session_dir/interactions/"
-      ;;
-  esac
-done
-
-# Migrate .process/ files
-mv "$session_dir/.process/context-package.json" "$session_dir/context/project/"
-mv "$session_dir/.process/backup" "$session_dir/history/"
-
-# Remove old directories
-rmdir "$session_dir/.chat" "$session_dir/.process" 2>/dev/null
-
-echo "✓ Migration complete: $session_dir"
-```
-
----
-
-## Implementation Checklist
-
-### Week 1-2: Dual Write Setup
-
-**Core Commands** (Priority 1):
-- [ ] `/cli:analyze` → `analysis/code/`
-- [ ] `/cli:execute` → `executions/implementations/`
-- [ ] `/cli:mode:plan` → `planning/architecture/`
-- [ ] `/workflow:execute` → `executions/implementations/`
-- [ ] `/workflow:action-plan-verify` → `quality/verifications/`
-
-**Planning Commands** (Priority 2):
-- [ ] `/cli:discuss-plan` → `planning/discussions/`
-- [ ] `/workflow:replan` → `planning/revisions/`
-- [ ] `/workflow:plan` → (updates `context/project/`)
-
-**Context Commands** (Priority 3):
-- [ ] `/workflow:tools:context-gather` → `context/project/`
-- [ ] `/workflow:brainstorm:*` → `context/brainstorm/`
-- [ ] `/workflow:tools:conflict-resolution` → `context/conflicts/`
-
-### Week 3: Dual Read + Auto-Migration
-
-**Read Logic Updates**:
-- [ ] Update all Read() calls with fallback logic
-- [ ] Add migration-on-read for all file types
-- [ ] Log all automatic migrations
-
-**Testing**:
-- [ ] Test with existing sessions
-- [ ] Test with new sessions
-- [ ] Verify backward compatibility
-
-### Week 4: Documentation + Deprecation
-
-**Documentation Updates**:
-- [ ] Update command documentation with new paths
-- [ ] Add migration guide for users
-- [ ] Document new directory structure
-- [ ] Add "Directory Purpose Reference" to docs
-
-**Deprecation Notices**:
-- [ ] Add notices to old command outputs
-- [ ] Update error messages with new paths
-- [ ] Create migration FAQ
-
----
-
-## Benefits Analysis
-
-### Immediate Benefits
-
-**1. Safety Clarity** 🟢
-- Clear separation: Read-only vs Code-modifying operations
-- Users can quickly identify dangerous operations
-- Reduces accidental code modifications
-
-**2. Better Organization** 📁
-- Semantic structure reflects operation purpose
-- Easy to find specific outputs
-- Clear audit trail
-
-**3. Improved Traceability** 🔍
-- Execution logs separated by type
-- Planning discussions organized chronologically
-- Quality checks easily accessible
-
-### Long-term Benefits
-
-**4. Scalability** 📈
-- Structure scales to 100+ sessions
-- Easy to add new operation types
-- Consistent organization patterns
-
-**5. Automation Potential** 🤖
-- Programmatic analysis of outputs
-- Automated cleanup of old files
-- Better CI/CD integration
-
-**6. User Experience** 👥
-- Intuitive directory structure
-- Self-documenting organization
-- Easier onboarding for new users
-
----
-
-## Risk Assessment
-
-### Migration Risks
-
-| Risk | Severity | Mitigation |
-|------|----------|------------|
-| **Breaking Changes** | HIGH | Phased migration with dual write/read |
-| **Data Loss** | MEDIUM | Automatic migration on read, keep backups |
-| **User Confusion** | MEDIUM | Clear documentation, migration guide |
-| **Command Failures** | LOW | Fallback to old locations during transition |
-| **Performance Impact** | LOW | Dual write adds minimal overhead |
-
-### Rollback Strategy
-
-If migration causes issues:
-
-**Phase 1 Rollback** (Dual Write):
-- Stop writing to new locations
-- Continue using old structure
-- No data loss
-
-**Phase 2 Rollback** (Dual Read):
-- Disable migration-on-read
-- Continue reading from old locations
-- New files still in new structure (OK)
-
-**Phase 3+ Rollback**:
-- Run reverse migration script
-- Copy new structure files back to old locations
-- May require manual intervention
-
----
-
-## Alternative Approaches Considered
-
-### Alternative 1: Flat Structure with Prefixes
-
-```
-.workflow/active/WFS-{session}/
-├── ANALYSIS_2024-01-15_auth-patterns.md
-├── EXEC_2024-01-15_jwt-impl.md
-└── PLAN_2024-01-14_architecture.md
-```
-
-**Rejected**: Too many files in one directory, poor organization
-
-### Alternative 2: Single "logs/" Directory
-
-```
-.workflow/active/WFS-{session}/
-└── logs/
-    ├── 2024-01-15T10-30-analyze-auth.md
-    └── 2024-01-15T11-00-execute-jwt.md
-```
-
-**Rejected**: Doesn't solve semantic confusion
-
-### Alternative 3: Minimal Change (Status Quo++)
-
-```
-.workflow/active/WFS-{session}/
-├── .chat/          # Rename to .interactions/
-├── .exec/          # NEW: Split executions out
-├── .summaries/
-└── .process/
-```
-
-**Partially Adopted**: Considered as "lite" version if full migration too complex
-
----
-
-## Recommended Timeline
-
-### Immediate (This Sprint)
-1. ✅ Document current structure
-2. ✅ Create proposed structure v2.0
-3. ✅ Get stakeholder approval
-
-### Short-term (Next 2 Sprints - 4 weeks)
-1. 📝 Implement Phase 1: Dual Write
-2. 🔍 Implement Phase 2: Dual Read
-3. 📢 Implement Phase 3: Deprecation
-
-### Long-term (Future Release)
-1. 🗑️ Implement Phase 4: Full Migration
-2. 🧹 Remove old structure code
-3. 📚 Update all documentation
-
----
-
-## Success Metrics
-
-### Quantitative
-- ✅ 100% of commands updated to new structure
-- ✅ 0 data loss during migration
-- ✅ <5% increase in execution time (dual write overhead)
-- ✅ 90% of sessions migrated within 1 month
-
-### Qualitative
-- ✅ User feedback: "Easier to find outputs"
-- ✅ User feedback: "Clearer which operations are safe"
-- ✅ Developer feedback: "Easier to maintain"
-
----
-
-## Conclusion
-
-The proposed directory reorganization addresses critical semantic confusion in the current structure by:
-
-1. **Separating read-only from code-modifying operations** (safety)
-2. **Organizing by purpose** (usability)
-3. **Using consistent naming** (maintainability)
-4. **Providing clear migration path** (feasibility)
-
-**Recommendation**: Proceed with phased migration starting with dual-write implementation.
-
-**Next Steps**:
-1. Review and approve proposed structure
-2. Identify pilot commands for Phase 1
-3. Create detailed implementation tasks
-4. Begin dual-write implementation
-
-**Questions for Discussion**:
-1. Should we use "lite" version (minimal changes) or full v2.0?
-2. What's the acceptable timeline for full migration?
-3. Are there any other directory purposes we should consider?
-4. Should we add more automation (e.g., auto-cleanup old files)?

OUTPUT_STRUCTURE_COMPARISON.md

@@ -1,404 +0,0 @@
-# Output Structure: Before vs After
-
-## Quick Visual Comparison
-
-### Current Structure (v1.0) - ⚠️ Problematic
-
-```
-.workflow/active/WFS-session/
-├── .chat/                    ⚠️ MIXED: Safe + Dangerous operations
-│   ├── analyze-*.md          ✅ Read-only
-│   ├── plan-*.md             ✅ Read-only
-│   ├── chat-*.md             ✅ Read-only
-│   └── execute-*.md          ⚠️ MODIFIES CODE!
-│
-├── .summaries/               ✅ OK
-├── .task/                    ✅ OK
-└── .process/                 ⚠️ MIXED: Multiple purposes
-    ├── context-package.json  (planning context)
-    ├── phase2-analysis.json  (temp data)
-    ├── CONFLICT_RESOLUTION.md (planning artifact)
-    └── backup/               (history)
-```
-
-**Problems**:
-- ❌ `.chat/` mixes safe (read-only) and dangerous (code-modifying) operations
-- ❌ `.process/` serves too many purposes
-- ❌ No clear organization by operation type
-- ❌ Hard to find specific outputs
-
----
-
-### Proposed Structure (v2.0) - ✅ Clear & Semantic
-
-```
-.workflow/active/WFS-session/
-│
-├── 🟢 SAFE: Read-only Operations
-│   ├── analysis/             Split from .chat/
-│   │   ├── code/            Code understanding
-│   │   ├── architecture/    Architecture analysis
-│   │   └── bugs/            Bug diagnosis
-│   │
-│   ├── planning/            Split from .chat/
-│   │   ├── discussions/     Multi-round planning
-│   │   ├── architecture/    Architecture plans
-│   │   └── revisions/       Replan history
-│   │
-│   └── interactions/        Split from .chat/
-│       └── *-chat.md        Q&A sessions
-│
-├── ⚠️ DANGEROUS: Code-modifying Operations
-│   └── executions/          Split from .chat/
-│       ├── implementations/ Code implementations
-│       ├── test-fixes/      Test fixes
-│       └── refactors/       Refactoring
-│
-├── 📊 RECORDS: Completion & Quality
-│   ├── summaries/           Keep same (task completions)
-│   │
-│   └── quality/             Split from .process/
-│       ├── verifications/   Plan verifications
-│       ├── reviews/         Code reviews
-│       └── tdd-compliance/  TDD checks
-│
-├── 📦 CONTEXT: Planning Artifacts
-│   └── context/             Split from .process/
-│       ├── project/         Context packages
-│       ├── brainstorm/      Brainstorm artifacts
-│       └── conflicts/       Conflict resolutions
-│
-├── 📜 HISTORY: Backups & Archives
-│   └── history/             Rename from .process/backup/
-│       ├── replans/         Replan backups
-│       └── snapshots/       Session snapshots
-│
-└── 📋 TASKS: Definitions
-    └── tasks/               Rename from .task/
-```
-
-**Benefits**:
-- ✅ Clear separation: Safe vs Dangerous operations
-- ✅ Semantic organization by purpose
-- ✅ Easy to find outputs by type
-- ✅ Self-documenting structure
-
----
-
-## Key Changes Summary
-
-### 1. Split `.chat/` by Safety Level
-
-| Current | New | Safety |
-|---------|-----|--------|
-| `.chat/analyze-*.md` | `analysis/code/` | 🟢 Safe |
-| `.chat/plan-*.md` | `planning/architecture/` | 🟢 Safe |
-| `.chat/chat-*.md` | `interactions/` | 🟢 Safe |
-| `.chat/execute-*.md` | `executions/implementations/` | ⚠️ Dangerous |
-
-### 2. Split `.process/` by Purpose
-
-| Current | New | Purpose |
-|---------|-----|---------|
-| `.process/context-package.json` | `context/project/` | Planning context |
-| `.process/CONFLICT_RESOLUTION.md` | `context/conflicts/` | Planning artifact |
-| `.process/ACTION_PLAN_VERIFICATION.md` | `quality/verifications/` | Quality check |
-| `.process/backup/` | `history/replans/` | Backups |
-| `.process/phase2-analysis.json` | `temp/` | Temporary data |
-
-### 3. Rename for Clarity
-
-| Current | New | Reason |
-|---------|-----|--------|
-| `.task/` | `tasks/` | Remove dot prefix (not hidden) |
-| `.summaries/` | `summaries/` | Keep same (already clear) |
-
----
-
-## Command Output Changes (Examples)
-
-### Analysis Commands
-
-```bash
-# Current (v1.0)
-/cli:analyze "review auth code"
-→ .chat/analyze-2024-01-15.md               ⚠️ Mixed with dangerous ops
-
-# Proposed (v2.0)
-/cli:analyze "review auth code"
-→ analysis/code/2024-01-15T10-30-auth.md    ✅ Clearly safe
-```
-
-### Execution Commands
-
-```bash
-# Current (v1.0)
-/cli:execute "implement auth"
-→ .chat/execute-2024-01-15.md               ⚠️ Looks safe, but dangerous!
-
-# Proposed (v2.0)
-/cli:execute "implement auth"
-→ executions/implementations/2024-01-15T11-00-auth.md    ⚠️ Clearly dangerous
-```
-
-### Planning Commands
-
-```bash
-# Current (v1.0)
-/cli:discuss-plan "design caching"
-→ .chat/discuss-plan-2024-01-15.md          ⚠️ Mixed with dangerous ops
-
-# Proposed (v2.0)
-/cli:discuss-plan "design caching"
-→ planning/discussions/2024-01-15T15-00-caching-3rounds.md    ✅ Clearly safe
-```
-
----
-
-## Migration Impact
-
-### Affected Commands: ~30
-
-**Analysis Commands** (6):
-- `/cli:analyze`
-- `/cli:mode:code-analysis`
-- `/cli:mode:bug-diagnosis`
-- `/cli:chat`
-- `/memory:code-map-memory`
-- `/workflow:review`
-
-**Planning Commands** (5):
-- `/cli:mode:plan`
-- `/cli:discuss-plan`
-- `/workflow:plan`
-- `/workflow:replan`
-- `/workflow:brainstorm:*`
-
-**Execution Commands** (8):
-- `/cli:execute`
-- `/cli:codex-execute`
-- `/workflow:execute`
-- `/workflow:lite-execute`
-- `/task:execute`
-- `/workflow:test-cycle-execute`
-- `/workflow:test-fix-gen`
-- `/workflow:test-gen`
-
-**Quality Commands** (4):
-- `/workflow:action-plan-verify`
-- `/workflow:review`
-- `/workflow:tdd-verify`
-- `/workflow:tdd-coverage-analysis`
-
-**Context Commands** (7):
-- `/workflow:tools:context-gather`
-- `/workflow:tools:conflict-resolution`
-- `/workflow:brainstorm:artifacts`
-- `/memory:skill-memory`
-- `/memory:docs`
-- `/memory:load`
-- `/memory:tech-research`
-
----
-
-## Safety Indicators
-
-### Directory Color Coding
-
-- 🟢 **Green** (Safe): Read-only operations, no code changes
-  - `analysis/`
-  - `planning/`
-  - `interactions/`
-  - `summaries/`
-  - `quality/`
-  - `context/`
-  - `history/`
-
-- ⚠️ **Yellow** (Dangerous): Code-modifying operations
-  - `executions/`
-
-### File Naming Patterns
-
-**Safe Operations** (🟢):
-```
-analysis/code/2024-01-15T10-30-auth-patterns.md
-planning/discussions/2024-01-15T15-00-caching-3rounds.md
-interactions/2024-01-15T14-00-jwt-question.md
-```
-
-**Dangerous Operations** (⚠️):
-```
-executions/implementations/2024-01-15T11-00-impl-auth.md
-executions/test-fixes/2024-01-16T09-00-fix-login-tests.md
-executions/refactors/2024-01-16T15-00-refactor-middleware.md
-```
-
----
-
-## User Experience Improvements
-
-### Before (v1.0) - Confusing ❌
-
-**User wants to review analysis logs**:
-```bash
-$ ls .workflow/active/WFS-auth/.chat/
-analyze-2024-01-15.md
-execute-2024-01-15.md    # ⚠️ Wait, which one is safe?
-plan-2024-01-14.md
-execute-2024-01-16.md    # ⚠️ More dangerous files mixed in!
-chat-2024-01-15.md
-```
-
-User thinks: "They're all in `.chat/`, so they're all logs... right?" 😰
-
-### After (v2.0) - Clear ✅
-
-**User wants to review analysis logs**:
-```bash
-$ ls .workflow/active/WFS-auth/
-analysis/      # ✅ Safe - code understanding
-planning/      # ✅ Safe - planning discussions
-interactions/  # ✅ Safe - Q&A logs
-executions/    # ⚠️ DANGER - code modifications
-```
-
-User thinks: "Oh, `executions/` is separate. I know that modifies code!" 😊
-
----
-
-## Performance Impact
-
-### Storage
-
-**Overhead**: Negligible
-- Deeper directory nesting adds ~10 bytes per file
-- For 1000 files: ~10 KB additional metadata
-
-### Access Speed
-
-**Overhead**: Negligible
-- Modern filesystems handle nested directories efficiently
-- Typical lookup: O(log n) regardless of depth
-
-### Migration Cost
-
-**Phase 1 (Dual Write)**: ~5-10% overhead
-- Writing to both old and new locations
-- Temporary during migration period
-
-**Phase 2+ (New Structure Only)**: No overhead
-- Single write location
-- Actually slightly faster (better organization)
-
----
-
-## Rollback Plan
-
-If migration causes issues:
-
-### Easy Rollback (Phase 1-2)
-
-```bash
-# Stop using new structure
-git revert <migration-commit>
-# Continue with old structure
-# No data loss (dual write preserved both)
-```
-
-### Manual Rollback (Phase 3+)
-
-```bash
-# Copy files back to old locations
-cp -r analysis/code/* .chat/
-cp -r executions/implementations/* .chat/
-cp -r context/project/* .process/
-# etc.
-```
-
----
-
-## Timeline Summary
-
-| Phase | Duration | Status | Risk |
-|-------|----------|--------|------|
-| **Phase 1**: Dual Write | 2 weeks | 📋 Planned | LOW |
-| **Phase 2**: Dual Read | 1 week | 📋 Planned | LOW |
-| **Phase 3**: Deprecation | 1 week | 📋 Planned | MEDIUM |
-| **Phase 4**: Full Migration | Future | 🤔 Optional | MEDIUM |
-
-**Total**: 4 weeks for Phases 1-3
-**Effort**: ~20-30 hours development time
-
----
-
-## Decision: Which Approach?
-
-### Option A: Full v2.0 Migration (Recommended) ✅
-
-**Pros**:
-- ✅ Clear semantic separation
-- ✅ Future-proof organization
-- ✅ Best user experience
-- ✅ Solves all identified problems
-
-**Cons**:
-- ❌ 4-week migration period
-- ❌ Affects 30+ commands
-- ❌ Requires documentation updates
-
-**Recommendation**: **YES** - Worth the investment
-
-### Option B: Minimal Changes (Quick Fix)
-
-**Change**:
-```
-.chat/ → Split into .analysis/ and .executions/
-.process/ → Keep as-is with better docs
-```
-
-**Pros**:
-- ✅ Quick implementation (1 week)
-- ✅ Solves main safety confusion
-
-**Cons**:
-- ❌ Partial solution
-- ❌ Still some confusion
-- ❌ May need full migration later anyway
-
-**Recommendation**: Only if time-constrained
-
-### Option C: Status Quo (No Change)
-
-**Pros**:
-- ✅ No development effort
-
-**Cons**:
-- ❌ Problems remain
-- ❌ User confusion continues
-- ❌ Safety risks
-
-**Recommendation**: **NO** - Not recommended
-
----
-
-## Conclusion
-
-**Recommended Action**: Proceed with **Option A (Full v2.0 Migration)**
-
-**Key Benefits**:
-1. 🟢 Clear safety separation (read-only vs code-modifying)
-2. 📁 Semantic organization by purpose
-3. 🔍 Easy to find specific outputs
-4. 📈 Scales for future growth
-5. 👥 Better user experience
-
-**Next Steps**:
-1. ✅ Review and approve this proposal
-2. 📋 Create detailed implementation tasks
-3. 🚀 Begin Phase 1: Dual Write implementation
-4. 📚 Update documentation in parallel
-
-**Questions?**
-- See detailed analysis in: `OUTPUT_DIRECTORY_REORGANIZATION.md`
-- Implementation guide: Migration Strategy section
-- Risk assessment: Risk Assessment section

WORKFLOW_DECISION_GUIDE_EN.md

@@ -0,0 +1,419 @@
+# 🌳 CCW Workflow Decision Guide
+
+This guide helps you choose the right commands and workflows for the complete software development lifecycle.
+
+---
+
+## 📊 Full Lifecycle Command Selection Flowchart
+
+```mermaid
+flowchart TD
+    Start([Start New Feature/Project]) --> Q1{Know what to build?}
+
+    Q1 -->|No| Ideation[💡 Ideation Phase<br>Requirements Exploration]
+    Q1 -->|Yes| Q2{Know how to build?}
+
+    Ideation --> BrainIdea[/ /workflow:brainstorm:auto-parallel<br>Explore product direction and positioning /]
+    BrainIdea --> Q2
+
+    Q2 -->|No| Design[🏗️ Design Exploration<br>Architecture Solution Discovery]
+    Q2 -->|Yes| Q3{Need UI design?}
+
+    Design --> BrainDesign[/ /workflow:brainstorm:auto-parallel<br>Explore technical solutions and architecture /]
+    BrainDesign --> Q3
+
+    Q3 -->|Yes| UIDesign[🎨 UI Design Phase]
+    Q3 -->|No| Q4{Task complexity?}
+
+    UIDesign --> Q3a{Have reference design?}
+    Q3a -->|Yes| UIImitate[/ /workflow:ui-design:imitate-auto<br>--input reference URL /]
+    Q3a -->|No| UIExplore[/ /workflow:ui-design:explore-auto<br>--prompt design description /]
+
+    UIImitate --> UISync[/ /workflow:ui-design:design-sync<br>Sync design system /]
+    UIExplore --> UISync
+    UISync --> Q4
+
+    Q4 -->|Simple & Quick| LitePlan[⚡ Lightweight Planning<br>/workflow:lite-plan]
+    Q4 -->|Complex & Complete| FullPlan[📋 Full Planning<br>/workflow:plan]
+
+    LitePlan --> Q5{Need code exploration?}
+    Q5 -->|Yes| LitePlanE[/ /workflow:lite-plan -e<br>task description /]
+    Q5 -->|No| LitePlanNormal[/ /workflow:lite-plan<br>task description /]
+
+    LitePlanE --> LiteConfirm[Three-Dimensional Confirmation:<br>1️⃣ Task Approval<br>2️⃣ Execution Method<br>3️⃣ Code Review]
+    LitePlanNormal --> LiteConfirm
+
+    LiteConfirm --> Q6{Choose execution method}
+    Q6 -->|Agent| LiteAgent[/ /workflow:lite-execute<br>Using @code-developer /]
+    Q6 -->|CLI Tools| LiteCLI[CLI Execution<br>Gemini/Qwen/Codex]
+    Q6 -->|Plan Only| UserImpl[Manual User Implementation]
+
+    FullPlan --> PlanVerify{Verify plan quality?}
+    PlanVerify -->|Yes| Verify[/ /workflow:action-plan-verify /]
+    PlanVerify -->|No| Execute
+    Verify --> Q7{Verification passed?}
+    Q7 -->|No| FixPlan[Fix plan issues]
+    Q7 -->|Yes| Execute
+    FixPlan --> Execute
+
+    Execute[🚀 Execution Phase<br>/workflow:execute]
+    LiteAgent --> TestDecision
+    LiteCLI --> TestDecision
+    UserImpl --> TestDecision
+    Execute --> TestDecision
+
+    TestDecision{Need testing?}
+    TestDecision -->|TDD Mode| TDD[/ /workflow:tdd-plan<br>Test-Driven Development /]
+    TestDecision -->|Post-Implementation Testing| TestGen[/ /workflow:test-gen<br>Generate tests /]
+    TestDecision -->|Existing Tests| TestCycle[/ /workflow:test-cycle-execute<br>Test-fix cycle /]
+    TestDecision -->|No| Review
+
+    TDD --> TDDExecute[/ /workflow:execute<br>Red-Green-Refactor /]
+    TDDExecute --> TDDVerify[/ /workflow:tdd-verify<br>Verify TDD compliance /]
+    TDDVerify --> Review
+
+    TestGen --> TestExecute[/ /workflow:execute<br>Execute test tasks /]
+    TestExecute --> TestResult{Tests passed?}
+    TestResult -->|No| TestCycle
+    TestResult -->|Yes| Review
+
+    TestCycle --> TestPass{Pass rate ≥95%?}
+    TestPass -->|No, continue fixing| TestCycle
+    TestPass -->|Yes| Review
+
+    Review[📝 Review Phase]
+    Review --> Q8{Need specialized review?}
+    Q8 -->|Security| SecurityReview[/ /workflow:review<br>--type security /]
+    Q8 -->|Architecture| ArchReview[/ /workflow:review<br>--type architecture /]
+    Q8 -->|Quality| QualityReview[/ /workflow:review<br>--type quality /]
+    Q8 -->|Comprehensive| GeneralReview[/ /workflow:review<br>Comprehensive review /]
+    Q8 -->|No| Complete
+
+    SecurityReview --> Complete
+    ArchReview --> Complete
+    QualityReview --> Complete
+    GeneralReview --> Complete
+
+    Complete[✅ Completion Phase<br>/workflow:session:complete]
+    Complete --> End([Project Complete])
+
+    style Start fill:#e1f5ff
+    style End fill:#c8e6c9
+    style BrainIdea fill:#fff9c4
+    style BrainDesign fill:#fff9c4
+    style UIImitate fill:#f8bbd0
+    style UIExplore fill:#f8bbd0
+    style LitePlan fill:#b3e5fc
+    style FullPlan fill:#b3e5fc
+    style Execute fill:#c5e1a5
+    style TDD fill:#ffccbc
+    style TestGen fill:#ffccbc
+    style TestCycle fill:#ffccbc
+    style Review fill:#d1c4e9
+    style Complete fill:#c8e6c9
+```
+
+---
+
+## 🎯 Decision Point Explanations
+
+### 1️⃣ **Ideation Phase - "Know what to build?"**
+
+| Situation | Command | Description |
+|-----------|---------|-------------|
+| ❌ Uncertain about product direction | `/workflow:brainstorm:auto-parallel "Explore XXX domain product opportunities"` | Multi-role analysis with Product Manager, UX Expert, etc. |
+| ✅ Clear feature requirements | Skip to design phase | Already know what functionality to build |
+
+**Examples**:
+```bash
+# Uncertain scenario: Want to build a collaboration tool, but unsure what exactly
+/workflow:brainstorm:auto-parallel "Explore team collaboration tool positioning and core features" --count 5
+
+# Certain scenario: Building a real-time document collaboration editor (requirements clear)
+# Skip ideation, move to design phase
+```
+
+---
+
+### 2️⃣ **Design Phase - "Know how to build?"**
+
+| Situation | Command | Description |
+|-----------|---------|-------------|
+| ❌ Don't know technical approach | `/workflow:brainstorm:auto-parallel "Design XXX system architecture"` | System Architect, Security Expert analyze technical solutions |
+| ✅ Clear implementation path | Skip to planning | Already know tech stack, architecture patterns |
+
+**Examples**:
+```bash
+# Don't know how: Real-time collaboration conflict resolution? Which algorithm?
+/workflow:brainstorm:auto-parallel "Design conflict resolution mechanism for real-time collaborative document editing" --count 4
+
+# Know how: Using Operational Transformation + WebSocket + Redis
+# Skip design exploration, go directly to planning
+/workflow:plan "Implement real-time collaborative editing using OT algorithm, WebSocket communication, Redis storage"
+```
+
+---
+
+### 3️⃣ **UI Design Phase - "Need UI design?"**
+
+| Situation | Command | Description |
+|-----------|---------|-------------|
+| 🎨 Have reference design | `/workflow:ui-design:imitate-auto --input "URL"` | Copy from existing design |
+| 🎨 Design from scratch | `/workflow:ui-design:explore-auto --prompt "description"` | Generate multiple design variants |
+| ⏭️ Backend/No UI | Skip | Pure backend API, CLI tools, etc. |
+
+**Examples**:
+```bash
+# Have reference: Imitate Google Docs collaboration interface
+/workflow:ui-design:imitate-auto --input "https://docs.google.com"
+
+# No reference: Design from scratch
+/workflow:ui-design:explore-auto --prompt "Modern minimalist document collaboration editing interface" --style-variants 3
+
+# Sync design to project
+/workflow:ui-design:design-sync --session WFS-xxx --selected-prototypes "v1,v2"
+```
+
+---
+
+### 4️⃣ **Planning Phase - Choose Workflow Type**
+
+| Workflow | Use Case | Characteristics |
+|----------|----------|-----------------|
+| `/workflow:lite-plan` | Quick tasks, small features | In-memory planning, three-dimensional confirmation, fast execution |
+| `/workflow:plan` | Complex projects, team collaboration | Persistent plans, quality gates, complete traceability |
+
+**Lite-Plan Three-Dimensional Confirmation**:
+1. **Task Approval**: Confirm / Modify / Cancel
+2. **Execution Method**: Agent / Provide Plan / CLI Tools (Gemini/Qwen/Codex)
+3. **Code Review**: No / Claude / Gemini / Qwen / Codex
+
+**Examples**:
+```bash
+# Simple task
+/workflow:lite-plan "Add user avatar upload feature"
+
+# Need code exploration
+/workflow:lite-plan -e "Refactor authentication module to OAuth2 standard"
+
+# Complex project
+/workflow:plan "Implement complete real-time collaborative editing system"
+/workflow:action-plan-verify  # Verify plan quality
+/workflow:execute
+```
+
+---
+
+### 5️⃣ **Testing Phase - Choose Testing Strategy**
+
+| Strategy | Command | Use Case |
+|----------|---------|----------|
+| **TDD Mode** | `/workflow:tdd-plan` | Starting from scratch, test-driven development |
+| **Post-Implementation Testing** | `/workflow:test-gen` | Code complete, add tests |
+| **Test Fixing** | `/workflow:test-cycle-execute` | Existing tests, need to fix failures |
+
+**Examples**:
+```bash
+# TDD: Write tests first, then implement
+/workflow:tdd-plan "User authentication module"
+/workflow:execute  # Red-Green-Refactor cycle
+/workflow:tdd-verify  # Verify TDD compliance
+
+# Post-implementation testing: Add tests after code complete
+/workflow:test-gen WFS-user-auth-implementation
+/workflow:execute
+
+# Test fixing: Existing tests with high failure rate
+/workflow:test-cycle-execute --max-iterations 5
+# Auto-iterate fixes until pass rate ≥95%
+```
+
+---
+
+### 6️⃣ **Review Phase - Choose Review Type**
+
+| Type | Command | Focus |
+|------|---------|-------|
+| **Security Review** | `/workflow:review --type security` | SQL injection, XSS, authentication vulnerabilities |
+| **Architecture Review** | `/workflow:review --type architecture` | Design patterns, coupling, scalability |
+| **Quality Review** | `/workflow:review --type quality` | Code style, complexity, maintainability |
+| **Comprehensive Review** | `/workflow:review` | All-around inspection |
+
+**Examples**:
+```bash
+# Security-critical system
+/workflow:review --type security
+
+# After architecture refactoring
+/workflow:review --type architecture
+
+# Daily development
+/workflow:review --type quality
+```
+
+---
+
+## 🔄 Complete Flow for Typical Scenarios
+
+### Scenario A: New Feature Development (Know How to Build)
+
+```bash
+# 1. Planning
+/workflow:plan "Add JWT authentication and permission management"
+
+# 2. Verify plan
+/workflow:action-plan-verify
+
+# 3. Execute
+/workflow:execute
+
+# 4. Testing
+/workflow:test-gen WFS-jwt-auth
+/workflow:execute
+
+# 5. Review
+/workflow:review --type security
+
+# 6. Complete
+/workflow:session:complete
+```
+
+---
+
+### Scenario B: New Feature Development (Don't Know How to Build)
+
+```bash
+# 1. Design exploration
+/workflow:brainstorm:auto-parallel "Design distributed cache system architecture" --count 5
+
+# 2. UI design (if needed)
+/workflow:ui-design:explore-auto --prompt "Cache management dashboard interface"
+/workflow:ui-design:design-sync --session WFS-xxx
+
+# 3. Planning
+/workflow:plan
+
+# 4. Verification
+/workflow:action-plan-verify
+
+# 5. Execution
+/workflow:execute
+
+# 6. TDD testing
+/workflow:tdd-plan "Cache system core modules"
+/workflow:execute
+
+# 7. Review
+/workflow:review --type architecture
+/workflow:review --type security
+
+# 8. Complete
+/workflow:session:complete
+```
+
+---
+
+### Scenario C: Quick Feature Development (Lite Workflow)
+
+```bash
+# 1. Lightweight planning (may need code exploration)
+/workflow:lite-plan -e "Optimize database query performance"
+
+# 2. Three-dimensional confirmation
+# - Confirm task
+# - Choose Agent execution
+# - Choose Gemini code review
+
+# 3. Auto-execution (called internally by /workflow:lite-execute)
+
+# 4. Complete
+```
+
+---
+
+### Scenario D: Bug Fixing
+
+```bash
+# 1. Diagnosis
+/cli:mode:bug-diagnosis --tool gemini "User login fails with token expired error"
+
+# 2. Quick fix
+/workflow:lite-plan "Fix JWT token expiration validation logic"
+
+# 3. Test fix
+/workflow:test-cycle-execute
+
+# 4. Complete
+```
+
+---
+
+## 🎓 Quick Command Reference
+
+### Choose by Knowledge Level
+
+| Your Situation | Recommended Command |
+|----------------|---------------------|
+| 💭 Don't know what to build | `/workflow:brainstorm:auto-parallel "Explore product direction"` |
+| ❓ Know what, don't know how | `/workflow:brainstorm:auto-parallel "Design technical solution"` |
+| ✅ Know what and how | `/workflow:plan "Specific implementation description"` |
+| ⚡ Simple, clear small task | `/workflow:lite-plan "Task description"` |
+| 🐛 Bug fixing | `/cli:mode:bug-diagnosis` + `/workflow:lite-plan` |
+
+### Choose by Project Phase
+
+| Phase | Command |
+|-------|---------|
+| 📋 **Requirements Analysis** | `/workflow:brainstorm:auto-parallel` |
+| 🏗️ **Architecture Design** | `/workflow:brainstorm:auto-parallel` |
+| 🎨 **UI Design** | `/workflow:ui-design:explore-auto` / `imitate-auto` |
+| 📝 **Implementation Planning** | `/workflow:plan` / `/workflow:lite-plan` |
+| 🚀 **Coding Implementation** | `/workflow:execute` / `/workflow:lite-execute` |
+| 🧪 **Testing** | `/workflow:tdd-plan` / `/workflow:test-gen` |
+| 🔧 **Test Fixing** | `/workflow:test-cycle-execute` |
+| 📖 **Code Review** | `/workflow:review` |
+| ✅ **Project Completion** | `/workflow:session:complete` |
+
+### Choose by Work Mode
+
+| Mode | Workflow | Use Case |
+|------|----------|----------|
+| **🚀 Agile & Fast** | Lite Workflow | Personal dev, rapid iteration, prototype validation |
+| **📋 Standard & Complete** | Full Workflow | Team collaboration, enterprise projects, long-term maintenance |
+| **🧪 Quality-First** | TDD Workflow | Core modules, critical features, high reliability requirements |
+| **🎨 Design-Driven** | UI-Design Workflow | Frontend projects, user interfaces, design systems |
+
+---
+
+## 💡 Expert Advice
+
+### ✅ Best Practices
+
+1. **Use brainstorming when uncertain**: Better to spend 10 minutes exploring solutions than blindly implementing and rewriting
+2. **Use Full workflow for complex projects**: Persistent plans facilitate team collaboration and long-term maintenance
+3. **Use Lite workflow for small tasks**: Complete quickly, reduce overhead
+4. **Use TDD for critical modules**: Test-driven development ensures quality
+5. **Regularly update memory**: `/memory:update-related` keeps context accurate
+
+### ❌ Common Pitfalls
+
+1. **Blindly skipping brainstorming**: Not exploring unfamiliar technical domains leads to rework
+2. **Overusing brainstorming**: Brainstorming even simple features wastes time
+3. **Ignoring plan verification**: Not running `/workflow:action-plan-verify` causes execution issues
+4. **Ignoring testing**: Not generating tests, code quality cannot be guaranteed
+5. **Not completing sessions**: Not running `/workflow:session:complete` causes session state confusion
+
+---
+
+## 🔗 Related Documentation
+
+- [Getting Started Guide](GETTING_STARTED.md) - Quick start tutorial
+- [Command Reference](COMMAND_REFERENCE.md) - Complete command list
+- [Architecture Overview](ARCHITECTURE.md) - System architecture explanation
+- [Examples](EXAMPLES.md) - Real-world scenario examples
+- [FAQ](FAQ.md) - Frequently asked questions
+
+---
+
+**Last Updated**: 2025-11-20
+**Version**: 5.8.1