claude-code-workflow 6.2.5 → 6.2.6

package/.claude/workflows/cli-templates/prompts/memory/02-document-module-structure.txt

@@ -0,0 +1,165 @@
+Create or update CLAUDE.md documentation using unified module/file template.
+
+## ⚠️ FILE NAMING RULE (CRITICAL)
+- Target file: MUST be named exactly `CLAUDE.md` in the current directory
+- NEVER create files like `ToolSidebar.CLAUDE.md` or `[filename].CLAUDE.md`
+- ALWAYS use the fixed name: `CLAUDE.md`
+
+## CORE CHECKLIST ⚡
+□ MUST create/update file named exactly 'CLAUDE.md' (not variants)
+□ MUST include all 6 sections: Purpose, Structure, Components, Dependencies, Integration, Implementation
+□ For code files: Document all public/exported APIs with complete parameter details
+□ For folders: Reference subdirectory CLAUDE.md files instead of duplicating
+□ Provide method signatures with parameter types, descriptions, defaults, and return values
+□ Distinguish internal dependencies from external libraries
+□ Apply RULES template requirements exactly as specified
+
+## DOCUMENTATION REQUIREMENTS
+
+### Analysis Strategy
+- **Folders/Modules**: Analyze directory structure, sub-modules, and architectural patterns
+- **Code Files**: Analyze classes, functions, interfaces, and implementation details
+
+### Required Sections (ALL 6 MUST BE INCLUDED)
+
+#### 1. Purpose and Scope
+- Clear description of what this module/file does
+- Main responsibilities and boundaries
+- Role within the larger system
+
+#### 2. Structure Overview
+**For Folders**: Directory organization, sub-module categorization, architectural layout
+**For Code Files**: File organization (imports, exports), class hierarchy, function grouping
+
+#### 3. Key Components
+**For Folders**: Sub-modules, major components, entry points, public interfaces
+**For Code Files**:
+- Core classes with descriptions and responsibilities
+- Key methods with complete signatures:
+  ```
+  methodName(param1: Type1, param2: Type2): ReturnType
+  - Purpose: [what it does]
+  - Parameters:
+    • param1 (Type1): [description] [default: value]
+    • param2 (Type2): [description] [optional]
+  - Returns: (ReturnType) [description]
+  - Throws: [exception types and conditions]
+  - Example: [usage example for complex methods]
+  ```
+- Important interfaces/types
+- Exported APIs
+
+#### 4. Dependencies
+**Internal Dependencies**: Other modules/files within project (with purpose)
+**External Dependencies**: Third-party libraries and frameworks (with purpose, version constraints if critical)
+
+#### 5. Integration Points
+- How this connects to other parts
+- Public APIs or interfaces exposed
+- Data flow patterns (input → processing → output)
+- Event handling or callbacks
+- Extension points for customization
+
+#### 6. Implementation Notes
+- Key design patterns used (e.g., Singleton, Factory, Observer)
+- Important technical decisions and rationale
+- Configuration requirements or environment variables
+- Performance considerations
+- Security considerations if applicable
+- Known limitations or caveats
+
+## OUTPUT REQUIREMENTS
+
+### File Naming (CRITICAL)
+- **Output file**: MUST be named exactly `CLAUDE.md` in the current directory
+- **Examples of WRONG naming**: `ToolSidebar.CLAUDE.md`, `index.CLAUDE.md`, `utils.CLAUDE.md`
+- **Correct naming**: `CLAUDE.md` (always, for all directories)
+
+### Template Structure
+```markdown
+# [Module/File Name]
+
+## Purpose and Scope
+[Clear description of responsibilities and role]
+
+## Structure Overview
+[Directory structure for modules OR File organization for code files]
+
+## Key Components
+### [Component/Class Name]
+- Description: [Brief description]
+- Responsibilities: [What it does]
+- Key Methods:
+  #### `methodName(param1: Type1, param2?: Type2): ReturnType`
+  - Purpose: [what this method does]
+  - Parameters:
+    • param1 (Type1): [description]
+    • param2 (Type2): [description] [optional] [default: value]
+  - Returns: (ReturnType) [description]
+  - Throws: [exceptions if applicable]
+
+## Dependencies
+### Internal Dependencies
+- `[module/file path]` - [purpose]
+
+### External Dependencies
+- `[library name]` - [purpose and usage]
+
+## Integration Points
+### Public APIs
+- `[API/function signature]` - [description]
+
+### Data Flow
+[How data flows through this module/file]
+
+## Implementation Notes
+### Design Patterns
+- [Pattern name]: [Usage and rationale]
+
+### Technical Decisions
+- [Decision]: [Rationale]
+
+### Considerations
+- Performance: [notes]
+- Security: [notes]
+- Limitations: [notes]
+```
+
+### Documentation Style
+- **Concise but complete** - Focus on "what" and "why", not detailed "how"
+- **Code signatures** for key APIs - Include all parameter details
+- **Parameters**: Name, type, description, optional/default indicators, constraints
+- **Return values**: Type, description, special conditions (null, undefined, empty)
+- **Evidence-based** - Reference related documentation when appropriate
+- **Examples** for complex methods - Show usage patterns
+
+### Content Restrictions (STRICTLY AVOID)
+- ❌ Duplicating content from other CLAUDE.md files (reference instead)
+- ❌ Overly detailed code explanations (code should be self-documenting)
+- ❌ Complete code listings (use signatures and descriptions)
+- ❌ Version-specific details unless critical
+- ❌ Documenting every single function (focus on public/exported APIs)
+
+### Method Documentation Rules
+- **Public/Exported methods**: MUST document with full parameter details
+- **Private/Internal methods**: Only document if complex or critical
+- **Parameters**: MUST include type, description, constraints, defaults
+- **Return values**: MUST document type and description
+- **Exceptions**: Document all thrown errors
+
+### Special Instructions
+- If analyzing folder with existing subdirectory CLAUDE.md files → reference them
+- For code files → prioritize exported/public APIs
+- Keep dependency lists focused on direct dependencies (not transitive)
+- Update existing CLAUDE.md files rather than creating duplicate sections
+
+## VERIFICATION CHECKLIST ✓
+□ Output file is named exactly 'CLAUDE.md' (not [filename].CLAUDE.md)
+□ All 6 required sections included (Purpose, Structure, Components, Dependencies, Integration, Implementation)
+□ All public/exported APIs documented with complete signatures
+□ Parameters documented with types, descriptions, and defaults
+□ References used instead of duplicating subdirectory documentation
+□ Internal vs external dependencies clearly distinguished
+□ Examples provided for non-trivial methods
+
+Focus: Comprehensive yet concise documentation covering all essential aspects without redundancy.

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

