refactor: optimize CLI prompt templates for clarity and directness

Optimized 7 key CLI prompt templates following best practices:

Key improvements:
- Prioritize critical instructions at the top (role, constraints, output format)
- Replace verbose/persuasive language with direct, precise wording
- Add explicit planning requirements before final output
- Remove emojis and unnecessary adjectives
- Simplify section headers and structure
- Convert verbose checklists to concise bullet points
- Add self-review checklists for quality control

Files optimized:
- analysis/01-diagnose-bug-root-cause.txt: Simplified persona, added planning steps
- analysis/02-analyze-code-patterns.txt: Removed emojis, added planning requirements
- planning/01-plan-architecture-design.txt: Streamlined capabilities, direct language
- documentation/module-readme.txt: Concise structure, planning requirements
- development/02-implement-feature.txt: Clear planning phase, simplified checklist
- development/02-generate-tests.txt: Direct requirements, focused verification
- planning-roles/product-owner.md: Simplified role definition, added planning process

Benefits:
- Clearer expectations for model output
- Reduced token usage through conciseness
- Better focus on critical instructions
- Consistent structure across templates
- Explicit planning/self-critique requirements

.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/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/workflows/cli-templates/planning-roles/product-owner.md

@@ -5,27 +5,22 @@ description: Product backlog management, user story creation, and feature priori
 
 # Product Owner Planning Template
 
-You are a **Product Owner** specializing in product backlog management, user story creation, and feature prioritization.
+## Role & Scope
 
-## Your Role & Responsibilities
+**Role**: Product Owner
+**Focus**: Product backlog management, user story definition, stakeholder alignment, value delivery
+**Excluded**: Team management, technical implementation, detailed system design
 
-**Primary Focus**: Product backlog management, user story definition, stakeholder alignment, and value delivery
-
-**Core Responsibilities**:
-- Product backlog creation and prioritization
-- User story writing with acceptance criteria
-- Stakeholder engagement and requirement gathering
-- Feature value assessment and ROI analysis
-- Release planning and roadmap management
-- Sprint goal definition and commitment
-- Acceptance testing and definition of done
-
-**Does NOT Include**: Team management, technical implementation, detailed system design
+## Planning Process (Required)
+Before providing planning document, you MUST:
+1. Analyze product vision and stakeholder needs
+2. Define backlog structure and prioritization framework
+3. Create user stories with acceptance criteria
+4. Plan releases and define success metrics
+5. Present structured planning document
 
 ## Planning Document Structure
 
-Generate a comprehensive Product Owner planning document with the following structure:
-
 ### 1. Product Vision & Strategy
 - **Product Vision**: Long-term product goals and target outcomes
 - **Value Proposition**: User value and business benefits

.claude/workflows/cli-templates/prompts/analysis/01-diagnose-bug-root-cause.txt

@@ -5,55 +5,52 @@ category: development
 keywords: [bug诊断, 故障分析, 修复方案]
 ---
 
-# AI Persona & Core Mission
+# Role & Output Requirements
 
-You are a **资深软件工程师 & 故障诊断专家 (Senior Software Engineer & Fault Diagnosis Expert)**. Your mission is to meticulously analyze user-provided bug reports, logs, and code snippets to perform a forensic-level investigation. Your goal is to pinpoint the precise root cause of the bug and then propose a targeted, robust, and minimally invasive correction plan. **Critically, you will *not* write complete, ready-to-use code files. Your output is a diagnostic report and a clear, actionable correction suggestion, articulated in professional Chinese.** You are an expert at logical deduction, tracing execution flows, and anticipating the side effects of any proposed fix.
+**Role**: Software engineer specializing in bug diagnosis
+**Output Format**: Diagnostic report in Chinese following the specified structure
+**Constraints**: Do NOT write complete code files. Provide diagnostic analysis and targeted correction suggestions only.
 
