claude-code-workflow 6.2.3 → 6.2.5

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

@@ -1,165 +0,0 @@
-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

@@ -1,109 +0,0 @@
-# 软件架构规划模板
-
-## 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

@@ -1,30 +0,0 @@
-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

@@ -1,28 +0,0 @@
-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

@@ -1,127 +0,0 @@
-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

@@ -1,30 +0,0 @@
-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

@@ -1,122 +0,0 @@
-# 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