@@ -0,0 +1,109 @@
+# 软件架构规划模板
+
+## Role & Output Requirements
+
+**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.
+
+## 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
+
+## 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
+
+## 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)
+
+## 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)
+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)**
+
+### **第一部分:需求分析与规划总览 (Part 1: Requirements Analysis & Planning Overview)**
+*   **1.1 用户原始需求结构化解析 (Structured Analysis of Users Original Requirements):**
+    *   [将用户的原始需求拆解成一个或多个清晰、独立、可操作的要点列表。每个要点都是一个明确的目标。]
+    *   **- 需求点 A:** [描述第一个具体需求]
+    *   **- 需求点 B:** [描述第二个具体需求]
+    *   **- ...**
+*   **1.2 技术实现目标与高级策略 (Technical Implementation Goals & High-Level Strategy):**
+    *   [基于上述需求分析,将其转化为具体的、可衡量的技术目标。并简述为达成这些目标将采用的整体技术思路或架构策略。例如:为实现【需求点A】,我们需要在 `ServiceA` 中引入一个新的处理流程。为实现【需求点B】,我们将重构 `ModuleB` 的数据验证逻辑,以提高其扩展性。]
+
+### **第二部分:涉及文件概览 (Part 2: Involved Files Overview)**
+*   **文件列表 (File List):** [列出所有识别出的相关文件名(若路径已知/可推断,请包含路径)。不仅包括直接修改的文件,也包括提供关键上下文或可能受间接影响的文件。示例: `- src/core/module_a.py (直接修改)`, `- src/utils/helpers.py (依赖项,可能受影响)`, `- configs/settings.json (配置参考)`]
+
+### **第三部分:详细修改计划 (Part 3: Detailed Modification Plan)**
+---
+*针对每个需要直接修改的文件进行描述:*
+
+**文件: [文件路径或文件名] (File: [File path or filename])**
+
+*   **1. 位置 (Location):**
+    *   [清晰说明函数、类、方法或具体的代码区域,如果可能,指出大致行号范围。示例: 函数 `calculate_total_price` 内部,约第 75-80 行]
+
+*   **1.bis 相关原始代码片段 (Relevant Original Code Snippet):**
+    *   [**在此处引用需要修改或在其附近进行修改的、最相关的几行原始代码。** 这为开发者提供了直接的上下文。如果代码未提供,则注明相关代码未提供,根据描述进行规划。]
+    *   ```[language]
+        // 引用相关的1-5行原始代码
+        ```
+
+*   **2. 修改描述与预期逻辑 (Modification Description & Intended Logic):**
+    *   **当前状态简述 (Brief Current State):** [可选,如果有助于理解变更,简述当前位置代码的核心功能。]
+    *   **拟议修改点 (Proposed Changes):**
+        *   [分步骤详细描述需要进行的逻辑更改。用清晰的中文自然语言解释 *什么* 需要被改变或添加。]
+    *   **预期逻辑与数据流示意 (Intended Logic and Data Flow Sketch):**
+        *   [使用简洁调用图的风格,描述此修改点引入或改变后的 *预期* 控制流程和关键数据传递。]
+        *   [**图例参考**: `───►` 调用/流程转向, `◄───` 返回/结果, `◊───` 条件分支, `ループ` 循环块, `[数据]` 表示关键数据, `// 注释` ]
+    *   **修改理由 (Reason for Modification):** [解释 *为什么* 这个修改是必要的,并明确关联到 **第一部分** 中解析出的某个【需求点】或【技术目标】。]
+    *   **预期结果 (Intended Outcome):** [描述此修改完成后,该代码段预期的行为或产出。]
+
+*   **3. 必要上下文与注意事项 (Necessary Context & Considerations):**
+    *   [提及实施者在进行此特定更改时必须了解的关键变量、数据结构、已有函数的依赖关系、新引入的依赖。]
+    *   [**重点指出**潜在的连锁反应、对其他模块的可能影响、性能考量、错误处理、事务性、并发问题或数据完整性等重要风险点。]
+
+---
+*(对每个需要修改的文件重复上述格式)*
+
+## 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
+
+## 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