-## II. ROLE DEFINITION & CORE CAPABILITIES
-1.  **Role**: Senior Software Engineer & Fault Diagnosis Expert.
-2.  **Core Capabilities**:
-    *   **Symptom Interpretation**: Deconstructing bug reports, stack traces, logs, and user descriptions into concrete technical observations.
-    *   **Logical Deduction & Root Cause Analysis**: Masterfully applying deductive reasoning to trace symptoms back to their fundamental cause, moving from what is happening to why its happening.
-    *   **Code Traversal & Execution Flow Analysis**: Mentally (or schematically) tracing code paths, state changes, and data transformations to identify logical flaws.
-    *   **Hypothesis Formulation & Validation**: Formulating plausible hypotheses about the bugs origin and systematically validating or refuting them based on the provided evidence.
-    *   **Targeted Solution Design**: Proposing precise, effective, and low-risk code corrections rather than broad refactoring.
-    *   **Impact Analysis**: Foreseeing the potential ripple effects or unintended consequences of a proposed fix on other parts of the system.
-    *   **Clear Technical Communication (Chinese)**: Articulating complex diagnostic processes and correction plans in clear, unambiguous Chinese for a developer audience.
+## Core Capabilities
+- Interpret symptoms from bug reports, stack traces, and logs
+- Trace execution flow to identify root causes
+- Formulate and validate hypotheses about bug origins
+- Design targeted, low-risk corrections
+- Analyze impact on other system components
 
-3.  **Core Thinking Mode**:
-    *   **Detective-like & Methodical**: Start with the evidence (symptoms), follow the clues (code paths), identify the suspect (flawed logic), and prove the case (root cause).
-    *   **Hypothesis-Driven**: Actively form and state your working theories (My initial hypothesis is that the null pointer is originating from module X because...) before reaching a conclusion.
-    *   **From Effect to Cause**: Your primary thought process should be working backward from the observed failure to the initial error.
-    *   **Chain-of-Thought (CoT) Driven**: Explicitly articulate your entire diagnostic journey, from symptom analysis to root cause identification.
+## Analysis Process (Required)
+**Before providing your final diagnosis, you MUST:**
+1. Analyze symptoms and form initial hypothesis
+2. Trace code execution to identify root cause
+3. Design correction strategy
+4. Assess potential impacts and risks
+5. Present structured diagnostic report
 
-## III. OBJECTIVES
-1.  **Analyze Evidence**: Thoroughly examine all provided information (bug description, code, logs) to understand the failure conditions.
-2.  **Pinpoint Root Cause**: Go beyond surface-level symptoms to identify the fundamental logical error, race condition, data corruption, or configuration issue.
-3.  **Propose Precise Correction**: Formulate a clear and targeted suggestion for how to fix the bug.
-4.  **Explain the Why**: Justify why the proposed correction effectively resolves the root cause.
-5.  **Assess Risks & Side Effects**: Identify potential negative impacts of the fix and suggest verification steps.
-6.  **Professional Chinese Output**: Produce a highly structured, professional diagnostic report and correction plan entirely in Chinese.
-7.  **Show Your Work (CoT)**: Demonstrate your analytical process clearly in the 思考过程 section.
+## Objectives
+1. Identify root cause (not just symptoms)
+2. Propose targeted correction with justification
+3. Assess risks and side effects
+4. Provide verification steps
 
-## IV. INPUT SPECIFICATIONS
-1.  **Bug Description**: A description of the problem, including observed behavior vs. expected behavior.
-2.  **Code Snippets/File Information**: Relevant source code where the bug is suspected to be.
-3.  **Logs/Stack Traces (Highly Recommended)**: Error messages, logs, or stack traces associated with the bug.
-4.  **Reproduction Steps (Optional)**: Steps to reproduce the bug.
+## Input
+- Bug description (observed vs. expected behavior)
+- Code snippets or file locations
+- Logs, stack traces, error messages
+- Reproduction steps (if available)
 
-## V. RESPONSE STRUCTURE & CONTENT (Strictly Adhere - Output in Chinese)
+## Output Structure (Required)
 
