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/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

WORKFLOW_DECISION_GUIDE.md

@@ -253,300 +253,6 @@ flowchart TD
 
 ---
 
-### 7️⃣ **CLI 工具协作模式 - 多模型智能协同**
-
-本项目集成了三种 CLI 工具，支持灵活的串联、并行和混合执行方式：
-
-| 工具 | 核心能力 | 上下文长度 | 适用场景 |
-|------|---------|-----------|---------|
-| **Gemini** | 深度分析、架构设计、规划 | 超长上下文 | 代码理解、执行流追踪、技术方案评估 |
-| **Qwen** | 代码审查、模式识别 | 超长上下文 | Gemini 备选、多维度分析 |
-| **Codex** | 精确代码撰写、Bug定位 | 标准上下文 | 功能实现、测试生成、代码重构 |
-
-#### 📋 三种执行模式
-
-**1. 串联执行（Serial Execution）** - 顺序依赖
-
-适用场景：后续任务依赖前一任务的结果
-
-```bash
-# 示例：分析后实现
-# Step 1: Gemini 分析架构
-使用 gemini 分析认证模块的架构设计，识别关键组件和数据流
-
-# Step 2: Codex 基于分析结果实现
-让 codex 根据上述架构分析，实现 JWT 认证中间件
-```
-
-**执行流程**：
-```
-Gemini 分析 → 输出架构报告 → Codex 读取报告 → 实现代码
-```
-
----
-
-**2. 并行执行（Parallel Execution）** - 同时进行
-
-适用场景：多个独立任务，无依赖关系
-
-```bash
-# 示例：多维度分析
-用 gemini 分析认证模块的安全性，关注 JWT、密码存储、会话管理
-用 qwen 分析认证模块的性能瓶颈，识别慢查询和优化点
-让 codex 为认证模块生成单元测试，覆盖所有核心功能
-```
-
-**执行流程**：
-```
-        ┌─ Gemini: 安全分析 ─┐
-并行 ───┼─ Qwen: 性能分析 ──┼─→ 汇总结果
-        └─ Codex: 测试生成 ─┘
-```
-
----
-
-**3. 混合执行（Hybrid Execution）** - 串并结合
-
-适用场景：复杂任务，部分并行、部分串联
-
-```bash
-# 示例：完整功能开发
-# Phase 1: 并行分析（独立任务）
-使用 gemini 分析现有认证系统的架构模式
-用 qwen 评估 OAuth2 集成的技术方案
-
-# Phase 2: 串联实现（依赖 Phase 1）
-让 codex 基于上述分析，实现 OAuth2 认证流程
-
-# Phase 3: 并行优化（独立任务）
-用 gemini 审查代码质量和安全性
-让 codex 生成集成测试
-```
-
-**执行流程**：
-```
-Phase 1: Gemini 分析 ──┐
-         Qwen 评估 ────┼─→ Phase 2: Codex 实现 ──→ Phase 3: Gemini 审查 ──┐
-                       │                                    Codex 测试 ──┼─→ 完成
-                       └────────────────────────────────────────────────┘
-```
-
----
-
-#### 🎯 语义调用 vs 命令调用
-
-**方式一：自然语言语义调用**（推荐）
-
-```bash
-# 用户只需自然描述，Claude Code 自动调用工具
-"使用 gemini 分析这个模块的依赖关系"
-→ Claude Code 自动生成：cd src && gemini -p "分析依赖关系"
-
-"让 codex 实现用户注册功能"
-→ Claude Code 自动生成：codex -C src/auth --full-auto exec "实现注册"
-```
-
-**方式二：直接命令调用**
-
-```bash
-# 通过 Slash 命令精准调用
-/cli:chat --tool gemini "解释这个算法"
-/cli:analyze --tool qwen "分析性能瓶颈"
-/cli:execute --tool codex "优化查询性能"
-```
-
----
-
-#### 🔗 CLI 结果作为上下文（Memory）
-
-CLI 工具的分析结果可以被保存并作为后续操作的上下文（memory），实现智能化的工作流程：
-
-**1. 结果持久化**
-
-```bash
-# CLI 执行结果自动保存到会话目录
-/cli:chat --tool gemini "分析认证模块架构"
-→ 保存到：.workflow/active/WFS-xxx/.chat/chat-[timestamp].md
-
-/cli:analyze --tool qwen "评估性能瓶颈"
-→ 保存到：.workflow/active/WFS-xxx/.chat/analyze-[timestamp].md
-
-/cli:execute --tool codex "实现功能"
-→ 保存到：.workflow/active/WFS-xxx/.chat/execute-[timestamp].md
-```
-
-**2. 结果作为规划依据**
-
-```bash
-# Step 1: 分析现状（生成 memory）
-使用 gemini 深度分析认证系统的架构、安全性和性能问题
-→ 输出：详细分析报告（自动保存）
-
-# Step 2: 基于分析结果规划
-/workflow:plan "根据上述 Gemini 分析报告重构认证系统"
-→ 系统自动读取 .chat/ 中的分析报告作为上下文
-→ 生成精准的实施计划
-```
-
-**3. 结果作为实现依据**
-
-```bash
-# Step 1: 并行分析（生成多个 memory）
-使用 gemini 分析现有代码结构
-用 qwen 评估技术方案可行性
-→ 输出：多份分析报告
-
-# Step 2: 基于所有分析结果实现
-让 codex 综合上述 Gemini 和 Qwen 的分析，实现最优方案
-→ Codex 自动读取前序分析结果
-→ 生成符合架构设计的代码
-```
-
-**4. 跨会话引用**
-
-```bash
-# 引用历史会话的分析结果
-/cli:execute --tool codex "参考 WFS-2024-001 中的架构分析，实现新的支付模块"
-→ 系统自动加载指定会话的上下文
-→ 基于历史分析进行实现
-```
-
-**5. Memory 更新循环**
-
-```bash
-# 迭代优化流程
-使用 gemini 分析当前实现的问题
-→ 生成问题报告（memory）
-
-让 codex 根据问题报告优化代码
-→ 实现改进（更新 memory）
-
-用 qwen 验证优化效果
-→ 验证报告（追加 memory）
-
-# 所有结果累积为完整的项目 memory
-→ 支持后续决策和实现
-```
-
-**Memory 流转示例**：
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 1: 分析阶段（生成 Memory）                             │
-├─────────────────────────────────────────────────────────────┤
-│  Gemini 分析  →  架构分析报告 (.chat/analyze-001.md)          │
-│  Qwen 评估    →  方案评估报告 (.chat/analyze-002.md)          │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ 作为 Memory 输入
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 2: 规划阶段（使用 Memory）                             │
-├─────────────────────────────────────────────────────────────┤
-│  /workflow:plan  →  读取分析报告  →  生成实施计划             │
-│                     (.task/IMPL-*.json)                      │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ 作为 Memory 输入
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 3: 实现阶段（使用 Memory）                             │
-├─────────────────────────────────────────────────────────────┤
-│  Codex 实现   →  读取计划+分析  →  生成代码                   │
-│                     (.chat/execute-001.md)                   │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ 作为 Memory 输入
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 4: 验证阶段（使用 Memory）                             │
-├─────────────────────────────────────────────────────────────┤
-│  Gemini 审查  →  读取实现代码  →  质量报告                    │
-│                     (.chat/review-001.md)                    │
-└─────────────────────────────────────────────────────────────┘
-                      │
-                      ↓
-            完整的项目 Memory 库
-          支持未来所有决策和实现
-```
-
-**最佳实践**：
-
-1. **保持连续性**：在同一会话中执行相关任务，自动共享 memory
-2. **显式引用**：跨会话时明确引用历史分析（如"参考 WFS-xxx 的分析"）
-3. **增量更新**：每次分析和实现都追加到 memory，形成完整的决策链
-4. **定期整理**：使用 `/memory:update-related` 将 CLI 结果整合到 CLAUDE.md
-5. **质量优先**：高质量的分析 memory 能显著提升后续实现质量
-
----
-
-#### 🔄 工作流集成示例
-
-**集成到 Lite 工作流**：
-
-```bash
-# 1. 规划阶段：Gemini 分析
-/workflow:lite-plan -e "重构支付模块"
-→ 三维确认选择 "CLI 工具执行"
-
-# 2. 执行阶段：选择执行方式
-# 选项 A: 串联执行
-→ "使用 gemini 分析支付流程" → "让 codex 重构代码"
-
-# 选项 B: 并行分析 + 串联实现
-→ "用 gemini 分析架构" + "用 qwen 评估方案"
-→ "让 codex 基于分析结果重构"
-```
-
-**集成到 Full 工作流**：
-
-```bash
-# 1. 规划阶段
-/workflow:plan "实现分布式缓存"
-/workflow:action-plan-verify
-
-# 2. 分析阶段（并行）
-使用 gemini 分析现有缓存架构
-用 qwen 评估 Redis 集群方案
-
-# 3. 实现阶段（串联）
-/workflow:execute  # 或使用 CLI
-让 codex 实现 Redis 集群集成
-
-# 4. 测试阶段（并行）
-/workflow:test-gen WFS-cache
-→ 内部使用 gemini 分析 + codex 生成测试
-
-# 5. 审查阶段（串联）
-用 gemini 审查代码质量
-/workflow:review --type architecture
-```
-
----
-
-#### 💡 最佳实践
-
-**何时使用串联**：
-- 实现依赖设计方案
-- 测试依赖代码实现
-- 优化依赖性能分析
-
-**何时使用并行**：
-- 多维度分析（安全+性能+架构）
-- 多模块独立开发
-- 同时生成代码和测试
-
-**何时使用混合**：
-- 复杂功能开发（分析→设计→实现→测试）
-- 大规模重构（评估→规划→执行→验证）
-- 技术栈迁移（调研→方案→实施→优化）
-
-**工具选择建议**：
-1. **需要理解代码** → Gemini（首选）或 Qwen
-2. **需要编写代码** → Codex
-3. **复杂分析** → Gemini + Qwen 并行（互补验证）
-4. **精确实现** → Codex（基于 Gemini 分析）
-5. **快速原型** → 直接使用 Codex
-
----
-
 ## 🔄 典型场景完整流程
 
 ### 场景A：新功能开发（知道怎么做）

WORKFLOW_DECISION_GUIDE_EN.md

@@ -253,300 +253,6 @@ flowchart TD
 
 ---
 
-### 7️⃣ **CLI Tools Collaboration Mode - Multi-Model Intelligent Coordination**
-
-This project integrates three CLI tools supporting flexible serial, parallel, and hybrid execution:
-
-| Tool | Core Capabilities | Context Length | Use Cases |
-|------|------------------|----------------|-----------|
-| **Gemini** | Deep analysis, architecture design, planning | Ultra-long context | Code understanding, execution flow tracing, technical solution evaluation |
-| **Qwen** | Code review, pattern recognition | Ultra-long context | Gemini alternative, multi-dimensional analysis |
-| **Codex** | Precise code writing, bug location | Standard context | Feature implementation, test generation, code refactoring |
-
-#### 📋 Three Execution Modes
-
-**1. Serial Execution** - Sequential dependency
-
-Use case: Subsequent tasks depend on previous results
-
-```bash
-# Example: Analyze then implement
-# Step 1: Gemini analyzes architecture
-Use gemini to analyze the authentication module's architecture design, identify key components and data flow
-
-# Step 2: Codex implements based on analysis
-Have codex implement JWT authentication middleware based on the above architecture analysis
-```
-
-**Execution flow**:
-```
-Gemini analysis → Output architecture report → Codex reads report → Implement code
-```
-
----
-
-**2. Parallel Execution** - Concurrent processing
-
-Use case: Multiple independent tasks with no dependencies
-
-```bash
-# Example: Multi-dimensional analysis
-Use gemini to analyze authentication module security, focus on JWT, password storage, session management
-Use qwen to analyze authentication module performance bottlenecks, identify slow queries and optimization points
-Have codex generate unit tests for authentication module, covering all core features
-```
-
-**Execution flow**:
-```
-        ┌─ Gemini: Security analysis ─┐
-Parallel ┼─ Qwen: Performance analysis ┼─→ Aggregate results
-        └─ Codex: Test generation ────┘
-```
-
----
-
-**3. Hybrid Execution** - Combined serial and parallel
-
-Use case: Complex tasks with both parallel and serial phases
-
-```bash
-# Example: Complete feature development
-# Phase 1: Parallel analysis (independent tasks)
-Use gemini to analyze existing authentication system architecture patterns
-Use qwen to evaluate OAuth2 integration technical solutions
-
-# Phase 2: Serial implementation (depends on Phase 1)
-Have codex implement OAuth2 authentication flow based on above analysis
-
-# Phase 3: Parallel optimization (independent tasks)
-Use gemini to review code quality and security
-Have codex generate integration tests
-```
-
-**Execution flow**:
-```
-Phase 1: Gemini analysis ──┐
-         Qwen evaluation ──┼─→ Phase 2: Codex implementation ──→ Phase 3: Gemini review ──┐
-                           │                                              Codex tests ───┼─→ Complete
-                           └──────────────────────────────────────────────────────────────┘
-```
-
----
-
-#### 🎯 Semantic Invocation vs Command Invocation
-
-**Method 1: Natural Language Semantic Invocation** (Recommended)
-
-```bash
-# Users simply describe naturally, Claude Code auto-invokes tools
-"Use gemini to analyze this module's dependencies"
-→ Claude Code auto-generates: cd src && gemini -p "Analyze dependencies"
-
-"Have codex implement user registration feature"
-→ Claude Code auto-generates: codex -C src/auth --full-auto exec "Implement registration"
-```
-
-**Method 2: Direct Command Invocation**
-
-```bash
-# Precise invocation via Slash commands
-/cli:chat --tool gemini "Explain this algorithm"
-/cli:analyze --tool qwen "Analyze performance bottlenecks"
-/cli:execute --tool codex "Optimize query performance"
-```
-
----
-
-#### 🔗 CLI Results as Context (Memory)
-
-CLI tool analysis results can be saved and used as context (memory) for subsequent operations, enabling intelligent workflows:
-
-**1. Result Persistence**
-
-```bash
-# CLI execution results automatically saved to session directory
-/cli:chat --tool gemini "Analyze authentication module architecture"
-→ Saved to: .workflow/active/WFS-xxx/.chat/chat-[timestamp].md
-
-/cli:analyze --tool qwen "Evaluate performance bottlenecks"
-→ Saved to: .workflow/active/WFS-xxx/.chat/analyze-[timestamp].md
-
-/cli:execute --tool codex "Implement feature"
-→ Saved to: .workflow/active/WFS-xxx/.chat/execute-[timestamp].md
-```
-
-**2. Results as Planning Basis**
-
-```bash
-# Step 1: Analyze current state (generate memory)
-Use gemini to deeply analyze authentication system architecture, security, and performance issues
-→ Output: Detailed analysis report (auto-saved)
-
-# Step 2: Plan based on analysis results
-/workflow:plan "Refactor authentication system based on above Gemini analysis report"
-→ System automatically reads analysis reports from .chat/ as context
-→ Generate precise implementation plan
-```
-
-**3. Results as Implementation Basis**
-
-```bash
-# Step 1: Parallel analysis (generate multiple memories)
-Use gemini to analyze existing code structure
-Use qwen to evaluate technical solution feasibility
-→ Output: Multiple analysis reports
-
-# Step 2: Implement based on all analysis results
-Have codex synthesize above Gemini and Qwen analyses to implement optimal solution
-→ Codex automatically reads prior analysis results
-→ Generate code conforming to architecture design
-```
-
-**4. Cross-Session References**
-
-```bash
-# Reference historical session analysis results
-/cli:execute --tool codex "Refer to architecture analysis in WFS-2024-001, implement new payment module"
-→ System automatically loads specified session context
-→ Implement based on historical analysis
-```
-
-**5. Memory Update Loop**
-
-```bash
-# Iterative optimization flow
-Use gemini to analyze problems in current implementation
-→ Generate problem report (memory)
-
-Have codex optimize code based on problem report
-→ Implement improvements (update memory)
-
-Use qwen to verify optimization effectiveness
-→ Verification report (append to memory)
-
-# All results accumulate as complete project memory
-→ Support subsequent decisions and implementation
-```
-
-**Memory Flow Example**:
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 1: Analysis Phase (Generate Memory)                   │
-├─────────────────────────────────────────────────────────────┤
-│  Gemini analysis  →  Architecture report (.chat/analyze-001.md)│
-│  Qwen evaluation  →  Solution report (.chat/analyze-002.md)   │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ As Memory Input
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 2: Planning Phase (Use Memory)                        │
-├─────────────────────────────────────────────────────────────┤
-│  /workflow:plan  →  Read analysis reports  →  Generate plan   │
-│                     (.task/IMPL-*.json)                      │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ As Memory Input
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 3: Implementation Phase (Use Memory)                   │
-├─────────────────────────────────────────────────────────────┤
-│  Codex implement  →  Read plan+analysis  →  Generate code     │
-│                     (.chat/execute-001.md)                   │
-└─────────────────────┬───────────────────────────────────────┘
-                      │ As Memory Input
-                      ↓
-┌─────────────────────────────────────────────────────────────┐
-│  Phase 4: Verification Phase (Use Memory)                     │
-├─────────────────────────────────────────────────────────────┤
-│  Gemini review   →  Read implementation code  →  Quality report│
-│                     (.chat/review-001.md)                    │
-└─────────────────────────────────────────────────────────────┘
-                      │
-                      ↓
-            Complete Project Memory Library
-          Supporting All Future Decisions and Implementation
-```
-
-**Best Practices**:
-
-1. **Maintain Continuity**: Execute related tasks in the same session to automatically share memory
-2. **Explicit References**: Explicitly reference historical analyses when crossing sessions (e.g., "Refer to WFS-xxx analysis")
-3. **Incremental Updates**: Each analysis and implementation appends to memory, forming complete decision chain
-4. **Regular Organization**: Use `/memory:update-related` to consolidate CLI results into CLAUDE.md
-5. **Quality First**: High-quality analysis memory significantly improves subsequent implementation quality
-
----
-
-#### 🔄 Workflow Integration Examples
-
-**Integration with Lite Workflow**:
-
-```bash
-# 1. Planning phase: Gemini analysis
-/workflow:lite-plan -e "Refactor payment module"
-→ Three-dimensional confirmation selects "CLI Tools execution"
-
-# 2. Execution phase: Choose execution method
-# Option A: Serial execution
-→ "Use gemini to analyze payment flow" → "Have codex refactor code"
-
-# Option B: Parallel analysis + Serial implementation
-→ "Use gemini to analyze architecture" + "Use qwen to evaluate solution"
-→ "Have codex refactor based on analysis results"
-```
-
-**Integration with Full Workflow**:
-
-```bash
-# 1. Planning phase
-/workflow:plan "Implement distributed cache"
-/workflow:action-plan-verify
-
-# 2. Analysis phase (parallel)
-Use gemini to analyze existing cache architecture
-Use qwen to evaluate Redis cluster solution
-
-# 3. Implementation phase (serial)
-/workflow:execute  # Or use CLI
-Have codex implement Redis cluster integration
-
-# 4. Testing phase (parallel)
-/workflow:test-gen WFS-cache
-→ Internally uses gemini analysis + codex test generation
-
-# 5. Review phase (serial)
-Use gemini to review code quality
-/workflow:review --type architecture
-```
-
----
-
-#### 💡 Best Practices
-
-**When to use serial**:
-- Implementation depends on design solution
-- Testing depends on code implementation
-- Optimization depends on performance analysis
-
-**When to use parallel**:
-- Multi-dimensional analysis (security + performance + architecture)
-- Multi-module independent development
-- Simultaneous code and test generation
-
-**When to use hybrid**:
-- Complex feature development (analysis → design → implementation → testing)
-- Large-scale refactoring (evaluation → planning → execution → verification)
-- Tech stack migration (research → solution → implementation → optimization)
-
-**Tool selection guidelines**:
-1. **Need to understand code** → Gemini (preferred) or Qwen
-2. **Need to write code** → Codex
-3. **Complex analysis** → Gemini + Qwen parallel (complementary verification)
-4. **Precise implementation** → Codex (based on Gemini analysis)
-5. **Quick prototype** → Direct Codex usage
-
----
-
 ## 🔄 Complete Flow for Typical Scenarios
 
 ### Scenario A: New Feature Development (Know How to Build)