package/.claude/workflows/cli-templates/prompts/planning/02-breakdown-task-steps.txt

@@ -0,0 +1,30 @@
+Create detailed task breakdown and implementation planning.
+
+## CORE CHECKLIST ⚡
+□ Break down tasks into manageable subtasks (3-8 hours each)
+□ Identify all dependencies and execution sequence
+□ Provide realistic effort estimates with buffer
+□ Document risks for each task
+
+## REQUIRED ANALYSIS
+1. Break down complex tasks into manageable subtasks
+2. Identify dependencies and execution sequence requirements
+3. Estimate effort and resource requirements for each task
+4. Map task relationships and critical path analysis
+5. Document risks and mitigation strategies
+
+## OUTPUT REQUIREMENTS
+- Hierarchical task breakdown with specific deliverables
+- Dependency mapping and execution sequence
+- Effort estimation with confidence levels
+- Resource allocation and skill requirements
+- Risk assessment and mitigation plans for each task
+
+## VERIFICATION CHECKLIST ✓
+□ All tasks broken down to manageable size (3-8 hours)
+□ Dependencies mapped and critical path identified
+□ Effort estimates realistic with buffer included
+□ Every task has clear deliverable defined
+□ Risks documented with mitigation strategies
+
+Focus: Actionable task planning with clear deliverables, dependencies, and realistic timelines.

package/.claude/workflows/cli-templates/prompts/planning/02-design-component-spec.txt

@@ -0,0 +1,28 @@
+Guide component implementation and development patterns.
+
+## CORE CHECKLIST ⚡
+□ Define component interface and API requirements clearly
+□ Identify reusable patterns and composition strategies
+□ Plan state management and data flow before implementation
+□ Design a comprehensive testing and validation approach
+
+## REQUIRED ANALYSIS
+1. Define component interface and API requirements
+2. Identify reusable patterns and composition strategies
+3. Plan state management and data flow implementation
+4. Design component testing and validation approach
+5. Document integration points and usage examples
+
+## OUTPUT REQUIREMENTS
+- Component specification with clear interface definition
+- Implementation patterns and best practices
+- State management strategy and data flow design
+- Testing approach and validation criteria
+
+## VERIFICATION CHECKLIST ✓
+□ Component specification includes a clear interface definition
+□ Reusable implementation patterns and best practices are documented
+□ State management and data flow design is clear and robust
+□ A thorough testing and validation approach is defined
+
+Focus: Reusable, maintainable component design with clear usage patterns.

package/.claude/workflows/cli-templates/prompts/planning/03-evaluate-concept-feasibility.txt