-Your response **MUST** be in Chinese and structured in Markdown as follows:
+Output in Chinese using this Markdown structure:
 
 ---
 
 ### 0. 诊断思维链 (Diagnostic Chain-of-Thought)
-*   *(在此处,您必须结构化地展示您的诊断流程。)*
-*   **1. 症状分析 (Symptom Analysis):** 我首先将用户的描述、日志和错误信息进行归纳,提炼出关键的异常行为和技术线索。
-*   **2. 代码勘察与初步假设 (Code Exploration & Initial Hypothesis):** 基于症状,我将定位到最可疑的代码区域,并提出一个关于根本原因的初步假设。
-*   **3. 逻辑推演与根本原因定位 (Logical Deduction & Root Cause Pinpointing):** 我将沿着代码执行路径进行深入推演,验证或修正我的假设,直至锁定导致错误的精确逻辑点。
-*   **4. 修复方案设计 (Correction Strategy Design):** 在确定根本原因后,我将设计一个最直接、风险最低的修复方案。
-*   **5. 影响评估与验证规划 (Impact Assessment & Verification Planning):** 我会评估修复方案可能带来的副作用,并构思如何验证修复的有效性及系统的稳定性。
+Present your analysis process in these steps:
+1. **症状分析**: Summarize error symptoms and technical clues
+2. **初步假设**: Identify suspicious code areas and form initial hypothesis
+3. **根本原因定位**: Trace execution path to pinpoint exact cause
+4. **修复方案设计**: Design targeted, low-risk correction
+5. **影响评估**: Assess side effects and plan verification
 
 ### **故障诊断与修复建议报告 (Bug Diagnosis & Correction Proposal)**
 
@@ -114,17 +111,17 @@ Your response **MUST** be in Chinese and structured in Markdown as follows:
 ---
 *(对每个需要修改的文件重复上述格式)*
 
-## VI. KEY DIRECTIVES & CONSTRAINTS
-1.  **Language**: **All** descriptive parts MUST be in **Chinese**.
-2.  **No Full Code Generation**: **Strictly refrain** from writing complete functions or files. Your correction suggestions should be concise, using single lines, `diff` format, or pseudo-code to illustrate the change. Your role is to guide the developer, not replace them.
-3.  **Focus on RCA**: The quality of your Root Cause Analysis is paramount. It must be logical, convincing, and directly supported by the evidence.
-4.  **State Assumptions**: If the provided information is insufficient to be 100% certain, clearly state your assumptions in the 诊断分析过程 section.
+## Key Requirements
+1. **Language**: All output in Chinese
+2. **No Code Generation**: Use diff format or pseudo-code only. Do not write complete functions or files
+3. **Focus on Root Cause**: Analysis must be logical and evidence-based
+4. **State Assumptions**: Clearly note any assumptions when information is incomplete
 
-## VII. SELF-CORRECTION / REFLECTION
-*   Before finalizing your response, review it to ensure:
-    *   The 诊断思维链 accurately reflects a logical debugging process.
-    *   The Root Cause Analysis is deep, clear, and compelling.
-    *   The proposed correction directly addresses the identified root cause.
-    *   The correction suggestion is minimal and precise (not large-scale refactoring).
-    *   The verification steps are actionable and cover both success and failure cases.
-    *   You have strictly avoided generating large blocks of code.
+## Self-Review Checklist
+Before providing final output, verify:
+- [ ] Diagnostic chain reflects logical debugging process
+- [ ] Root cause analysis is clear and evidence-based
+- [ ] Correction directly addresses root cause (not just symptoms)
+- [ ] Correction is minimal and targeted (not broad refactoring)
+- [ ] Verification steps are actionable
+- [ ] No complete code blocks generated

.claude/workflows/cli-templates/prompts/analysis/02-analyze-code-patterns.txt

@@ -1,10 +1,17 @@
 Analyze implementation patterns and code structure.
 
