claude-code-workflow 6.3.53 → 7.0.0

package/.claude/workflows/cli-templates/prompts/planning-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-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

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

@@ -1,122 +0,0 @@
-# Rule Template: Component Rules (Frontend/Fullstack Only)
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {FILE_EXT}: File extension pattern
-- {UI_FRAMEWORK}: UI framework (React, Vue, etc)
-
-## Output Format
-
-```markdown
----
-paths:
-  - "**/components/**/*.{FILE_EXT}"
-  - "**/ui/**/*.{FILE_EXT}"
-  - "**/views/**/*.{FILE_EXT}"
-  - "**/pages/**/*.{FILE_EXT}"
----
-
-# {TECH_STACK_NAME} Component Rules
-
-## Component Structure
-
-[Organization patterns from Exa research]
-
-### File Organization
-```
-components/
-├── common/          # Shared components
-├── features/        # Feature-specific
-├── layout/          # Layout components
-└── ui/              # Base UI elements
-```
-
-### Component Template
-```{lang}
-// Standard component structure
-```
-
-### Naming Conventions
-- PascalCase for components
-- Descriptive names
-- Prefix conventions (if any)
-
-## Props & State
-
-[State management guidelines]
-
-### Props Definition
-```{lang}
-// Props type/interface example
-```
-
-### Props Best Practices
-- Required vs optional
-- Default values
-- Prop validation
-- Prop naming
-
-### Local State
-- When to use local state
-- State initialization
-- State updates
-
-### Shared State
-- State management approach
-- Context usage
-- Store patterns
-
-## Styling
-
-[CSS/styling conventions]
-
-### Approach
-- [CSS Modules/Styled Components/Tailwind/etc]
-
-### Style Organization
-```{lang}
-// Style example
-```
-
-### Naming Conventions
-- Class naming (BEM, etc)
-- CSS variable usage
-- Theme integration
-
-## Accessibility
-
-[A11y requirements]
-
-### Essential Requirements
-- Semantic HTML
-- ARIA labels
-- Keyboard navigation
-- Focus management
-
-### Testing A11y
-- Automated checks
-- Manual testing
-- Screen reader testing
-
-## Performance
-
-[Performance guidelines]
-
-### Optimization Patterns
-- Memoization
-- Lazy loading
-- Code splitting
-- Virtual lists
-
-### Avoiding Re-renders
-- When to memoize
-- Callback optimization
-- State structure
-```
-
-## Content Guidelines
-
-- Focus on component-specific patterns
-- Include framework-specific examples
-- Cover accessibility requirements
-- Address performance considerations

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

@@ -1,89 +0,0 @@
-# Rule Template: Configuration Rules
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {CONFIG_FILES}: List of config file patterns
-
-## Output Format
-
-```markdown
----
-paths:
-  - "*.config.*"
-  - ".*rc"
-  - ".*rc.{js,json,yaml,yml}"
-  - "package.json"
-  - "tsconfig*.json"
-  - "pyproject.toml"
-  - "Cargo.toml"
-  - "go.mod"
-  - ".env*"
----
-
-# {TECH_STACK_NAME} Configuration Rules
-
-## Project Setup
-
-[Configuration guidelines from Exa research]
-
-### Essential Config Files
-- [List primary config files]
-- [Purpose of each]
-
-### Recommended Structure
-```
-project/
-├── [config files]
-├── src/
-└── tests/
-```
-
-## Tooling
-
-[Linters, formatters, bundlers]
-
-### Linting
-- Tool: [ESLint/Pylint/etc]
-- Config file: [.eslintrc/pyproject.toml/etc]
-- Key rules to enable
-
-### Formatting
-- Tool: [Prettier/Black/etc]
-- Integration with editor
-- Pre-commit hooks
-
-### Build Tools
-- Bundler: [Webpack/Vite/etc]
-- Build configuration
-- Optimization settings
-
-## Environment
-
-[Environment management]
-
-### Environment Variables
-- Naming conventions
-- Required vs optional
-- Secret handling
-- .env file structure
-
-### Development vs Production
-- Environment-specific configs
-- Feature flags
-- Debug settings
-
-## Dependencies
-
-[Dependency management]
-- Lock file usage
-- Version pinning strategy
-- Security updates
-- Peer dependencies
-```
-
-## Content Guidelines
-
-- Focus on config file best practices
-- Include security considerations
-- Cover development workflow setup
-- Mention CI/CD integration where relevant

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