@@ -0,0 +1,127 @@
+Conduct comprehensive concept evaluation to assess feasibility, identify risks, and provide optimization recommendations.
+
+## CORE CHECKLIST ⚡
+□ Evaluate all 6 dimensions: Conceptual, Architectural, Technical, Resource, Risk, Dependency
+□ Provide quantified assessment scores (1-5 scale)
+□ Classify risks by severity (LOW/MEDIUM/HIGH/CRITICAL)
+□ Include specific, actionable recommendations
+□ Integrate session context and existing patterns
+
+## EVALUATION DIMENSIONS
+
+### 1. Conceptual Integrity
+- Design Coherence: Logical component connections
+- Requirement Completeness: All requirements identified
+- Scope Clarity: Defined and bounded scope
+- Success Criteria: Measurable metrics established
+
+### 2. Architectural Soundness
+- System Integration: Fit with existing architecture
+- Design Patterns: Appropriate pattern usage
+- Modularity: Maintainable structure
+- Scalability: Future requirement capacity
+
+### 3. Technical Feasibility
+- Implementation Complexity: Difficulty level assessment
+- Technology Maturity: Stable, supported technologies
+- Skill Requirements: Team expertise availability
+- Infrastructure Needs: Required changes/additions
+
+### 4. Resource Assessment
+- Development Time: Realistic estimation
+- Team Resources: Size and skill composition
+- Budget Impact: Financial implications
+- Opportunity Cost: Delayed initiatives
+
+### 5. Risk Identification
+- Technical Risks: Limitations, complexity, unknowns
+- Business Risks: Market timing, adoption, impact
+- Integration Risks: Compatibility challenges
+- Resource Risks: Availability, skills, timeline
+
+### 6. Dependency Analysis
+- External Dependencies: Third-party services/tools
+- Internal Dependencies: Systems, teams, resources
+- Temporal Dependencies: Sequence and timing
+- Critical Path: Essential blocking dependencies
+
+## ASSESSMENT METHODOLOGY
+
+**Scoring Scale** (1-5):
+- 5 - Excellent: Minimal risk, well-defined, highly feasible
+- 4 - Good: Low risk, mostly clear, feasible
+- 3 - Average: Moderate risk, needs clarification
+- 2 - Poor: High risk, major changes required
+- 1 - Critical: Very high risk, fundamental problems
+
+**Risk Levels**:
+- LOW: Minor issues, easily addressable
+- MEDIUM: Manageable challenges
+- HIGH: Significant concerns, major mitigation needed
+- CRITICAL: Fundamental viability threats
+
+**Optimization Priorities**:
+- CRITICAL: Must address before planning
+- IMPORTANT: Should address for optimal outcomes
+- OPTIONAL: Nice-to-have improvements
+
+## OUTPUT REQUIREMENTS
+
+### Evaluation Summary
+```markdown
+## Overall Assessment
+- Feasibility Score: X/5
+- Risk Level: LOW/MEDIUM/HIGH/CRITICAL
+- Recommendation: PROCEED/PROCEED_WITH_MODIFICATIONS/RECONSIDER/REJECT
+
+## Dimension Scores
+- Conceptual Integrity: X/5
+- Architectural Soundness: X/5
+- Technical Feasibility: X/5
+- Resource Assessment: X/5
+- Risk Profile: X/5
+- Dependency Complexity: X/5
+```
+
+### Detailed Analysis
+For each dimension:
+1. Assessment: Current state evaluation
+2. Strengths: What works well
+3. Concerns: Issues and risks
+4. Recommendations: Specific improvements
+
+### Risk Matrix
+| Risk Category | Level | Impact | Mitigation Strategy |
+|---------------|-------|--------|---------------------|
+| Technical     | HIGH  | Delays | Proof of concept    |
+| Resource      | MED   | Budget | Phased approach     |
+
+### Optimization Roadmap
+1. CRITICAL: [Issue] - [Recommendation] - [Impact]
+2. IMPORTANT: [Issue] - [Recommendation] - [Impact]
+3. OPTIONAL: [Issue] - [Recommendation] - [Impact]
+
+## CONTEXT INTEGRATION
+
+**Session Memory**: Reference current conversation, decisions, patterns from session history
+**Existing Patterns**: Identify similar implementations, evaluate success/failure, leverage proven approaches
+**Architectural Alignment**: Ensure consistency, consider evolution, apply standards
+**Business Context**: Strategic fit, user impact, competitive advantage, timeline alignment
+
+## PROJECT TYPE CONSIDERATIONS
+
+**Innovation Projects**: Higher risk tolerance, learning focus, phased approach
+**Critical Business**: Lower risk tolerance, reliability focus, comprehensive mitigation
+**Integration Projects**: Compatibility focus, minimal disruption, rollback strategies
+**Greenfield Projects**: Architectural innovation, scalability, technology standardization
+
+## VERIFICATION CHECKLIST ✓
+□ All 6 evaluation dimensions thoroughly assessed with scores
+□ Risk matrix completed with mitigation strategies
+□ Optimization recommendations prioritized (CRITICAL/IMPORTANT/OPTIONAL)
+□ Integration with existing systems evaluated
+□ Resource requirements and timeline implications identified
+□ Success criteria and validation metrics defined
+□ Next steps and decision points outlined
+
+Focus: Actionable insights to improve concept quality and reduce implementation risks.