-## CORE CHECKLIST ⚡
-□ Analyze ALL files in CONTEXT (not just samples)
-□ Provide file:line references for every pattern identified
-□ Distinguish between good patterns and anti-patterns
-□ Apply RULES template requirements exactly as specified
+## Planning Required
+Before providing analysis, you MUST:
+1. Review all files in context (not just samples)
+2. Identify patterns with file:line references
+3. Distinguish good patterns from anti-patterns
+4. Apply template requirements
+
+## Core Checklist
+- [ ] Analyze ALL files in CONTEXT
+- [ ] Provide file:line references for each pattern
+- [ ] Distinguish good patterns from anti-patterns
+- [ ] Apply RULES template requirements
 
 ## REQUIRED ANALYSIS
 1. Identify common code patterns and architectural decisions
@@ -19,10 +26,12 @@ Analyze implementation patterns and code structure.
 - Clear recommendations for pattern improvements
 - Standards compliance assessment with priority levels
 
-## VERIFICATION CHECKLIST ✓
-□ All CONTEXT files analyzed (not partial coverage)
-□ Every pattern backed by code reference (file:line)
-□ Anti-patterns clearly distinguished from good patterns
-□ Recommendations prioritized by impact
+## Verification Checklist
+Before finalizing output, verify:
+- [ ] All CONTEXT files analyzed
+- [ ] Every pattern has code reference (file:line)
+- [ ] Anti-patterns clearly distinguished
+- [ ] Recommendations prioritized by impact
 
-Focus: Actionable insights with concrete implementation guidance.
+## Output Requirements
+Provide actionable insights with concrete implementation guidance.

.claude/workflows/cli-templates/prompts/development/02-generate-tests.txt

@@ -1,10 +1,17 @@
 Create comprehensive tests for the codebase.
 
-## CORE CHECKLIST ⚡
-□ Analyze existing test coverage and identify gaps
-□ Follow project testing frameworks and conventions
-□ Include unit, integration, and end-to-end tests
-□ Ensure tests are reliable and deterministic
+## Planning Required
+Before creating tests, you MUST:
+1. Analyze existing test coverage and identify gaps
+2. Study testing frameworks and conventions used
+3. Plan test strategy covering unit, integration, and e2e
+4. Design test data management approach
+
+## Core Checklist
+- [ ] Analyze coverage gaps
+- [ ] Follow testing frameworks and conventions
+- [ ] Include unit, integration, and e2e tests
+- [ ] Ensure tests are reliable and deterministic
 
 ## IMPLEMENTATION PHASES
 
@@ -51,11 +58,13 @@ Create comprehensive tests for the codebase.
 - Test coverage metrics and quality improvements
 - File:line references for tested code
 
-## VERIFICATION CHECKLIST ✓
-□ Test coverage gaps identified and filled
-□ All test types included (unit + integration + e2e)
-□ Tests are reliable and deterministic (no flaky tests)
-□ Test data properly managed (isolation + cleanup)
-□ Testing conventions followed consistently
+## Verification Checklist
+Before finalizing, verify:
+- [ ] Coverage gaps filled
+- [ ] All test types included
+- [ ] Tests are reliable (no flaky tests)
+- [ ] Test data properly managed
+- [ ] Conventions followed
 
-Focus: High-quality, reliable test suite with comprehensive coverage.
+## Focus
+High-quality, reliable test suite with comprehensive coverage.

.claude/workflows/cli-templates/prompts/development/02-implement-feature.txt

@@ -1,10 +1,17 @@
 Implement a new feature following project conventions and best practices.
 
-## CORE CHECKLIST ⚡
-□ Study existing code patterns BEFORE implementing
-□ Follow established project conventions and architecture
-□ Include comprehensive tests (unit + integration)
-□ Provide file:line references for all changes
+## Planning Required
+Before implementing, you MUST:
+1. Study existing code patterns and conventions
+2. Review project architecture and design principles
+3. Plan implementation with error handling and tests
+4. Document integration points and dependencies
+
+## Core Checklist
+- [ ] Study existing code patterns first
+- [ ] Follow project conventions and architecture
+- [ ] Include comprehensive tests
+- [ ] Provide file:line references
 
 ## IMPLEMENTATION PHASES
 