@@ -1,60 +0,0 @@
-# Rule Template: Core Principles
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {FILE_EXT}: File extension pattern
-
-## Output Format
-
-```markdown
----
-paths: **/*.{FILE_EXT}
----
-
-# {TECH_STACK_NAME} Core Principles
-
-## Philosophy
-
-[Synthesize core philosophy from Exa research]
-- Key paradigms and mental models
-- Design philosophy
-- Community conventions
-
-## Naming Conventions
-
-[Language-specific naming rules]
-- Variables and functions
-- Classes and types
-- Files and directories
-- Constants and enums
-
-## Code Organization
-
-[Structure and module guidelines]
-- File structure patterns
-- Module boundaries
-- Import organization
-- Dependency management
-
-## Type Safety
-
-[Type system best practices - if applicable]
-- Type annotation guidelines
-- Generic usage patterns
-- Type inference vs explicit types
-- Null/undefined handling
-
-## Documentation
-
-[Documentation standards]
-- Comment style
-- JSDoc/docstring format
-- README conventions
-```
-
-## Content Guidelines
-
-- Focus on universal principles that apply to ALL files
-- Keep rules actionable and specific
-- Include rationale for each rule
-- Reference official style guides where applicable

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

@@ -1,70 +0,0 @@
-# Rule Template: Implementation Patterns
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {FILE_EXT}: File extension pattern
-
-## Output Format
-
-```markdown
----
-paths: src/**/*.{FILE_EXT}
----
-
-# {TECH_STACK_NAME} Implementation Patterns
-
-## Common Patterns
-
-[With code examples from Exa research]
-
-### Pattern 1: [Name]
-```{lang}
-// Example code
-```
-**When to use**: [Context]
-**Benefits**: [Why this pattern]
-
-### Pattern 2: [Name]
-...
-
-## Anti-Patterns to Avoid
-
-[Common mistakes with examples]
-
-### Anti-Pattern 1: [Name]
-```{lang}
-// Bad example
-```
-**Problem**: [Why it's bad]
-**Solution**: [Better approach]
-
-## Error Handling
-
-[Error handling conventions]
-- Error types and hierarchy
-- Try-catch patterns
-- Error propagation
-- Logging practices
-
-## Async Patterns
-
-[Asynchronous code conventions - if applicable]
-- Promise handling
-- Async/await usage
-- Concurrency patterns
-- Error handling in async code
-
-## State Management
-
-[State handling patterns]
-- Local state patterns
-- Shared state approaches
-- Immutability practices
-```
-
-## Content Guidelines
-
-- Focus on source code implementation
-- Provide concrete code examples
-- Show both good and bad patterns
-- Include context for when to apply each pattern

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

@@ -1,81 +0,0 @@
-# Rule Template: Testing Rules
-
-## Variables
-- {TECH_STACK_NAME}: Tech stack display name
-- {FILE_EXT}: File extension pattern
-- {TEST_FRAMEWORK}: Primary testing framework
-
-## Output Format
-
-```markdown
----
-paths:
-  - "**/*.{test,spec}.{FILE_EXT}"
-  - "tests/**/*.{FILE_EXT}"
-  - "__tests__/**/*.{FILE_EXT}"
-  - "**/test_*.{FILE_EXT}"
-  - "**/*_test.{FILE_EXT}"
----
-
-# {TECH_STACK_NAME} Testing Rules
-
-## Testing Framework
-
-[Recommended frameworks from Exa research]
-- Primary: {TEST_FRAMEWORK}
-- Assertion library
-- Mocking library
-- Coverage tool
-
-## Test Structure
-
-[Organization patterns]
-
-### File Naming
-- Unit tests: `*.test.{ext}` or `*.spec.{ext}`
-- Integration tests: `*.integration.test.{ext}`
-- E2E tests: `*.e2e.test.{ext}`
-
-### Test Organization
-```{lang}
-describe('[Component/Module]', () => {
-  describe('[method/feature]', () => {
-    it('should [expected behavior]', () => {
-      // Arrange
-      // Act
-      // Assert
-    });
-  });
-});
-```
-
-## Mocking & Fixtures
-
-[Best practices]
-- Mock creation patterns
-- Fixture organization
-- Test data factories
-- Cleanup strategies
-
-## Assertions
-
-[Assertion patterns]
-- Common assertions
-- Custom matchers
-- Async assertions
-- Error assertions
-
-## Coverage Requirements
-
-[Coverage guidelines]
-- Minimum coverage thresholds
-- What to cover vs skip
-- Coverage report interpretation
-```
-
-## Content Guidelines
-
-- Include framework-specific patterns
-- Show test structure examples
-- Cover both unit and integration testing
-- Include async testing patterns