mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-03-29 20:11:04 +08:00
Add comprehensive analysis and development templates for CLAUDE workflows
- Introduced new analysis templates for architecture, implementation patterns, performance, quality, and security. - Created detailed development templates for component creation, debugging, feature implementation, refactoring, testing, and migration planning. - Established structured documentation guidelines for root, domain, module, and sub-module levels to enhance clarity and organization. - Implemented a hierarchy analysis template to optimize project structure and documentation depth. - Updated codex-unified documentation to reflect new command structures, template usage, and best practices for autonomous development workflows.
This commit is contained in:
catlog22
269
.claude/workflows/cli-templates/commands/context-analysis.md
Normal file
269
.claude/workflows/cli-templates/commands/context-analysis.md
Normal file
@@ -0,0 +1,269 @@
|
||||
# Context Analysis Command Templates
|
||||
|
||||
**完整的上下文获取命令示例**
|
||||
|
||||
## 项目完整上下文获取
|
||||
|
||||
### 基础项目上下文
|
||||
```bash
|
||||
# 获取项目完整上下文
|
||||
cd /project/root && gemini --all-files -p "@{CLAUDE.md,**/*CLAUDE.md}
|
||||
|
||||
Extract comprehensive project context for agent coordination:
|
||||
1. Implementation patterns and coding standards
|
||||
2. Available utilities and shared libraries
|
||||
3. Architecture decisions and design principles
|
||||
4. Integration points and module dependencies
|
||||
5. Testing strategies and quality standards
|
||||
|
||||
Output: Context package with patterns, utilities, standards, integration points"
|
||||
```
|
||||
|
||||
### 技术栈特定上下文
|
||||
```bash
|
||||
# React 项目上下文
|
||||
cd /project/root && gemini --all-files -p "@{src/components/**/*,src/hooks/**/*} @{CLAUDE.md}
|
||||
|
||||
React application context analysis:
|
||||
1. Component patterns and composition strategies
|
||||
2. Hook usage patterns and state management
|
||||
3. Styling approaches and design system
|
||||
4. Testing patterns and coverage strategies
|
||||
5. Performance optimization techniques
|
||||
|
||||
Output: React development context with specific patterns"
|
||||
|
||||
# Node.js API 上下文
|
||||
cd /project/root && gemini --all-files -p "@{**/api/**/*,**/routes/**/*,**/services/**/*} @{CLAUDE.md}
|
||||
|
||||
Node.js API context analysis:
|
||||
1. Route organization and endpoint patterns
|
||||
2. Middleware usage and request handling
|
||||
3. Service layer architecture and patterns
|
||||
4. Database integration and data access
|
||||
5. Error handling and validation strategies
|
||||
|
||||
Output: API development context with integration patterns"
|
||||
```
|
||||
|
||||
## 领域特定上下文
|
||||
|
||||
### 认证系统上下文
|
||||
```bash
|
||||
# 认证和安全上下文
|
||||
gemini -p "@{**/*auth*,**/*login*,**/*session*,**/*security*} @{CLAUDE.md}
|
||||
|
||||
Authentication and security context analysis:
|
||||
1. Authentication mechanisms and flow patterns
|
||||
2. Authorization and permission management
|
||||
3. Session management and token handling
|
||||
4. Security middleware and protection layers
|
||||
5. Encryption and data protection methods
|
||||
|
||||
Output: Security implementation context with patterns"
|
||||
```
|
||||
|
||||
### 数据层上下文
|
||||
```bash
|
||||
# 数据库和模型上下文
|
||||
gemini -p "@{**/models/**/*,**/db/**/*,**/migrations/**/*} @{CLAUDE.md}
|
||||
|
||||
Database and data layer context analysis:
|
||||
1. Data model patterns and relationships
|
||||
2. Query patterns and optimization strategies
|
||||
3. Migration patterns and schema evolution
|
||||
4. Database connection and transaction handling
|
||||
5. Data validation and integrity patterns
|
||||
|
||||
Output: Data layer context with implementation patterns"
|
||||
```
|
||||
|
||||
## 并行上下文获取
|
||||
|
||||
### 多层并行分析
|
||||
```bash
|
||||
# 按架构层级并行获取上下文
|
||||
(
|
||||
cd src/frontend && gemini --all-files -p "@{CLAUDE.md} Frontend layer context analysis" &
|
||||
cd src/backend && gemini --all-files -p "@{CLAUDE.md} Backend layer context analysis" &
|
||||
cd src/database && gemini --all-files -p "@{CLAUDE.md} Data layer context analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 跨领域并行分析
|
||||
```bash
|
||||
# 按功能领域并行获取上下文
|
||||
(
|
||||
gemini -p "@{**/*auth*,**/*login*} @{CLAUDE.md} Authentication context" &
|
||||
gemini -p "@{**/api/**/*,**/routes/**/*} @{CLAUDE.md} API endpoint context" &
|
||||
gemini -p "@{**/components/**/*,**/ui/**/*} @{CLAUDE.md} UI component context" &
|
||||
gemini -p "@{**/*.test.*,**/*.spec.*} @{CLAUDE.md} Testing strategy context" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
## 模板引入示例
|
||||
|
||||
### 使用提示词模板
|
||||
```bash
|
||||
# 基础模板引入
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt)"
|
||||
|
||||
# 组合多个模板
|
||||
gemini -p "@{src/**/*} $(cat <<'EOF'
|
||||
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/architecture.txt)
|
||||
|
||||
Additional focus:
|
||||
$(cat ~/.claude/workflows/cli-templates/prompts/analysis/quality.txt)
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
### 条件模板选择
|
||||
```bash
|
||||
# 基于项目特征动态选择模板
|
||||
if [ -f "package.json" ] && grep -q "react" package.json; then
|
||||
TEMPLATE="~/.claude/workflows/cli-templates/prompts/tech/react-component.txt"
|
||||
elif [ -f "requirements.txt" ]; then
|
||||
TEMPLATE="~/.claude/workflows/cli-templates/prompts/tech/python-api.txt"
|
||||
else
|
||||
TEMPLATE="~/.claude/workflows/cli-templates/prompts/analysis/pattern.txt"
|
||||
fi
|
||||
|
||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat $TEMPLATE)"
|
||||
```
|
||||
|
||||
## 错误处理和回退
|
||||
|
||||
### 带回退的上下文获取
|
||||
```bash
|
||||
# 智能回退策略
|
||||
get_context_with_fallback() {
|
||||
local target_dir="$1"
|
||||
local analysis_type="${2:-general}"
|
||||
|
||||
# 策略 1: 目录导航 + --all-files
|
||||
if cd "$target_dir" 2>/dev/null; then
|
||||
echo "Using directory navigation approach..."
|
||||
if gemini --all-files -p "@{CLAUDE.md} $analysis_type context analysis"; then
|
||||
cd - > /dev/null
|
||||
return 0
|
||||
fi
|
||||
cd - > /dev/null
|
||||
fi
|
||||
|
||||
# 策略 2: 文件模式匹配
|
||||
echo "Fallback to pattern matching..."
|
||||
if gemini -p "@{$target_dir/**/*} @{CLAUDE.md} $analysis_type context analysis"; then
|
||||
return 0
|
||||
fi
|
||||
|
||||
# 策略 3: 最简单的通用模式
|
||||
echo "Using generic fallback..."
|
||||
gemini -p "@{**/*} @{CLAUDE.md} $analysis_type context analysis"
|
||||
}
|
||||
|
||||
# 使用示例
|
||||
get_context_with_fallback "src/components" "component"
|
||||
```
|
||||
|
||||
### 资源感知执行
|
||||
```bash
|
||||
# 检测系统资源并调整执行策略
|
||||
smart_context_analysis() {
|
||||
local estimated_files
|
||||
estimated_files=$(find . -type f -name "*.js" -o -name "*.ts" -o -name "*.jsx" -o -name "*.tsx" | wc -l)
|
||||
|
||||
if [ "$estimated_files" -gt 1000 ]; then
|
||||
echo "Large codebase detected ($estimated_files files). Using focused analysis..."
|
||||
|
||||
# 分块执行
|
||||
gemini -p "@{src/components/**/*.{jsx,tsx}} @{CLAUDE.md} Component patterns" &
|
||||
gemini -p "@{src/services/**/*.{js,ts}} @{CLAUDE.md} Service patterns" &
|
||||
gemini -p "@{src/utils/**/*.{js,ts}} @{CLAUDE.md} Utility patterns" &
|
||||
wait
|
||||
else
|
||||
echo "Standard analysis for manageable codebase..."
|
||||
cd /project/root && gemini --all-files -p "@{CLAUDE.md} Comprehensive context analysis"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
## 结果处理和整合
|
||||
|
||||
### 上下文结果解析
|
||||
```bash
|
||||
# 解析并结构化上下文结果
|
||||
parse_context_results() {
|
||||
local results_file="$1"
|
||||
|
||||
echo "## Context Analysis Summary"
|
||||
echo "Generated: $(date)"
|
||||
echo ""
|
||||
|
||||
# 提取关键模式
|
||||
echo "### Key Patterns Found:"
|
||||
grep -E "Pattern:|pattern:" "$results_file" | sed 's/^/- /'
|
||||
echo ""
|
||||
|
||||
# 提取工具和库
|
||||
echo "### Available Utilities:"
|
||||
grep -E "Utility:|utility:|Library:|library:" "$results_file" | sed 's/^/- /'
|
||||
echo ""
|
||||
|
||||
# 提取集成点
|
||||
echo "### Integration Points:"
|
||||
grep -E "Integration:|integration:|API:|api:" "$results_file" | sed 's/^/- /'
|
||||
echo ""
|
||||
}
|
||||
```
|
||||
|
||||
### 上下文缓存
|
||||
```bash
|
||||
# 缓存上下文结果以供复用
|
||||
cache_context_results() {
|
||||
local project_signature="$(pwd | md5sum | cut -d' ' -f1)"
|
||||
local cache_dir="~/.cache/gemini-context"
|
||||
local cache_file="$cache_dir/$project_signature.context"
|
||||
|
||||
mkdir -p "$cache_dir"
|
||||
|
||||
echo "# Context Cache - $(date)" > "$cache_file"
|
||||
echo "# Project: $(pwd)" >> "$cache_file"
|
||||
echo "" >> "$cache_file"
|
||||
|
||||
# 保存上下文结果
|
||||
cat >> "$cache_file"
|
||||
}
|
||||
```
|
||||
|
||||
## 性能优化示例
|
||||
|
||||
### 内存优化执行
|
||||
```bash
|
||||
# 内存感知的上下文获取
|
||||
memory_optimized_context() {
|
||||
local available_memory
|
||||
|
||||
# Linux 系统内存检测
|
||||
if command -v free >/dev/null 2>&1; then
|
||||
available_memory=$(free -m | awk 'NR==2{print $7}')
|
||||
|
||||
if [ "$available_memory" -lt 1000 ]; then
|
||||
echo "Low memory mode: Using selective patterns"
|
||||
|
||||
# 仅分析关键文件
|
||||
gemini -p "@{src/**/*.{js,ts,jsx,tsx}} @{CLAUDE.md} Core patterns only" --timeout=30
|
||||
else
|
||||
echo "Standard memory mode: Full analysis"
|
||||
cd /project/root && gemini --all-files -p "@{CLAUDE.md} Complete context analysis"
|
||||
fi
|
||||
else
|
||||
echo "Memory detection unavailable, using standard mode"
|
||||
cd /project/root && gemini --all-files -p "@{CLAUDE.md} Standard context analysis"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
这些命令模板提供了完整的、可直接执行的上下文获取示例，涵盖了各种项目类型、规模和复杂度的情况。
|
||||
410
.claude/workflows/cli-templates/commands/folder-analysis.md
Normal file
410
.claude/workflows/cli-templates/commands/folder-analysis.md
Normal file
@@ -0,0 +1,410 @@
|
||||
# Folder-Specific Analysis Command Templates
|
||||
|
||||
**针对特定文件夹的完整分析命令示例**
|
||||
|
||||
## 组件文件夹分析
|
||||
|
||||
### React 组件分析
|
||||
```bash
|
||||
# 标准 React 组件目录分析
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
React components architecture analysis:
|
||||
1. Component composition patterns and prop design
|
||||
2. State management strategies (local state vs context vs external)
|
||||
3. Styling approaches and CSS-in-JS usage patterns
|
||||
4. Testing strategies and component coverage
|
||||
5. Performance optimization patterns (memoization, lazy loading)
|
||||
|
||||
Output: Component development guidelines with specific patterns and best practices"
|
||||
|
||||
# 带回退的组件分析
|
||||
analyze_components() {
|
||||
if [ -d "src/components" ]; then
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md} Component analysis"
|
||||
elif [ -d "components" ]; then
|
||||
cd components && gemini --all-files -p "@{CLAUDE.md} Component analysis"
|
||||
else
|
||||
gemini -p "@{**/components/**/*,**/ui/**/*} @{CLAUDE.md} Component analysis"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
### Vue 组件分析
|
||||
```bash
|
||||
# Vue 单文件组件分析
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Vue component architecture analysis:
|
||||
1. Single File Component structure and organization
|
||||
2. Composition API vs Options API usage patterns
|
||||
3. Props, emits, and component communication patterns
|
||||
4. Scoped styling and CSS module usage
|
||||
5. Component testing with Vue Test Utils patterns
|
||||
|
||||
Focus on Vue 3 composition patterns and modern development practices."
|
||||
```
|
||||
|
||||
## API 文件夹分析
|
||||
|
||||
### RESTful API 分析
|
||||
```bash
|
||||
# API 路由和控制器分析
|
||||
cd src/api && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
RESTful API architecture analysis:
|
||||
1. Route organization and endpoint design patterns
|
||||
2. Controller structure and request handling patterns
|
||||
3. Middleware usage for authentication, validation, and error handling
|
||||
4. Response formatting and error handling strategies
|
||||
5. API versioning and backward compatibility approaches
|
||||
|
||||
Output: API development guidelines with routing patterns and best practices"
|
||||
|
||||
# Express.js 特定分析
|
||||
cd routes && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Express.js routing patterns analysis:
|
||||
1. Route definition and organization strategies
|
||||
2. Middleware chain design and error propagation
|
||||
3. Parameter validation and sanitization patterns
|
||||
4. Authentication and authorization middleware integration
|
||||
5. Response handling and status code conventions
|
||||
|
||||
Focus on Express.js specific patterns and Node.js best practices."
|
||||
```
|
||||
|
||||
### GraphQL API 分析
|
||||
```bash
|
||||
# GraphQL 解析器分析
|
||||
cd src/graphql && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
GraphQL API architecture analysis:
|
||||
1. Schema design and type definition patterns
|
||||
2. Resolver implementation and data fetching strategies
|
||||
3. Query complexity analysis and performance optimization
|
||||
4. Authentication and authorization in GraphQL context
|
||||
5. Error handling and custom scalar implementations
|
||||
|
||||
Focus on GraphQL-specific patterns and performance considerations."
|
||||
```
|
||||
|
||||
## 服务层分析
|
||||
|
||||
### 业务服务分析
|
||||
```bash
|
||||
# 服务层架构分析
|
||||
cd src/services && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Business services architecture analysis:
|
||||
1. Service layer organization and responsibility separation
|
||||
2. Domain logic implementation and business rule patterns
|
||||
3. External service integration and API communication
|
||||
4. Transaction management and data consistency patterns
|
||||
5. Service composition and orchestration strategies
|
||||
|
||||
Output: Service layer guidelines with business logic patterns and integration approaches"
|
||||
|
||||
# 微服务分析
|
||||
analyze_microservices() {
|
||||
local services=($(find services -maxdepth 1 -type d -not -name services))
|
||||
|
||||
for service in "${services[@]}"; do
|
||||
echo "Analyzing service: $service"
|
||||
cd "$service" && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Microservice analysis for $(basename $service):
|
||||
1. Service boundaries and responsibility definition
|
||||
2. Inter-service communication patterns
|
||||
3. Data persistence and consistency strategies
|
||||
4. Service configuration and environment management
|
||||
5. Monitoring and health check implementations
|
||||
|
||||
Focus on microservice-specific patterns and distributed system concerns."
|
||||
cd - > /dev/null
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
## 数据层分析
|
||||
|
||||
### 数据模型分析
|
||||
```bash
|
||||
# 数据库模型分析
|
||||
cd src/models && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Data model architecture analysis:
|
||||
1. Entity relationship design and database schema patterns
|
||||
2. ORM usage patterns and query optimization strategies
|
||||
3. Data validation and integrity constraint implementations
|
||||
4. Migration strategies and schema evolution patterns
|
||||
5. Database connection management and transaction handling
|
||||
|
||||
Output: Data modeling guidelines with ORM patterns and database best practices"
|
||||
|
||||
# Prisma 特定分析
|
||||
cd prisma && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Prisma ORM integration analysis:
|
||||
1. Schema definition and model relationship patterns
|
||||
2. Query patterns and performance optimization with Prisma
|
||||
3. Migration management and database versioning
|
||||
4. Type generation and client usage patterns
|
||||
5. Advanced features usage (middleware, custom types)
|
||||
|
||||
Focus on Prisma-specific patterns and TypeScript integration."
|
||||
```
|
||||
|
||||
### 数据访问层分析
|
||||
```bash
|
||||
# Repository 模式分析
|
||||
cd src/repositories && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Repository pattern implementation analysis:
|
||||
1. Repository interface design and abstraction patterns
|
||||
2. Data access optimization and caching strategies
|
||||
3. Query builder usage and dynamic query construction
|
||||
4. Transaction management across repository boundaries
|
||||
5. Testing strategies for data access layer
|
||||
|
||||
Focus on repository pattern best practices and data access optimization."
|
||||
```
|
||||
|
||||
## 工具和配置分析
|
||||
|
||||
### 构建配置分析
|
||||
```bash
|
||||
# 构建工具配置分析
|
||||
gemini -p "@{webpack.config.*,vite.config.*,rollup.config.*} @{CLAUDE.md}
|
||||
|
||||
Build configuration analysis:
|
||||
1. Build tool setup and optimization strategies
|
||||
2. Asset processing and bundling patterns
|
||||
3. Development vs production configuration differences
|
||||
4. Plugin configuration and custom build steps
|
||||
5. Performance optimization and bundle analysis
|
||||
|
||||
Focus on build optimization and development workflow improvements."
|
||||
|
||||
# package.json 和依赖分析
|
||||
gemini -p "@{package.json,package-lock.json,yarn.lock} @{CLAUDE.md}
|
||||
|
||||
Package management and dependency analysis:
|
||||
1. Dependency organization and version management strategies
|
||||
2. Script definitions and development workflow automation
|
||||
3. Peer dependency handling and version compatibility
|
||||
4. Security considerations and dependency auditing
|
||||
5. Package size optimization and tree-shaking opportunities
|
||||
|
||||
Output: Dependency management guidelines and optimization recommendations."
|
||||
```
|
||||
|
||||
### 测试目录分析
|
||||
```bash
|
||||
# 测试策略分析
|
||||
cd tests && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Testing strategy and implementation analysis:
|
||||
1. Test organization and structure patterns
|
||||
2. Unit testing approaches and coverage strategies
|
||||
3. Integration testing patterns and mock usage
|
||||
4. End-to-end testing implementation and tooling
|
||||
5. Test performance and maintainability considerations
|
||||
|
||||
Output: Testing guidelines with patterns for different testing levels"
|
||||
|
||||
# Jest 配置和测试模式
|
||||
cd __tests__ && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Jest testing patterns analysis:
|
||||
1. Test suite organization and naming conventions
|
||||
2. Mock strategies and dependency isolation
|
||||
3. Async testing patterns and promise handling
|
||||
4. Snapshot testing usage and maintenance
|
||||
5. Custom matchers and testing utilities
|
||||
|
||||
Focus on Jest-specific patterns and JavaScript/TypeScript testing best practices."
|
||||
```
|
||||
|
||||
## 样式和资源分析
|
||||
|
||||
### CSS 架构分析
|
||||
```bash
|
||||
# 样式架构分析
|
||||
cd src/styles && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
CSS architecture and styling patterns analysis:
|
||||
1. CSS organization methodologies (BEM, SMACSS, etc.)
|
||||
2. Preprocessor usage and mixin/variable patterns
|
||||
3. Component-scoped styling and CSS-in-JS approaches
|
||||
4. Responsive design patterns and breakpoint management
|
||||
5. Performance optimization and critical CSS strategies
|
||||
|
||||
Output: Styling guidelines with organization patterns and best practices"
|
||||
|
||||
# Tailwind CSS 分析
|
||||
gemini -p "@{tailwind.config.*,**/*.css} @{CLAUDE.md}
|
||||
|
||||
Tailwind CSS implementation analysis:
|
||||
1. Configuration customization and theme extension
|
||||
2. Utility class usage patterns and component composition
|
||||
3. Custom component creation with @apply directives
|
||||
4. Purging strategies and bundle size optimization
|
||||
5. Design system implementation with Tailwind
|
||||
|
||||
Focus on Tailwind-specific patterns and utility-first methodology."
|
||||
```
|
||||
|
||||
### 静态资源分析
|
||||
```bash
|
||||
# 资源管理分析
|
||||
cd src/assets && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Static asset management analysis:
|
||||
1. Asset organization and naming conventions
|
||||
2. Image optimization and format selection strategies
|
||||
3. Icon management and sprite generation patterns
|
||||
4. Font loading and performance optimization
|
||||
5. Asset versioning and cache management
|
||||
|
||||
Focus on performance optimization and asset delivery strategies."
|
||||
```
|
||||
|
||||
## 智能文件夹检测
|
||||
|
||||
### 自动文件夹检测和分析
|
||||
```bash
|
||||
# 智能检测项目结构并分析
|
||||
auto_folder_analysis() {
|
||||
echo "Detecting project structure..."
|
||||
|
||||
# 检测前端框架
|
||||
if [ -d "src/components" ]; then
|
||||
echo "Found React/Vue components directory"
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md} Component architecture analysis"
|
||||
cd - > /dev/null
|
||||
fi
|
||||
|
||||
# 检测API结构
|
||||
if [ -d "src/api" ] || [ -d "api" ] || [ -d "routes" ]; then
|
||||
echo "Found API directory structure"
|
||||
api_dir=$(find . -maxdepth 2 -name "api" -o -name "routes" | head -1)
|
||||
cd "$api_dir" && gemini --all-files -p "@{CLAUDE.md} API architecture analysis"
|
||||
cd - > /dev/null
|
||||
fi
|
||||
|
||||
# 检测服务层
|
||||
if [ -d "src/services" ] || [ -d "services" ]; then
|
||||
echo "Found services directory"
|
||||
service_dir=$(find . -maxdepth 2 -name "services" | head -1)
|
||||
cd "$service_dir" && gemini --all-files -p "@{CLAUDE.md} Service layer analysis"
|
||||
cd - > /dev/null
|
||||
fi
|
||||
|
||||
# 检测数据层
|
||||
if [ -d "src/models" ] || [ -d "models" ] || [ -d "src/db" ]; then
|
||||
echo "Found data layer directory"
|
||||
data_dir=$(find . -maxdepth 2 -name "models" -o -name "db" | head -1)
|
||||
cd "$data_dir" && gemini --all-files -p "@{CLAUDE.md} Data layer analysis"
|
||||
cd - > /dev/null
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
### 并行文件夹分析
|
||||
```bash
|
||||
# 多文件夹并行分析
|
||||
parallel_folder_analysis() {
|
||||
local folders=("$@")
|
||||
local pids=()
|
||||
|
||||
for folder in "${folders[@]}"; do
|
||||
if [ -d "$folder" ]; then
|
||||
(
|
||||
echo "Analyzing folder: $folder"
|
||||
cd "$folder" && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Folder-specific analysis for $folder:
|
||||
1. Directory organization and file structure patterns
|
||||
2. Code patterns and architectural decisions
|
||||
3. Integration points and external dependencies
|
||||
4. Testing strategies and quality standards
|
||||
5. Performance considerations and optimizations
|
||||
|
||||
Focus on folder-specific patterns and best practices."
|
||||
) &
|
||||
pids+=($!)
|
||||
fi
|
||||
done
|
||||
|
||||
# 等待所有分析完成
|
||||
for pid in "${pids[@]}"; do
|
||||
wait "$pid"
|
||||
done
|
||||
}
|
||||
|
||||
# 使用示例
|
||||
parallel_folder_analysis "src/components" "src/services" "src/api" "src/models"
|
||||
```
|
||||
|
||||
## 条件分析和优化
|
||||
|
||||
### 基于文件大小的分析策略
|
||||
```bash
|
||||
# 基于文件夹大小选择分析策略
|
||||
smart_folder_analysis() {
|
||||
local folder="$1"
|
||||
local file_count=$(find "$folder" -type f | wc -l)
|
||||
|
||||
echo "Analyzing folder: $folder ($file_count files)"
|
||||
|
||||
if [ "$file_count" -gt 100 ]; then
|
||||
echo "Large folder detected, using selective analysis"
|
||||
|
||||
# 大文件夹：按文件类型分组分析
|
||||
cd "$folder" && gemini -p "@{**/*.{js,ts,jsx,tsx}} @{CLAUDE.md} JavaScript/TypeScript patterns"
|
||||
cd "$folder" && gemini -p "@{**/*.{css,scss,sass}} @{CLAUDE.md} Styling patterns"
|
||||
cd "$folder" && gemini -p "@{**/*.{json,yaml,yml}} @{CLAUDE.md} Configuration patterns"
|
||||
elif [ "$file_count" -gt 20 ]; then
|
||||
echo "Medium folder, using standard analysis"
|
||||
cd "$folder" && gemini --all-files -p "@{CLAUDE.md} Comprehensive folder analysis"
|
||||
else
|
||||
echo "Small folder, using detailed analysis"
|
||||
cd "$folder" && gemini --all-files -p "@{CLAUDE.md} Detailed patterns and implementation analysis"
|
||||
fi
|
||||
|
||||
cd - > /dev/null
|
||||
}
|
||||
```
|
||||
|
||||
### 增量分析策略
|
||||
```bash
|
||||
# 仅分析修改过的文件夹
|
||||
incremental_folder_analysis() {
|
||||
local base_commit="${1:-HEAD~1}"
|
||||
|
||||
echo "Finding modified folders since $base_commit"
|
||||
|
||||
# 获取修改的文件夹
|
||||
local modified_folders=($(git diff --name-only "$base_commit" | xargs -I {} dirname {} | sort -u))
|
||||
|
||||
for folder in "${modified_folders[@]}"; do
|
||||
if [ -d "$folder" ]; then
|
||||
echo "Analyzing modified folder: $folder"
|
||||
cd "$folder" && gemini --all-files -p "@{CLAUDE.md}
|
||||
|
||||
Incremental analysis for recently modified folder:
|
||||
1. Recent changes impact on existing patterns
|
||||
2. New patterns introduced and their consistency
|
||||
3. Integration effects on related components
|
||||
4. Testing coverage for modified functionality
|
||||
5. Performance implications of recent changes
|
||||
|
||||
Focus on change impact and pattern evolution."
|
||||
cd - > /dev/null
|
||||
fi
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
这些文件夹特定的分析模板为不同类型的项目目录提供了专门的分析策略，从组件库到API层，从数据模型到配置管理，确保每种目录类型都能得到最适合的分析方式。
|
||||
390
.claude/workflows/cli-templates/commands/parallel-execution.md
Normal file
390
.claude/workflows/cli-templates/commands/parallel-execution.md
Normal file
@@ -0,0 +1,390 @@
|
||||
# Parallel Execution Command Templates
|
||||
|
||||
**并行执行模式的完整命令示例**
|
||||
|
||||
## 基础并行执行模式
|
||||
|
||||
### 标准并行结构
|
||||
```bash
|
||||
# 基本并行执行模板
|
||||
(
|
||||
command1 &
|
||||
command2 &
|
||||
command3 &
|
||||
wait # 等待所有并行进程完成
|
||||
)
|
||||
```
|
||||
|
||||
### 资源限制并行执行
|
||||
```bash
|
||||
# 限制并行进程数量
|
||||
MAX_PARALLEL=3
|
||||
parallel_count=0
|
||||
|
||||
for cmd in "${commands[@]}"; do
|
||||
eval "$cmd" &
|
||||
((parallel_count++))
|
||||
|
||||
# 达到并发限制时等待
|
||||
if ((parallel_count >= MAX_PARALLEL)); then
|
||||
wait
|
||||
parallel_count=0
|
||||
fi
|
||||
done
|
||||
|
||||
wait # 等待剩余进程
|
||||
```
|
||||
|
||||
## 按架构层级并行
|
||||
|
||||
### 前后端分离并行
|
||||
```bash
|
||||
# 前后端架构并行分析
|
||||
(
|
||||
cd src/frontend && gemini --all-files -p "@{CLAUDE.md} Frontend architecture and patterns analysis" &
|
||||
cd src/backend && gemini --all-files -p "@{CLAUDE.md} Backend services and API patterns analysis" &
|
||||
cd src/shared && gemini --all-files -p "@{CLAUDE.md} Shared utilities and common patterns analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 三层架构并行
|
||||
```bash
|
||||
# 表示层、业务层、数据层并行分析
|
||||
(
|
||||
gemini -p "@{src/views/**/*,src/components/**/*} @{CLAUDE.md} Presentation layer analysis" &
|
||||
gemini -p "@{src/services/**/*,src/business/**/*} @{CLAUDE.md} Business logic layer analysis" &
|
||||
gemini -p "@{src/models/**/*,src/db/**/*} @{CLAUDE.md} Data access layer analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 微服务架构并行
|
||||
```bash
|
||||
# 微服务并行分析
|
||||
(
|
||||
cd services/user-service && gemini --all-files -p "@{CLAUDE.md} User service patterns and architecture" &
|
||||
cd services/order-service && gemini --all-files -p "@{CLAUDE.md} Order service patterns and architecture" &
|
||||
cd services/payment-service && gemini --all-files -p "@{CLAUDE.md} Payment service patterns and architecture" &
|
||||
cd services/notification-service && gemini --all-files -p "@{CLAUDE.md} Notification service patterns and architecture" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
## 按功能领域并行
|
||||
|
||||
### 核心功能并行分析
|
||||
```bash
|
||||
# 核心业务功能并行分析
|
||||
(
|
||||
gemini -p "@{**/*auth*,**/*login*,**/*session*} @{CLAUDE.md} Authentication and session management analysis" &
|
||||
gemini -p "@{**/api/**/*,**/routes/**/*,**/controllers/**/*} @{CLAUDE.md} API endpoints and routing analysis" &
|
||||
gemini -p "@{**/components/**/*,**/ui/**/*,**/views/**/*} @{CLAUDE.md} UI components and interface analysis" &
|
||||
gemini -p "@{**/models/**/*,**/entities/**/*,**/schemas/**/*} @{CLAUDE.md} Data models and schema analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 跨切面关注点并行
|
||||
```bash
|
||||
# 横切关注点并行分析
|
||||
(
|
||||
gemini -p "@{**/*security*,**/*crypto*,**/*auth*} @{CLAUDE.md} Security and encryption patterns analysis" &
|
||||
gemini -p "@{**/*log*,**/*monitor*,**/*track*} @{CLAUDE.md} Logging and monitoring patterns analysis" &
|
||||
gemini -p "@{**/*cache*,**/*redis*,**/*memory*} @{CLAUDE.md} Caching and performance patterns analysis" &
|
||||
gemini -p "@{**/*test*,**/*spec*,**/*mock*} @{CLAUDE.md} Testing strategies and patterns analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
## 按技术栈并行
|
||||
|
||||
### 全栈技术并行分析
|
||||
```bash
|
||||
# 多技术栈并行分析
|
||||
(
|
||||
gemini -p "@{**/*.{js,jsx,ts,tsx}} @{CLAUDE.md} JavaScript/TypeScript patterns and usage analysis" &
|
||||
gemini -p "@{**/*.{css,scss,sass,less}} @{CLAUDE.md} Styling patterns and CSS architecture analysis" &
|
||||
gemini -p "@{**/*.{py,pyx}} @{CLAUDE.md} Python code patterns and implementation analysis" &
|
||||
gemini -p "@{**/*.{sql,migration}} @{CLAUDE.md} Database schema and migration patterns analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 框架特定并行分析
|
||||
```bash
|
||||
# React 生态系统并行分析
|
||||
(
|
||||
gemini -p "@{src/components/**/*.{jsx,tsx}} @{CLAUDE.md} React component patterns and composition analysis" &
|
||||
gemini -p "@{src/hooks/**/*.{js,ts}} @{CLAUDE.md} Custom hooks patterns and usage analysis" &
|
||||
gemini -p "@{src/context/**/*.{js,ts,jsx,tsx}} @{CLAUDE.md} Context API usage and state management analysis" &
|
||||
gemini -p "@{**/*.stories.{js,jsx,ts,tsx}} @{CLAUDE.md} Storybook stories and component documentation analysis" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
## 按项目规模并行
|
||||
|
||||
### 大型项目分块并行
|
||||
```bash
|
||||
# 大型项目按模块并行分析
|
||||
analyze_large_project() {
|
||||
local modules=("auth" "user" "product" "order" "payment" "notification")
|
||||
local pids=()
|
||||
|
||||
for module in "${modules[@]}"; do
|
||||
(
|
||||
echo "Analyzing module: $module"
|
||||
gemini -p "@{src/$module/**/*,lib/$module/**/*} @{CLAUDE.md}
|
||||
|
||||
Module-specific analysis for $module:
|
||||
1. Module architecture and organization patterns
|
||||
2. Internal API and interface definitions
|
||||
3. Integration points with other modules
|
||||
4. Testing strategies and coverage
|
||||
5. Performance considerations and optimizations
|
||||
|
||||
Focus on module-specific patterns and integration points."
|
||||
) &
|
||||
pids+=($!)
|
||||
|
||||
# 控制并行数量
|
||||
if [ ${#pids[@]} -ge 3 ]; then
|
||||
wait "${pids[0]}"
|
||||
pids=("${pids[@]:1}") # 移除已完成的进程ID
|
||||
fi
|
||||
done
|
||||
|
||||
# 等待所有剩余进程
|
||||
for pid in "${pids[@]}"; do
|
||||
wait "$pid"
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
### 企业级项目并行策略
|
||||
```bash
|
||||
# 企业级项目分层并行分析
|
||||
enterprise_parallel_analysis() {
|
||||
# 第一层：核心架构分析
|
||||
echo "Phase 1: Core Architecture Analysis"
|
||||
(
|
||||
gemini -p "@{src/core/**/*,lib/core/**/*} @{CLAUDE.md} Core architecture and foundation patterns" &
|
||||
gemini -p "@{config/**/*,*.config.*} @{CLAUDE.md} Configuration management and environment setup" &
|
||||
gemini -p "@{docs/**/*,README*,CHANGELOG*} @{CLAUDE.md} Documentation structure and project information" &
|
||||
wait
|
||||
)
|
||||
|
||||
# 第二层：业务模块分析
|
||||
echo "Phase 2: Business Module Analysis"
|
||||
(
|
||||
gemini -p "@{src/modules/**/*} @{CLAUDE.md} Business modules and domain logic analysis" &
|
||||
gemini -p "@{src/services/**/*} @{CLAUDE.md} Service layer and business services analysis" &
|
||||
gemini -p "@{src/repositories/**/*} @{CLAUDE.md} Data access and repository patterns analysis" &
|
||||
wait
|
||||
)
|
||||
|
||||
# 第三层：基础设施分析
|
||||
echo "Phase 3: Infrastructure Analysis"
|
||||
(
|
||||
gemini -p "@{infrastructure/**/*,deploy/**/*} @{CLAUDE.md} Infrastructure and deployment patterns" &
|
||||
gemini -p "@{scripts/**/*,tools/**/*} @{CLAUDE.md} Build scripts and development tools analysis" &
|
||||
gemini -p "@{tests/**/*,**/*.test.*} @{CLAUDE.md} Testing infrastructure and strategies analysis" &
|
||||
wait
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
## 智能并行调度
|
||||
|
||||
### 依赖感知并行执行
|
||||
```bash
|
||||
# 基于依赖关系的智能并行调度
|
||||
dependency_aware_parallel() {
|
||||
local -A dependencies=(
|
||||
["core"]=""
|
||||
["utils"]="core"
|
||||
["services"]="core,utils"
|
||||
["api"]="services"
|
||||
["ui"]="services"
|
||||
["tests"]="api,ui"
|
||||
)
|
||||
|
||||
local -A completed=()
|
||||
local -A running=()
|
||||
|
||||
while [ ${#completed[@]} -lt ${#dependencies[@]} ]; do
|
||||
for module in "${!dependencies[@]}"; do
|
||||
# 跳过已完成或正在运行的模块
|
||||
[[ ${completed[$module]} ]] && continue
|
||||
[[ ${running[$module]} ]] && continue
|
||||
|
||||
# 检查依赖是否已完成
|
||||
local deps="${dependencies[$module]}"
|
||||
local can_start=true
|
||||
|
||||
if [[ -n "$deps" ]]; then
|
||||
IFS=',' read -ra dep_array <<< "$deps"
|
||||
for dep in "${dep_array[@]}"; do
|
||||
[[ ! ${completed[$dep]} ]] && can_start=false && break
|
||||
done
|
||||
fi
|
||||
|
||||
# 启动模块分析
|
||||
if $can_start; then
|
||||
echo "Starting analysis for module: $module"
|
||||
(
|
||||
gemini -p "@{src/$module/**/*} @{CLAUDE.md} Module $module analysis"
|
||||
echo "completed:$module"
|
||||
) &
|
||||
running[$module]=$!
|
||||
fi
|
||||
done
|
||||
|
||||
# 检查完成的进程
|
||||
for module in "${!running[@]}"; do
|
||||
if ! kill -0 "${running[$module]}" 2>/dev/null; then
|
||||
completed[$module]=true
|
||||
unset running[$module]
|
||||
echo "Module $module analysis completed"
|
||||
fi
|
||||
done
|
||||
|
||||
sleep 1
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
### 资源自适应并行
|
||||
```bash
|
||||
# 基于系统资源的自适应并行
|
||||
adaptive_parallel_execution() {
|
||||
local available_memory=$(free -m 2>/dev/null | awk 'NR==2{print $7}' || echo 4000)
|
||||
local cpu_cores=$(nproc 2>/dev/null || echo 4)
|
||||
|
||||
# 根据资源计算最优并行数
|
||||
local max_parallel
|
||||
if [ "$available_memory" -lt 2000 ]; then
|
||||
max_parallel=2
|
||||
elif [ "$available_memory" -lt 4000 ]; then
|
||||
max_parallel=3
|
||||
else
|
||||
max_parallel=$((cpu_cores > 4 ? 4 : cpu_cores))
|
||||
fi
|
||||
|
||||
echo "Adaptive parallel execution: $max_parallel concurrent processes"
|
||||
|
||||
local commands=(
|
||||
"gemini -p '@{src/components/**/*} @{CLAUDE.md} Component analysis'"
|
||||
"gemini -p '@{src/services/**/*} @{CLAUDE.md} Service analysis'"
|
||||
"gemini -p '@{src/utils/**/*} @{CLAUDE.md} Utility analysis'"
|
||||
"gemini -p '@{src/api/**/*} @{CLAUDE.md} API analysis'"
|
||||
"gemini -p '@{src/models/**/*} @{CLAUDE.md} Model analysis'"
|
||||
)
|
||||
|
||||
local active_jobs=0
|
||||
for cmd in "${commands[@]}"; do
|
||||
eval "$cmd" &
|
||||
((active_jobs++))
|
||||
|
||||
# 达到并行限制时等待
|
||||
if [ $active_jobs -ge $max_parallel ]; then
|
||||
wait
|
||||
active_jobs=0
|
||||
fi
|
||||
done
|
||||
|
||||
wait # 等待所有剩余任务完成
|
||||
}
|
||||
```
|
||||
|
||||
## 错误处理和监控
|
||||
|
||||
### 并行执行错误处理
|
||||
```bash
|
||||
# 带错误处理的并行执行
|
||||
robust_parallel_execution() {
|
||||
local commands=("$@")
|
||||
local pids=()
|
||||
local results=()
|
||||
|
||||
# 启动所有并行任务
|
||||
for i in "${!commands[@]}"; do
|
||||
(
|
||||
echo "Starting task $i: ${commands[$i]}"
|
||||
if eval "${commands[$i]}"; then
|
||||
echo "SUCCESS:$i"
|
||||
else
|
||||
echo "FAILED:$i"
|
||||
fi
|
||||
) &
|
||||
pids+=($!)
|
||||
done
|
||||
|
||||
# 等待所有任务完成并收集结果
|
||||
for i in "${!pids[@]}"; do
|
||||
if wait "${pids[$i]}"; then
|
||||
results+=("Task $i: SUCCESS")
|
||||
else
|
||||
results+=("Task $i: FAILED")
|
||||
echo "Task $i failed, attempting retry..."
|
||||
|
||||
# 简单重试机制
|
||||
if eval "${commands[$i]}"; then
|
||||
results[-1]="Task $i: SUCCESS (retry)"
|
||||
else
|
||||
results[-1]="Task $i: FAILED (retry failed)"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
|
||||
# 输出执行结果摘要
|
||||
echo "Parallel execution summary:"
|
||||
for result in "${results[@]}"; do
|
||||
echo " $result"
|
||||
done
|
||||
}
|
||||
```
|
||||
|
||||
### 实时进度监控
|
||||
```bash
|
||||
# 带进度监控的并行执行
|
||||
monitored_parallel_execution() {
|
||||
local total_tasks=$#
|
||||
local completed_tasks=0
|
||||
local failed_tasks=0
|
||||
|
||||
echo "Starting $total_tasks parallel tasks..."
|
||||
|
||||
for cmd in "$@"; do
|
||||
(
|
||||
if eval "$cmd"; then
|
||||
echo "COMPLETED:$(date): $cmd"
|
||||
else
|
||||
echo "FAILED:$(date): $cmd"
|
||||
fi
|
||||
) &
|
||||
done
|
||||
|
||||
# 监控进度
|
||||
while [ $completed_tasks -lt $total_tasks ]; do
|
||||
sleep 5
|
||||
|
||||
# 计算当前完成数量
|
||||
local current_completed=$(jobs -r | wc -l)
|
||||
local current_failed=$((total_tasks - current_completed - $(jobs -s | wc -l)))
|
||||
|
||||
if [ $current_completed -ne $completed_tasks ] || [ $current_failed -ne $failed_tasks ]; then
|
||||
completed_tasks=$current_completed
|
||||
failed_tasks=$current_failed
|
||||
|
||||
echo "Progress: Completed: $completed_tasks, Failed: $failed_tasks, Remaining: $((total_tasks - completed_tasks - failed_tasks))"
|
||||
fi
|
||||
done
|
||||
|
||||
wait
|
||||
echo "All parallel tasks completed."
|
||||
}
|
||||
```
|
||||
|
||||
这些并行执行模板提供了各种场景下的并行分析策略，从简单的并行执行到复杂的依赖感知调度和资源自适应执行。
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze system architecture and design decisions:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify main architectural patterns and design principles
|
||||
2. Map module dependencies and component relationships
|
||||
3. Assess integration points and data flow patterns
|
||||
4. Evaluate scalability and maintainability aspects
|
||||
5. Document architectural trade-offs and design decisions
|
||||
|
||||
## Output Requirements:
|
||||
- Architectural diagrams or textual descriptions
|
||||
- Dependency mapping with specific file references
|
||||
- Integration point documentation with examples
|
||||
- Scalability assessment and bottleneck identification
|
||||
|
||||
Focus on high-level design patterns and system-wide architectural concerns.
|
||||
16
.claude/workflows/cli-templates/prompts/analysis/pattern.txt
Normal file
16
.claude/workflows/cli-templates/prompts/analysis/pattern.txt
Normal file
@@ -0,0 +1,16 @@
|
||||
Analyze implementation patterns and code structure:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify common code patterns and architectural decisions
|
||||
2. Extract reusable utilities and shared components
|
||||
3. Document existing conventions and coding standards
|
||||
4. Assess pattern consistency and identify anti-patterns
|
||||
5. Suggest improvements and optimization opportunities
|
||||
|
||||
## Output Requirements:
|
||||
- Specific file:line references for all findings
|
||||
- Code snippets demonstrating identified patterns
|
||||
- Clear recommendations for pattern improvements
|
||||
- Standards compliance assessment
|
||||
|
||||
Focus on actionable insights and concrete implementation guidance.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze performance characteristics and optimization opportunities:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify performance bottlenecks and resource usage patterns
|
||||
2. Assess algorithm efficiency and data structure choices
|
||||
3. Evaluate caching strategies and optimization techniques
|
||||
4. Review memory management and resource cleanup
|
||||
5. Document performance metrics and improvement opportunities
|
||||
|
||||
## Output Requirements:
|
||||
- Performance bottleneck identification with specific locations
|
||||
- Algorithm complexity analysis and optimization suggestions
|
||||
- Caching pattern documentation and recommendations
|
||||
- Memory usage patterns and optimization opportunities
|
||||
|
||||
Focus on measurable performance improvements and concrete optimization strategies.
|
||||
16
.claude/workflows/cli-templates/prompts/analysis/quality.txt
Normal file
16
.claude/workflows/cli-templates/prompts/analysis/quality.txt
Normal file
@@ -0,0 +1,16 @@
|
||||
Analyze code quality and maintainability aspects:
|
||||
|
||||
## Required Analysis:
|
||||
1. Assess code organization and structural quality
|
||||
2. Evaluate naming conventions and readability standards
|
||||
3. Review error handling and logging practices
|
||||
4. Analyze test coverage and testing strategies
|
||||
5. Document technical debt and improvement priorities
|
||||
|
||||
## Output Requirements:
|
||||
- Code quality metrics and specific improvement areas
|
||||
- Naming convention consistency analysis
|
||||
- Error handling pattern documentation
|
||||
- Test coverage assessment with gap identification
|
||||
|
||||
Focus on maintainability improvements and long-term code health.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze security implementation and potential vulnerabilities:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify authentication and authorization mechanisms
|
||||
2. Assess input validation and sanitization practices
|
||||
3. Review data encryption and secure storage methods
|
||||
4. Evaluate API security and access control patterns
|
||||
5. Document security risks and compliance considerations
|
||||
|
||||
## Output Requirements:
|
||||
- Security vulnerability findings with file:line references
|
||||
- Authentication/authorization pattern documentation
|
||||
- Input validation examples and gaps
|
||||
- Encryption usage patterns and recommendations
|
||||
|
||||
Focus on identifying security gaps and providing actionable remediation steps.
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with creating a reusable component in this codebase. Follow these guidelines:
|
||||
|
||||
## Design Phase:
|
||||
1. Analyze existing component patterns and structures
|
||||
2. Identify reusable design principles and styling approaches
|
||||
3. Review component hierarchy and prop patterns
|
||||
4. Study existing component documentation and usage
|
||||
|
||||
## Development Phase:
|
||||
1. Create component with proper TypeScript interfaces
|
||||
2. Implement following established naming conventions
|
||||
3. Add appropriate default props and validation
|
||||
4. Include comprehensive prop documentation
|
||||
|
||||
## Styling Phase:
|
||||
1. Follow existing styling methodology (CSS modules, styled-components, etc.)
|
||||
2. Ensure responsive design principles
|
||||
3. Add proper theming support if applicable
|
||||
4. Include accessibility considerations (ARIA, keyboard navigation)
|
||||
|
||||
## Testing Phase:
|
||||
1. Write component tests covering all props and states
|
||||
2. Test accessibility compliance
|
||||
3. Add visual regression tests if applicable
|
||||
4. Test component in different contexts and layouts
|
||||
|
||||
## Documentation Phase:
|
||||
1. Create usage examples and code snippets
|
||||
2. Document all props and their purposes
|
||||
3. Include accessibility guidelines
|
||||
4. Add integration examples with other components
|
||||
|
||||
## Output Requirements:
|
||||
- Provide complete component implementation
|
||||
- Include comprehensive TypeScript types
|
||||
- Show usage examples and integration patterns
|
||||
- Document component API and best practices
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with debugging and resolving issues in this codebase. Follow these systematic guidelines:
|
||||
|
||||
## Issue Analysis Phase:
|
||||
1. Identify and reproduce the reported issue
|
||||
2. Analyze error logs and stack traces
|
||||
3. Study code flow and identify potential failure points
|
||||
4. Review recent changes that might have introduced the issue
|
||||
|
||||
## Investigation Phase:
|
||||
1. Add strategic logging and debugging statements
|
||||
2. Use debugging tools and profilers as appropriate
|
||||
3. Test with different input conditions and edge cases
|
||||
4. Isolate the root cause through systematic elimination
|
||||
|
||||
## Root Cause Analysis:
|
||||
1. Document the exact cause of the issue
|
||||
2. Identify contributing factors and conditions
|
||||
3. Assess impact scope and affected functionality
|
||||
4. Determine if similar issues exist elsewhere
|
||||
|
||||
## Resolution Phase:
|
||||
1. Implement minimal, targeted fix for the root cause
|
||||
2. Ensure fix doesn't introduce new issues or regressions
|
||||
3. Add proper error handling and validation
|
||||
4. Include defensive programming measures
|
||||
|
||||
## Prevention Phase:
|
||||
1. Add tests to prevent regression of this issue
|
||||
2. Improve error messages and logging
|
||||
3. Add monitoring or alerts for early detection
|
||||
4. Document lessons learned and prevention strategies
|
||||
|
||||
## Output Requirements:
|
||||
- Provide detailed root cause analysis
|
||||
- Show exact code changes made to resolve the issue
|
||||
- Include new tests added to prevent regression
|
||||
- Document debugging process and lessons learned
|
||||
@@ -0,0 +1,31 @@
|
||||
You are tasked with implementing a new feature in this codebase. Follow these guidelines:
|
||||
|
||||
## Analysis Phase:
|
||||
1. Study existing code patterns and conventions
|
||||
2. Identify similar features and their implementation approaches
|
||||
3. Review project architecture and design principles
|
||||
4. Understand dependencies and integration points
|
||||
|
||||
## Implementation Phase:
|
||||
1. Create feature following established patterns
|
||||
2. Implement with proper error handling and validation
|
||||
3. Add comprehensive logging for debugging
|
||||
4. Follow security best practices
|
||||
|
||||
## Integration Phase:
|
||||
1. Ensure seamless integration with existing systems
|
||||
2. Update configuration files as needed
|
||||
3. Add proper TypeScript types and interfaces
|
||||
4. Update documentation and comments
|
||||
|
||||
## Testing Phase:
|
||||
1. Write unit tests covering edge cases
|
||||
2. Add integration tests for feature workflows
|
||||
3. Verify error scenarios are properly handled
|
||||
4. Test performance and security implications
|
||||
|
||||
## Output Requirements:
|
||||
- Provide file:line references for all changes
|
||||
- Include code examples demonstrating key patterns
|
||||
- Explain architectural decisions made
|
||||
- Document any new dependencies or configurations
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with refactoring existing code to improve quality, performance, or maintainability. Follow these guidelines:
|
||||
|
||||
## Analysis Phase:
|
||||
1. Identify code smells and technical debt
|
||||
2. Analyze performance bottlenecks and inefficiencies
|
||||
3. Review code complexity and maintainability metrics
|
||||
4. Study existing test coverage and identify gaps
|
||||
|
||||
## Planning Phase:
|
||||
1. Create refactoring strategy preserving existing functionality
|
||||
2. Identify breaking changes and migration paths
|
||||
3. Plan incremental refactoring steps
|
||||
4. Consider backward compatibility requirements
|
||||
|
||||
## Refactoring Phase:
|
||||
1. Apply SOLID principles and design patterns
|
||||
2. Improve code readability and documentation
|
||||
3. Optimize performance while maintaining functionality
|
||||
4. Reduce code duplication and improve reusability
|
||||
|
||||
## Validation Phase:
|
||||
1. Ensure all existing tests continue to pass
|
||||
2. Add new tests for improved code coverage
|
||||
3. Verify performance improvements with benchmarks
|
||||
4. Test edge cases and error scenarios
|
||||
|
||||
## Migration Phase:
|
||||
1. Update dependent code to use refactored interfaces
|
||||
2. Update documentation and usage examples
|
||||
3. Provide migration guides for breaking changes
|
||||
4. Add deprecation warnings for old interfaces
|
||||
|
||||
## Output Requirements:
|
||||
- Provide before/after code comparisons
|
||||
- Document performance improvements achieved
|
||||
- Include migration instructions for breaking changes
|
||||
- Show updated test coverage and quality metrics
|
||||
@@ -0,0 +1,43 @@
|
||||
You are tasked with creating comprehensive tests for this codebase. Follow these guidelines:
|
||||
|
||||
## Test Strategy Phase:
|
||||
1. Analyze existing test coverage and identify gaps
|
||||
2. Study codebase architecture and critical paths
|
||||
3. Identify edge cases and error scenarios
|
||||
4. Review testing frameworks and conventions used
|
||||
|
||||
## Unit Testing Phase:
|
||||
1. Write tests for individual functions and methods
|
||||
2. Test all branches and conditional logic
|
||||
3. Cover edge cases and boundary conditions
|
||||
4. Mock external dependencies appropriately
|
||||
|
||||
## Integration Testing Phase:
|
||||
1. Test interactions between components and modules
|
||||
2. Verify API endpoints and data flow
|
||||
3. Test database operations and transactions
|
||||
4. Validate external service integrations
|
||||
|
||||
## End-to-End Testing Phase:
|
||||
1. Test complete user workflows and scenarios
|
||||
2. Verify critical business logic and processes
|
||||
3. Test error handling and recovery mechanisms
|
||||
4. Validate performance under load
|
||||
|
||||
## Quality Assurance:
|
||||
1. Ensure tests are reliable and deterministic
|
||||
2. Make tests readable and maintainable
|
||||
3. Add proper test documentation and comments
|
||||
4. Follow testing best practices and conventions
|
||||
|
||||
## Test Data Management:
|
||||
1. Create realistic test data and fixtures
|
||||
2. Ensure test isolation and cleanup
|
||||
3. Use factories or builders for complex objects
|
||||
4. Handle sensitive data appropriately in tests
|
||||
|
||||
## Output Requirements:
|
||||
- Provide comprehensive test suite with high coverage
|
||||
- Include performance benchmarks where relevant
|
||||
- Document testing strategy and conventions used
|
||||
- Show test coverage metrics and quality improvements
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update root-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 1: Root Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Project Overview and Purpose**
|
||||
- High-level project description and mission
|
||||
- Target audience and use cases
|
||||
- Key value propositions
|
||||
|
||||
2. **Technology Stack Summary**
|
||||
- Primary programming languages and frameworks
|
||||
- Key dependencies and tools
|
||||
- Platform and runtime requirements
|
||||
|
||||
3. **Architecture Decisions and Principles**
|
||||
- Core architectural patterns used
|
||||
- Design principles governing the codebase
|
||||
- Major technical decisions and rationale
|
||||
|
||||
4. **Development Workflow Overview**
|
||||
- Build and deployment processes
|
||||
- Testing approach and quality standards
|
||||
- Contributing guidelines and processes
|
||||
|
||||
5. **Quick Start Guide**
|
||||
- Installation prerequisites
|
||||
- Setup instructions
|
||||
- Basic usage examples
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Implementation details (belongs in module-level docs)
|
||||
- Module-specific patterns (belongs in module-level docs)
|
||||
- Code examples from specific modules (belongs in module-level docs)
|
||||
- Domain internal architecture (belongs in domain-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Use high-level, strategic perspective
|
||||
- Focus on "what" and "why" rather than "how"
|
||||
- Reference other documentation layers rather than duplicating content
|
||||
- Maintain concise, executive-summary style
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Project Name] - Development Guidelines
|
||||
|
||||
## 1. Project Overview and Purpose
|
||||
[Brief project description, mission, and target audience]
|
||||
|
||||
## 2. Technology Stack Summary
|
||||
[Primary technologies, frameworks, and tools]
|
||||
|
||||
## 3. Architecture Decisions and Principles
|
||||
[Core architectural patterns and design principles]
|
||||
|
||||
## 4. Development Workflow Overview
|
||||
[Build, test, and deployment processes]
|
||||
|
||||
## 5. Quick Start Guide
|
||||
[Installation and basic usage]
|
||||
```
|
||||
|
||||
Remember: This is Layer 1 - stay at the strategic level and avoid diving into implementation details.
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update domain-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 2: Domain Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Domain Architecture and Responsibilities**
|
||||
- Domain's role within the larger system
|
||||
- Core responsibilities and boundaries
|
||||
- Key abstractions and concepts
|
||||
|
||||
2. **Module Organization Within Domain**
|
||||
- How modules are structured within this domain
|
||||
- Module relationships and hierarchies
|
||||
- Organizational patterns used
|
||||
|
||||
3. **Inter-Module Communication Patterns**
|
||||
- How modules within this domain communicate
|
||||
- Data flow patterns and interfaces
|
||||
- Shared resources and dependencies
|
||||
|
||||
4. **Domain-Specific Conventions**
|
||||
- Coding standards specific to this domain
|
||||
- Naming conventions and patterns
|
||||
- Testing approaches for this domain
|
||||
|
||||
5. **Integration Points with Other Domains**
|
||||
- External dependencies and interfaces
|
||||
- Cross-domain communication protocols
|
||||
- Shared contracts and data formats
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Duplicating root project overview (belongs in root-level docs)
|
||||
- Component/function-level details (belongs in module-level docs)
|
||||
- Specific implementation code (belongs in module-level docs)
|
||||
- Module internal patterns (belongs in module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on domain-wide patterns and organization
|
||||
- Explain relationships between modules within the domain
|
||||
- Describe domain boundaries and responsibilities
|
||||
- Reference module-level docs for implementation details
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Domain Name] - Domain Architecture
|
||||
|
||||
## 1. Domain Overview
|
||||
[Domain's role and core responsibilities]
|
||||
|
||||
## 2. Module Organization
|
||||
[How modules are structured within this domain]
|
||||
|
||||
## 3. Inter-Module Communication
|
||||
[Communication patterns and data flow]
|
||||
|
||||
## 4. Domain Conventions
|
||||
[Domain-specific standards and patterns]
|
||||
|
||||
## 5. External Integration
|
||||
[Integration with other domains and systems]
|
||||
```
|
||||
|
||||
Remember: This is Layer 2 - focus on domain-wide organization and avoid both high-level project details and low-level implementation specifics.
|
||||
@@ -0,0 +1,66 @@
|
||||
Create or update module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 3: Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Module-Specific Implementation Patterns**
|
||||
- Implementation patterns used within this module
|
||||
- Common coding approaches and idioms
|
||||
- Module-specific design patterns
|
||||
|
||||
2. **Internal Architecture and Design Decisions**
|
||||
- How the module is internally organized
|
||||
- Key design decisions and their rationale
|
||||
- Component relationships within the module
|
||||
|
||||
3. **API Contracts and Interfaces**
|
||||
- Public interfaces exposed by this module
|
||||
- Input/output contracts and data formats
|
||||
- Integration points with other modules
|
||||
|
||||
4. **Module Dependencies and Relationships**
|
||||
- Direct dependencies of this module
|
||||
- How this module fits into the larger system
|
||||
- Data flow in and out of the module
|
||||
|
||||
5. **Testing Strategies for This Module**
|
||||
- Testing approaches specific to this module
|
||||
- Test coverage strategies and targets
|
||||
- Module-specific testing tools and frameworks
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Project overview content (belongs in root-level docs)
|
||||
- Domain-wide architectural patterns (belongs in domain-level docs)
|
||||
- Detailed function documentation (belongs in sub-module-level docs)
|
||||
- Configuration specifics (belongs in sub-module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on module-level architecture and patterns
|
||||
- Explain how components within the module work together
|
||||
- Document public interfaces and contracts
|
||||
- Reference sub-module docs for detailed implementation
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Module Name] - Module Architecture
|
||||
|
||||
## 1. Module Overview
|
||||
[Module's purpose and responsibilities]
|
||||
|
||||
## 2. Implementation Patterns
|
||||
[Common patterns and approaches used]
|
||||
|
||||
## 3. Internal Architecture
|
||||
[How the module is organized internally]
|
||||
|
||||
## 4. Public Interfaces
|
||||
[APIs and contracts exposed by this module]
|
||||
|
||||
## 5. Dependencies and Integration
|
||||
[Module dependencies and system integration]
|
||||
|
||||
## 6. Testing Strategy
|
||||
[Testing approaches for this module]
|
||||
```
|
||||
|
||||
Remember: This is Layer 3 - focus on module-level architecture and patterns, avoiding both domain-wide and detailed implementation concerns.
|
||||
@@ -0,0 +1,69 @@
|
||||
Create or update sub-module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 4: Sub-Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Detailed Implementation Specifics**
|
||||
- Specific implementation details and algorithms
|
||||
- Code-level patterns and idioms
|
||||
- Implementation trade-offs and decisions
|
||||
|
||||
2. **Component/Function Documentation**
|
||||
- Individual component descriptions
|
||||
- Function signatures and behaviors
|
||||
- Class/struct/interface documentation
|
||||
|
||||
3. **Configuration Details and Examples**
|
||||
- Configuration options and parameters
|
||||
- Environment-specific settings
|
||||
- Configuration examples and templates
|
||||
|
||||
4. **Usage Examples and Patterns**
|
||||
- Code examples and usage patterns
|
||||
- Common use cases and scenarios
|
||||
- Integration examples with other components
|
||||
|
||||
5. **Performance Considerations**
|
||||
- Performance characteristics and constraints
|
||||
- Optimization strategies and techniques
|
||||
- Resource usage and scalability notes
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Architecture decisions (belong in higher levels)
|
||||
- Module-level organizational patterns (belong in module-level docs)
|
||||
- Domain or project overview content (belong in higher levels)
|
||||
- Cross-module architectural concerns (belong in higher levels)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on detailed, actionable implementation information
|
||||
- Provide concrete examples and code snippets
|
||||
- Document specific behaviors and edge cases
|
||||
- Include troubleshooting and debugging guidance
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Sub-Module/Component Name] - Implementation Guide
|
||||
|
||||
## 1. Component Overview
|
||||
[Specific purpose and functionality]
|
||||
|
||||
## 2. Implementation Details
|
||||
[Detailed implementation specifics]
|
||||
|
||||
## 3. API Reference
|
||||
[Function/method documentation]
|
||||
|
||||
## 4. Configuration
|
||||
[Configuration options and examples]
|
||||
|
||||
## 5. Usage Examples
|
||||
[Code examples and patterns]
|
||||
|
||||
## 6. Performance and Optimization
|
||||
[Performance considerations and tips]
|
||||
|
||||
## 7. Troubleshooting
|
||||
[Common issues and solutions]
|
||||
```
|
||||
|
||||
Remember: This is Layer 4 - focus on concrete, actionable implementation details and avoid architectural or organizational concerns.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze project structure for DMS hierarchy optimization:
|
||||
|
||||
## Required Analysis:
|
||||
1. Assess project complexity and file organization patterns
|
||||
2. Identify logical module boundaries and responsibility separation
|
||||
3. Evaluate cross-module dependencies and integration complexity
|
||||
4. Determine optimal documentation depth and hierarchy levels
|
||||
5. Recommend content differentiation strategies across hierarchy levels
|
||||
|
||||
## Output Requirements:
|
||||
- Project complexity classification with supporting metrics
|
||||
- Module boundary recommendations with responsibility mapping
|
||||
- Hierarchy depth recommendations with level-specific focus areas
|
||||
- Content strategy with redundancy elimination guidelines
|
||||
|
||||
Focus on intelligent documentation hierarchy that scales with project complexity.
|
||||
@@ -0,0 +1,16 @@
|
||||
Guide component implementation and development patterns:
|
||||
|
||||
## 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
|
||||
|
||||
Focus on reusable, maintainable component design with clear usage patterns.
|
||||
@@ -0,0 +1,16 @@
|
||||
Plan system migration and modernization strategies:
|
||||
|
||||
## 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 and integration requirements
|
||||
- Risk analysis and rollback procedures
|
||||
|
||||
Focus on low-risk migration strategies with comprehensive fallback options.
|
||||
@@ -0,0 +1,16 @@
|
||||
Create detailed task breakdown and implementation planning:
|
||||
|
||||
## 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 and resource allocation
|
||||
- Risk assessment and mitigation plans
|
||||
|
||||
Focus on actionable task planning with clear deliverables and timelines.
|
||||
@@ -0,0 +1,16 @@
|
||||
Conduct comprehensive code review and quality assessment:
|
||||
|
||||
## Required Analysis:
|
||||
1. Review code against established coding standards and conventions
|
||||
2. Assess logic correctness and potential edge cases
|
||||
3. Evaluate security implications and vulnerability risks
|
||||
4. Check performance characteristics and optimization opportunities
|
||||
5. Validate test coverage and documentation completeness
|
||||
|
||||
## Output Requirements:
|
||||
- Standards compliance assessment with specific violations
|
||||
- Logic review findings with potential issue identification
|
||||
- Security assessment with vulnerability documentation
|
||||
- Performance review with optimization recommendations
|
||||
|
||||
Focus on actionable feedback with clear improvement priorities and implementation guidance.
|
||||
Reference in New Issue
Block a user