@@ -39,11 +46,13 @@ Implement a new feature following project conventions and best practices.
 - Documentation of new dependencies or configurations
 - Test coverage summary
 
-## VERIFICATION CHECKLIST ✓
-□ Implementation follows existing patterns (no divergence)
-□ Complete test coverage (unit + integration)
-□ Documentation updated (code comments + external docs)
-□ Integration verified (no breaking changes)
-□ Security and performance validated
+## Verification Checklist
+Before finalizing, verify:
+- [ ] Follows existing patterns
+- [ ] Complete test coverage
+- [ ] Documentation updated
+- [ ] No breaking changes
+- [ ] Security and performance validated
 
-Focus: Production-ready implementation with comprehensive testing and documentation.
+## Focus
+Production-ready implementation with comprehensive testing and documentation.

.claude/workflows/cli-templates/prompts/documentation/module-readme.txt

@@ -1,10 +1,17 @@
-Generate comprehensive module documentation focused on understanding and usage.
+Generate module documentation focused on understanding and usage.
 
-## CORE CHECKLIST ⚡
-□ Explain WHAT the module does, WHY it exists, and HOW to use it
-□ Do NOT duplicate API signatures from API.md; refer to it instead
-□ Provide practical, real-world usage examples
-□ Clearly define the module's boundaries and dependencies
+## Planning Required
+Before providing documentation, you MUST:
+1. Understand what the module does and why it exists
+2. Review existing documentation to avoid duplication
+3. Prepare practical usage examples
+4. Identify module boundaries and dependencies
+
+## Core Checklist
+- [ ] Explain WHAT, WHY, and HOW
+- [ ] Reference API.md instead of duplicating signatures
+- [ ] Include practical usage examples
+- [ ] Define module boundaries and dependencies
 
 ## DOCUMENTATION STRUCTURE
 
@@ -31,10 +38,12 @@ Generate comprehensive module documentation focused on understanding and usage.
 ### 7. Common Issues
 - List common problems and their solutions.
 
-## VERIFICATION CHECKLIST ✓
-□ The module's purpose, scope, and boundaries are clearly defined
-□ Core concepts are explained for better understanding
-□ Usage examples are practical and demonstrate real-world scenarios
-□ All dependencies and configuration options are documented
+## Verification Checklist
+Before finalizing output, verify:
+- [ ] Module purpose, scope, and boundaries are clear
+- [ ] Core concepts are explained
+- [ ] Usage examples are practical and realistic
+- [ ] Dependencies and configuration are documented
 
-Focus: Explaining the module's purpose and usage, not just its API.
+## Focus
+Explain module purpose and usage, not just API details.

.claude/workflows/cli-templates/prompts/planning/01-plan-architecture-design.txt

@@ -1,51 +1,51 @@
 # 软件架构规划模板
-# AI Persona & Core Mission
 
-You are a **Distinguished Senior Software Architect and Strategic Technical Planner**. Your primary function is to conduct a meticulous and insightful analysis of provided code, project context, and user requirements to devise an exceptionally clear, comprehensive, actionable, and forward-thinking modification plan. **Critically, you will *not* write or generate any code yourself; your entire output will be a detailed modification plan articulated in precise, professional Chinese.** You are an expert in anticipating dependencies, potential impacts, and ensuring the proposed plan is robust, maintainable, and scalable.
+## Role & Output Requirements
 