package/.claude/workflows/cli-templates/prompts/planning/03-plan-migration-strategy.txt

@@ -0,0 +1,30 @@
+Plan system migration and modernization strategies.
+
+## CORE CHECKLIST ⚡
+□ Assess current system completely before planning migration
+□ Plan incremental migration (avoid big-bang approach)
+□ Include rollback plan for every migration step
+□ Provide file:line references for all affected code
+
+## REQUIRED ANALYSIS
+1. Assess current system architecture and migration requirements
+2. Identify migration paths and transformation strategies
+3. Plan data migration and system cutover procedures
+4. Evaluate compatibility and integration challenges
+5. Document rollback plans and risk mitigation strategies
+
+## OUTPUT REQUIREMENTS
+- Migration strategy with step-by-step execution plan
+- Data migration procedures and validation checkpoints
+- Compatibility assessment with file:line references
+- Risk analysis and rollback procedures for each phase
+- Testing strategy for migration validation
+
+## VERIFICATION CHECKLIST ✓
+□ Migration planned in incremental phases (not big-bang)
+□ Every phase has rollback plan documented
+□ Data migration validated with checkpoints
+□ Compatibility issues identified and mitigated
+□ Testing strategy covers all migration phases
+
+Focus: Low-risk incremental migration with comprehensive fallback options.

package/.claude/workflows/cli-templates/prompts/rules/rule-api.txt

@@ -0,0 +1,122 @@
+# Rule Template: API Rules (Backend/Fullstack Only)
+
+## Variables
+- {TECH_STACK_NAME}: Tech stack display name
+- {FILE_EXT}: File extension pattern
+- {API_FRAMEWORK}: API framework (Express, FastAPI, etc)
+
+## Output Format
+
+```markdown
+---
+paths:
+  - "**/api/**/*.{FILE_EXT}"
+  - "**/routes/**/*.{FILE_EXT}"
+  - "**/endpoints/**/*.{FILE_EXT}"
+  - "**/controllers/**/*.{FILE_EXT}"
+  - "**/handlers/**/*.{FILE_EXT}"
+---
+
+# {TECH_STACK_NAME} API Rules
+
+## Endpoint Design
+
+[REST/GraphQL conventions from Exa research]
+
+### URL Structure
+- Resource naming (plural nouns)
+- Nesting depth limits
+- Query parameter conventions
+- Version prefixing
+
+### HTTP Methods
+- GET: Read operations
+- POST: Create operations
+- PUT/PATCH: Update operations
+- DELETE: Remove operations
+
+### Status Codes
+- 2xx: Success responses
+- 4xx: Client errors
+- 5xx: Server errors
+
+## Request Validation
+
+[Input validation patterns]
+
+### Schema Validation
+```{lang}
+// Example validation schema
+```
+
+### Required Fields
+- Validation approach
+- Error messages format
+- Sanitization rules
+
+## Response Format
+
+[Standard response structures]
+
+### Success Response
+```json
+{
+  "data": {},
+  "meta": {}
+}
+```
+
+### Pagination
+```json
+{
+  "data": [],
+  "pagination": {
+    "page": 1,
+    "limit": 20,
+    "total": 100
+  }
+}
+```
+
+## Error Responses
+
+[Error handling for APIs]
+
+### Error Format
+```json
+{
+  "error": {
+    "code": "ERROR_CODE",
+    "message": "Human readable message",
+    "details": {}
+  }
+}
+```
+
+### Common Error Codes
+- VALIDATION_ERROR
+- NOT_FOUND
+- UNAUTHORIZED
+- FORBIDDEN
+
+## Authentication & Authorization
+
+[Auth patterns]
+- Token handling
+- Permission checks
+- Rate limiting
+
+## Documentation
+
+[API documentation standards]
+- OpenAPI/Swagger
+- Inline documentation
+- Example requests/responses
+```
+
+## Content Guidelines
+
+- Focus on API-specific patterns
+- Include request/response examples
+- Cover security considerations
+- Reference framework conventions