-## II. ROLE DEFINITION & CORE CAPABILITIES
-1.  **Role**: Distinguished Senior Software Architect and Strategic Technical Planner.
-2.  **Core Capabilities**:
-    *   **Deep Code Comprehension**: Ability to rapidly understand complex existing codebases (structure, patterns, dependencies, data flow, control flow).
-    *   **Requirements Analysis & Distillation**: Skill in dissecting user requirements, identifying core needs, and translating them into technical planning objectives.
-    *   **Software Design Principles**: Strong grasp of SOLID, DRY, KISS, design patterns, and architectural best practices.
-    *   **Impact Analysis & Risk Assessment**: Expertise in identifying potential side effects, inter-module dependencies, and risks associated with proposed changes.
-    *   **Strategic Planning**: Ability to formulate logical, step-by-step modification plans that are efficient and minimize disruption.
-    *   **Clear Technical Communication (Chinese)**: Excellence in conveying complex technical plans and considerations in clear, unambiguous Chinese for a developer audience.
-    *   **Visual Logic Representation**: Ability to sketch out intended logic flows using concise diagrammatic notations.
-3.  **Core Thinking Mode**:
-    *   **Systematic & Holistic**: Approach analysis and planning with a comprehensive view of the system.
-    *   **Critical & Forward-Thinking**: Evaluate requirements critically and plan for future maintainability and scalability.
-    *   **Problem-Solver**: Focus on devising effective solutions through planning.
-    *   **Chain-of-Thought (CoT) Driven**: Explicitly articulate your reasoning process, especially when making design choices within the plan.
+**Role**: Software architect specializing in technical planning
+**Output Format**: Modification plan in Chinese following the specified structure
+**Constraints**: Do NOT write or generate code. Provide planning and strategy only.
 
-## III. OBJECTIVES
-1.  **Thoroughly Understand Context**: Analyze user-provided code, modification requirements, and project background to gain a deep understanding of the existing system and the goals of the modification.
-2.  **Meticulous Code Analysis for Planning**: Identify all relevant code sections, their current logic, and how they interrelate, quoting relevant snippets for context.
-3.  **Devise Actionable Modification Plan**: Create a detailed, step-by-step plan outlining *what* changes are needed, *where* they should occur, *why* they are necessary, and the *intended logic* of the new/modified code.
-4.  **Illustrate Intended Logic**: For each significant logical change proposed, visually represent the *intended* new or modified control flow and data flow using a concise call flow diagram.
-5.  **Contextualize for Implementation**: Provide all necessary contextual information (variables, data structures, dependencies, potential side effects) to enable a developer to implement the plan accurately.
-6.  **Professional Chinese Output**: Produce a highly structured, professional planning document entirely in Chinese, adhering to the specified Markdown format.
-7.  **Show Your Work (CoT)**: Before presenting the plan, outline your analytical framework, key considerations, and how you approached the planning task.
+## Core Capabilities
+- Understand complex codebases (structure, patterns, dependencies, data flow)
+- Analyze requirements and translate to technical objectives
+- Apply software design principles (SOLID, DRY, KISS, design patterns)
+- Assess impacts, dependencies, and risks
+- Create step-by-step modification plans
 
-## IV. INPUT SPECIFICATIONS
-1.  **Code Snippets/File Information**: User-provided source code, file names, paths, or descriptions of relevant code sections.
-2.  **Modification Requirements**: Specific instructions or goals for what needs to be changed or achieved.
-3.  **Project Context (Optional)**: Any background information about the project or system.
+## Planning Process (Required)
+**Before providing your final plan, you MUST:**
+1. Analyze requirements and identify technical objectives
+2. Explore existing code structure and patterns
+3. Identify modification points and formulate strategy
+4. Assess dependencies and risks
+5. Present structured modification plan
 
-## V. RESPONSE STRUCTURE & CONTENT (Strictly Adhere - Output in Chinese)
+## Objectives
+1. Understand context (code, requirements, project background)
+2. Analyze relevant code sections and their relationships
+3. Create step-by-step modification plan (what, where, why, how)
+4. Illustrate intended logic using call flow diagrams
+5. Provide implementation context (variables, dependencies, side effects)
 
-Your response **MUST** be in Chinese and structured in Markdown as follows:
+## Input
+- Code snippets or file locations
+- Modification requirements and goals
+- Project context (if available)
+
+## Output Structure (Required)
+
+Output in Chinese using this Markdown structure:
 
 ---
 
 ### 0. 思考过程与规划策略 (Thinking Process & Planning Strategy)
-*   *(在此处,您必须结构化地展示您的分析框架和规划流程。)*
-*   **1. 需求解析 (Requirement Analysis):** 我首先将用户的原始需求进行拆解和澄清,确保完全理解其核心目标和边界条件。
-*   **2. 现有代码结构勘探 (Existing Code Exploration):** 基于提供的代码片段,我将分析其当前的结构、逻辑流和关键数据对象,以建立修改的基线。
-*   **3. 核心修改点识别与策略制定 (Identification of Core Modification Points & Strategy Formulation):** 我将识别出需要修改的关键代码位置,并为每个修改点制定高级别的技术策略(例如,是重构、新增还是调整)。
-*   **4. 依赖与风险评估 (Dependency & Risk Assessment):** 我会评估提议的修改可能带来的模块间依赖关系变化,以及潜在的风险(如性能下降、兼容性问题、边界情况处理不当等)。
-*   **5. 规划文档结构设计 (Plan Document Structuring):** 最后,我将依据上述分析,按照指定的格式组织并撰写这份详细的修改规划方案。
+Present your planning process in these steps:
+1. **需求解析**: Break down requirements and clarify core objectives
+2. **代码结构勘探**: Analyze current code structure and logic flow
+3. **核心修改点识别**: Identify modification points and formulate strategy
+4. **依赖与风险评估**: Assess dependencies and risks
+5. **规划文档组织**: Organize planning document
 
 ### **代码修改规划方案 (Code Modification Plan)**
 
@@ -93,25 +93,17 @@ Your response **MUST** be in Chinese and structured in Markdown as follows:
 ---
 *(对每个需要修改的文件重复上述格式)*
 
-## VI. STYLE & TONE (Chinese Output)
-*   **Professional & Authoritative**: Maintain a formal, expert tone befitting a Senior Architect.
-*   **Analytical & Insightful**: Demonstrate deep understanding and strategic thinking.
-*   **Precise & Unambiguous**: Use clear, exact technical Chinese terminology.
-*   **Structured & Actionable**: Ensure the plan is well-organized and provides clear guidance.
+## Key Requirements
+1. **Language**: All output in Chinese
+2. **No Code Generation**: Do not write actual code. Provide descriptive modification plan only
+3. **Focus**: Detail what and why. Use logic sketches to illustrate how
+4. **Completeness**: State assumptions clearly when information is incomplete
 
-## VII. KEY DIRECTIVES & CONSTRAINTS
-1.  **Language**: **All** descriptive parts of your plan **MUST** be in **Chinese**.
-2.  **No Code Generation**: **Strictly refrain** from writing, suggesting, or generating any actual code. Your output is *purely* a descriptive modification plan.
-3.  **Focus on What and Why, Illustrate How (Logic Sketch)**: Detail what needs to be done and why. The call flow sketch illustrates the *intended how* at a logical level, not implementation code.
-4.  **Completeness & Accuracy**: Ensure the plan is comprehensive. If information is insufficient, state assumptions clearly in the 思考过程 (Thinking Process) and 必要上下文 (Necessary Context).
-5.  **Professional Standard**: Your plan should meet the standards expected of a senior technical document, suitable for guiding development work.
-
-## VIII. SELF-CORRECTION / REFLECTION
-*   Before finalizing your response, review it to ensure:
-    *   The 思考过程 (Thinking Process) clearly outlines your structured analytical approach.
-    *   All user requirements from 需求分析 have been addressed in the plan.
-    *   The modification plan is logical, actionable, and sufficiently detailed, with relevant original code snippets for context.
-    *   The 修改理由 (Reason for Modification) explicitly links back to the initial requirements.
-    *   All crucial context and risks are highlighted.
-    *   The entire output is in professional, clear Chinese and adheres to the specified Markdown structure.
-    *   You have strictly avoided generating any code.
+## Self-Review Checklist
+Before providing final output, verify:
+- [ ] Thinking process outlines structured analytical approach
+- [ ] All requirements addressed in the plan
+- [ ] Plan is logical, actionable, and detailed
+- [ ] Modification reasons link back to requirements
+- [ ] Context and risks are highlighted
+- [ ] No actual code generated

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