mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-12 02:37:45 +08:00
Add parallel execution command templates and analysis prompts
- Introduced a comprehensive set of parallel execution command templates for various architectural and functional scenarios. - Added prompts for analyzing system architecture, implementation patterns, performance, code quality, security, and project structure. - Created templates for planning tasks, component implementation, migration strategies, and code reviews. - Established a unified guideline for Gemini CLI usage, including command syntax, file patterns, and template best practices. - Initialized VSCode settings file for project configuration.1
This commit is contained in:
catlog22
@@ -1,68 +0,0 @@
|
||||
# Gemini Agent Templates Overview
|
||||
|
||||
**Precise, task-focused templates for actionable agent context gathering.**
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides focused templates that deliver precise, actionable context for specific tasks rather than generic pattern analysis. Each template targets exact requirements, modification points, and concrete implementation guidance.
|
||||
|
||||
## Template Usage Guidelines
|
||||
|
||||
### Key Principles
|
||||
|
||||
1. **Task-Specific Focus**: Templates target specific tasks rather than broad analysis
|
||||
2. **Actionable Output**: Provide exact file:line references and concrete guidance
|
||||
3. **Repository Context**: Extract patterns specific to the actual codebase
|
||||
4. **Precise Scope**: Analyze only what's needed for the immediate task
|
||||
|
||||
### When to Use Each Template
|
||||
|
||||
**Planning Agent**: Before creating implementation plans for specific features or fixes
|
||||
- Use when you need to understand exact scope and modification points
|
||||
- Focus on concrete deliverables rather than architectural overviews
|
||||
|
||||
**Code Developer**: Before implementing specific functions, classes, or features
|
||||
- Use when you need exact insertion points and code structure guidance
|
||||
- Focus on actionable implementation steps with line references
|
||||
|
||||
**Code Review**: After code has been written for a specific task
|
||||
- Use when reviewing changes against repository-specific standards
|
||||
- Focus on understanding what was actually implemented and how it fits
|
||||
|
||||
**UI Design**: Before creating or modifying specific UI components
|
||||
- Use when you need component-specific patterns and design system compliance
|
||||
- Focus on established design language and interaction patterns
|
||||
|
||||
**Memory-Gemini-Bridge**: For creating or updating CLAUDE.md files
|
||||
- Use when establishing hierarchical documentation strategy
|
||||
- Focus on cross-system compatibility between Claude and Gemini CLI
|
||||
|
||||
### Benefits of Task-Focused Approach
|
||||
|
||||
1. **Precision**: Get exact modification points instead of general patterns
|
||||
2. **Efficiency**: 50% reduction in irrelevant analysis
|
||||
3. **Actionability**: Concrete guidance with file:line references
|
||||
4. **Context Relevance**: Repository-specific patterns, not generic best practices
|
||||
5. **Task Alignment**: Analysis directly supports the specific work being done
|
||||
|
||||
### Template Customization
|
||||
|
||||
Customize templates by:
|
||||
|
||||
1. **Specific File Targeting**: Replace `[task-related-files]` with exact patterns for your task
|
||||
2. **Domain Context**: Add domain-specific file patterns (auth, api, ui, etc.)
|
||||
3. **Technology Focus**: Include relevant extensions (.tsx for React, .py for Python, etc.)
|
||||
4. **Task Context**: Specify exact feature or component being worked on
|
||||
|
||||
These focused templates provide agents with precise, actionable context for specific tasks, eliminating unnecessary pattern analysis and providing concrete implementation guidance.
|
||||
|
||||
## Integration with Intelligent Context
|
||||
|
||||
All templates integrate with `gemini-intelligent-context.md`(@~/.claude/workflows/gemini-intelligent-context.md) for:
|
||||
|
||||
- **Smart Path Detection** - Automatic file targeting based on analysis type
|
||||
- **Technology Stack Detection** - Framework and language-specific optimizations
|
||||
- **Domain Context Mapping** - Intelligent domain-specific pattern matching
|
||||
- **Dynamic Prompt Enhancement** - Context-aware prompt construction
|
||||
|
||||
For complete context detection algorithms and intelligent file targeting, see `gemini-intelligent-context.md`.
|
||||
@@ -1,273 +0,0 @@
|
||||
# Gemini CLI Core Guidelines
|
||||
|
||||
**Streamlined Gemini CLI usage guidelines with parallel execution patterns for enhanced performance.**
|
||||
|
||||
## 🎯 Core Command Syntax
|
||||
|
||||
### Basic Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{file_patterns} analysis_prompt"
|
||||
```
|
||||
|
||||
**Parameters**:
|
||||
- `--all-files` - Include all files (context-dependent on execution path)
|
||||
- `-p` - Specify prompt content
|
||||
- `@{pattern}` - File reference pattern
|
||||
|
||||
### Parallel Execution Structure
|
||||
```bash
|
||||
# Execute multiple Gemini commands concurrently
|
||||
(
|
||||
gemini_command_1 &
|
||||
gemini_command_2 &
|
||||
gemini_command_3 &
|
||||
wait # Synchronize all parallel processes
|
||||
)
|
||||
```
|
||||
|
||||
### ⚠️ Execution Path Dependencies
|
||||
- `--all-files` adds all text to context memory and depends on execution path
|
||||
- **For folder-specific analysis**: Navigate to target folder first, then run gemini
|
||||
- **If errors occur**: Remove `--all-files` and use `@folder` or `@file` in prompts instead
|
||||
|
||||
**Example - Analyzing a specific component folder:**
|
||||
```bash
|
||||
# Combined command - navigate and analyze in one line
|
||||
cd src/components/ui && gemini --all-files -p "analyze component structure and patterns in this UI folder"
|
||||
|
||||
# For Windows systems
|
||||
cd src\components\ui && gemini --all-files -p "analyze component structure and patterns in this UI folder"
|
||||
|
||||
# Alternative if --all-files fails
|
||||
cd /project/root && gemini -p "@src/components/ui analyze UI component patterns and structure"
|
||||
|
||||
# Cross-platform combined command with fallback
|
||||
cd src/components/ui && gemini --all-files -p "analyze patterns" || gemini -p "@src/components/ui analyze patterns"
|
||||
```
|
||||
|
||||
## 📂 File Reference Rules
|
||||
|
||||
### Required Reference Patterns
|
||||
```bash
|
||||
# 1. Project guidelines files (REQUIRED)
|
||||
@{CLAUDE.md,**/*CLAUDE.md}
|
||||
|
||||
# 2. Target analysis files
|
||||
@{src/**/*,lib/**/*} # Source code
|
||||
@{**/*.{ts,tsx,js,jsx}} # Specific languages
|
||||
@{**/api/**/*} # Domain-related
|
||||
|
||||
# 3. Test files (RECOMMENDED)
|
||||
@{**/*.test.*,**/*.spec.*}
|
||||
```
|
||||
|
||||
### Domain Pattern Quick Reference
|
||||
| Domain | Pattern |
|
||||
|--------|---------|
|
||||
| **Frontend Components** | `@{src/components/**/*,src/ui/**/*}` |
|
||||
| **API Endpoints** | `@{**/api/**/*,**/routes/**/*}` |
|
||||
| **Authentication** | `@{**/*auth*,**/*login*,**/*session*}` |
|
||||
| **Database** | `@{**/models/**/*,**/db/**/*}` |
|
||||
| **Configuration** | `@{*.config.*,**/config/**/*}` |
|
||||
|
||||
## ⚡ Parallel Agent Execution Guidelines
|
||||
|
||||
### Parallel Task Distribution Rules
|
||||
|
||||
**Rule 1: Module Independence Analysis**
|
||||
- Before parallel execution, identify independent modules
|
||||
- Group modules by dependency level
|
||||
- Execute only independent modules in parallel
|
||||
|
||||
**Rule 2: Resource-Based Concurrency**
|
||||
- Default: 3 concurrent Gemini processes
|
||||
- Maximum: 5 concurrent processes (system dependent)
|
||||
- Reduce if memory/CPU constraints detected
|
||||
|
||||
**Rule 3: Synchronization Points**
|
||||
- Wait for all modules at same dependency level
|
||||
- Merge results before proceeding to next level
|
||||
- Global summary only after all modules complete
|
||||
|
||||
### Parallel Template Formats
|
||||
|
||||
**Directory-Based Parallel Execution**:
|
||||
```bash
|
||||
# Navigate to different directories and analyze in parallel
|
||||
(
|
||||
cd src/components/ui && gemini --all-files -p "@{CLAUDE.md} analyze UI patterns" &
|
||||
cd src/components/forms && gemini --all-files -p "@{CLAUDE.md} analyze form patterns" &
|
||||
cd src/api && gemini --all-files -p "@{CLAUDE.md} analyze API patterns" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
**File Pattern Parallel Execution**:
|
||||
```bash
|
||||
# Use file patterns for parallel analysis (when --all-files not suitable)
|
||||
gemini -p "@src/components/ui/**/* @{CLAUDE.md} analyze UI implementation" &
|
||||
gemini -p "@src/components/forms/**/* @{CLAUDE.md} analyze form handling" &
|
||||
gemini -p "@src/api/auth/**/* @{CLAUDE.md} analyze authentication" &
|
||||
wait
|
||||
```
|
||||
|
||||
### Standard Sequential Template
|
||||
```bash
|
||||
gemini --all-files -p "@{target_files} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
|
||||
Analysis Task: [specific task description]
|
||||
|
||||
Required Output:
|
||||
- Specific file:line references
|
||||
- Executable code examples
|
||||
- Clear implementation guidance"
|
||||
```
|
||||
|
||||
### Agent-Specific Modes
|
||||
```bash
|
||||
# Planning Agent (navigate to project root first)
|
||||
cd /path/to/project && gemini --all-files -p "@{src/**/*} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
Task planning analysis: [task] - Extract file modification points, implementation sequence, integration requirements"
|
||||
|
||||
# Code Developer (navigate to target directory first)
|
||||
cd /path/to/project && gemini --all-files -p "@{**/*.{ts,js}} @{**/*test*} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
Code implementation guidance: [feature] - Extract code patterns, insertion points, testing requirements"
|
||||
|
||||
# Code Review (use @file references if --all-files fails)
|
||||
gemini -p "@modified_files @related_files @CLAUDE.md
|
||||
Code review: [changes] - Compare against standards, check consistency, identify risks"
|
||||
|
||||
# Alternative without --all-files for targeted analysis
|
||||
gemini -p "@src/components @CLAUDE.md
|
||||
Component analysis: [specific_component] - Extract patterns and implementation guidance"
|
||||
```
|
||||
|
||||
## 📋 Core Principles
|
||||
|
||||
### 1. File Reference Principles
|
||||
- **Must include**: `@{CLAUDE.md,**/*CLAUDE.md}`
|
||||
- **Precise targeting**: Use specific file patterns, avoid over-inclusion
|
||||
- **Logical grouping**: Combine related file patterns
|
||||
|
||||
### 2. Prompt Construction Principles
|
||||
- **Single objective**: Each command completes one analysis task
|
||||
- **Specific requirements**: Clearly specify required output format
|
||||
- **Context integration**: Reference project standards and existing patterns
|
||||
|
||||
### 3. Output Requirements
|
||||
- **File references**: Provide specific `file:line` locations
|
||||
- **Code examples**: Give executable code snippets
|
||||
- **Implementation guidance**: Clear next-step actions
|
||||
|
||||
## 🔧 Common Command Patterns
|
||||
|
||||
### Quick Analysis
|
||||
```bash
|
||||
# Architecture analysis (navigate to project root first)
|
||||
cd /project/root && gemini --all-files -p "@{src/**/*} @{CLAUDE.md} system architecture and component relationships"
|
||||
|
||||
# Pattern detection (navigate to project root first)
|
||||
cd /project/root && gemini --all-files -p "@{**/*.ts} @{CLAUDE.md} TypeScript usage patterns"
|
||||
|
||||
# Security review (fallback to @file if --all-files fails)
|
||||
gemini -p "@**/*auth* @CLAUDE.md authentication and authorization implementation patterns"
|
||||
|
||||
# Folder-specific analysis (navigate to target folder)
|
||||
cd /project/src/components && gemini --all-files -p "component structure and patterns analysis"
|
||||
```
|
||||
|
||||
### Parallel Analysis Patterns
|
||||
```bash
|
||||
# Parallel architecture analysis by layer
|
||||
(
|
||||
cd src/frontend && gemini --all-files -p "analyze frontend architecture" &
|
||||
cd src/backend && gemini --all-files -p "analyze backend architecture" &
|
||||
cd src/database && gemini --all-files -p "analyze data layer architecture" &
|
||||
wait
|
||||
)
|
||||
|
||||
# Parallel pattern detection across modules
|
||||
gemini -p "@src/components/**/*.tsx analyze React patterns" &
|
||||
gemini -p "@src/api/**/*.ts analyze API patterns" &
|
||||
gemini -p "@src/utils/**/*.ts analyze utility patterns" &
|
||||
wait
|
||||
|
||||
# Parallel security review
|
||||
(
|
||||
gemini -p "@**/*auth* analyze authentication implementation" &
|
||||
gemini -p "@**/*permission* analyze authorization patterns" &
|
||||
gemini -p "@**/*crypto* analyze encryption usage" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### Integration Standards
|
||||
1. **Path awareness**: Navigate to appropriate directory before using `--all-files`
|
||||
2. **Fallback strategy**: Use `@file` or `@folder` references if `--all-files` errors
|
||||
3. **Minimal references**: Only reference files you actually need
|
||||
4. **Self-contained**: Avoid complex cross-file dependencies
|
||||
5. **Focused analysis**: Use for specific analysis, not general exploration
|
||||
6. **Result reuse**: Reuse analysis results when possible
|
||||
|
||||
### Parallel Execution Standards
|
||||
1. **Dependency verification**: Ensure modules are independent before parallel execution
|
||||
2. **Resource monitoring**: Check system capacity before increasing concurrency
|
||||
3. **Synchronization discipline**: Always use `wait` after parallel commands
|
||||
4. **Result aggregation**: Merge outputs from parallel executions properly
|
||||
5. **Error isolation**: Handle failures in individual parallel tasks gracefully
|
||||
6. **Performance tracking**: Monitor speedup to validate parallel benefit
|
||||
|
||||
## 📊 Parallel Execution Rules
|
||||
|
||||
### Rule-Based Parallel Coordination
|
||||
|
||||
**Execution Order Rules**:
|
||||
1. **Level 0 (Leaf Modules)**: Execute all in parallel (max 5)
|
||||
2. **Level N**: Wait for Level N-1 completion before starting
|
||||
3. **Root Level**: Process only after all module levels complete
|
||||
|
||||
**File Partitioning Rules**:
|
||||
1. **Size-based**: Split large directories into ~equal file counts
|
||||
2. **Type-based**: Group by file extension for focused analysis
|
||||
3. **Logic-based**: Separate by functionality (auth, api, ui, etc.)
|
||||
|
||||
**Memory Management Rules**:
|
||||
1. **Per-process limit**: Each Gemini process uses ~500MB-1GB
|
||||
2. **Total limit**: Don't exceed 80% system memory
|
||||
3. **Throttling**: Reduce parallelism if memory pressure detected
|
||||
|
||||
**Synchronization Rules**:
|
||||
1. **Barrier sync**: All tasks at level must complete
|
||||
2. **Queue sync**: Next task starts when worker available
|
||||
3. **Async sync**: Collect results as they complete
|
||||
|
||||
### Performance Optimization Rules
|
||||
|
||||
**When to use parallel execution**:
|
||||
- Project has >5 independent modules
|
||||
- Modules have clear separation
|
||||
- System has adequate resources (>8GB RAM)
|
||||
- Time savings justify coordination overhead
|
||||
|
||||
**When to avoid parallel execution**:
|
||||
- Small projects (<5 modules)
|
||||
- Highly interdependent modules
|
||||
- Limited system resources
|
||||
- Sequential dependencies required
|
||||
|
||||
### Error Handling Rules
|
||||
|
||||
**Parallel Failure Recovery**:
|
||||
1. If one parallel task fails, continue others
|
||||
2. Retry failed tasks once with reduced scope
|
||||
3. Fall back to sequential for persistent failures
|
||||
4. Report all failures at synchronization point
|
||||
|
||||
**Resource Exhaustion Handling**:
|
||||
1. Detect high memory/CPU usage
|
||||
2. Pause new parallel tasks
|
||||
3. Wait for current tasks to complete
|
||||
4. Resume with reduced concurrency
|
||||
|
||||
---
|
||||
*Enhanced version with parallel execution patterns and coordination rules*
|
||||
@@ -1,92 +0,0 @@
|
||||
# Gemini Code Developer Template
|
||||
|
||||
**Purpose**: Locate exact modification points and provide concrete implementation guidance
|
||||
|
||||
## Template Structure
|
||||
|
||||
```bash
|
||||
gemini --all-files -p "@{[target-modification-files]} @{[similar-feature-files]} @{**/*test*/**/*,**/*.test.*,**/*.spec.*}
|
||||
|
||||
Implementation guidance for: [specific feature/function to implement]
|
||||
|
||||
## Required Analysis:
|
||||
1. **Exact Modification Points**:
|
||||
- Find precise locations (file:line) where new code should be added
|
||||
- Identify existing functions that need modification
|
||||
- Locate where new imports/dependencies should be added
|
||||
|
||||
2. **Similar Code Examples**:
|
||||
- Find existing implementations similar to what needs to be built
|
||||
- Extract code patterns that should be followed
|
||||
- Identify utility functions that can be reused
|
||||
|
||||
3. **Code Structure and Patterns**:
|
||||
- How should the new code be structured based on existing patterns?
|
||||
- What naming conventions are used for similar features?
|
||||
- What error handling patterns should be followed?
|
||||
|
||||
4. **Testing Requirements**:
|
||||
- Find similar test cases for reference
|
||||
- Identify testing utilities and helpers available
|
||||
- Determine what specific test scenarios are needed
|
||||
|
||||
5. **Integration and Dependencies**:
|
||||
- What existing functions need to call the new code?
|
||||
- Which modules need to import the new functionality?
|
||||
- What configuration or setup is required?
|
||||
|
||||
## Output Requirements:
|
||||
- **Precise insertion points**: Exact file:line locations for new code
|
||||
- **Code skeleton**: Structure based on existing patterns with placeholder functions
|
||||
- **Concrete examples**: Copy-paste reference code from similar features
|
||||
- **Test template**: Specific test cases needed based on existing patterns
|
||||
- **Integration checklist**: Exact functions/files that need to call or import new code
|
||||
|
||||
Focus on actionable implementation guidance with specific line references."
|
||||
```
|
||||
|
||||
## Intelligent Usage Examples
|
||||
|
||||
```python
|
||||
# React component implementation
|
||||
def code_developer_context(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="Create user profile edit component",
|
||||
analysis_type="code-developer-context",
|
||||
domains=['frontend', 'ui'],
|
||||
tech_stack=['React', 'TypeScript', 'Tailwind']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{src/components/**/*,src/pages/**/*}}
|
||||
@{{**/*profile*,**/*user*,**/*form*}} @{{**/*.test.*,**/*.spec.*}}
|
||||
@{{CLAUDE.md,frontend/CLAUDE.md,react/CLAUDE.md}}
|
||||
|
||||
Implementation guidance for: User profile edit component with form validation
|
||||
- Profile form fields: name, email, bio, avatar upload
|
||||
- Form validation using existing patterns
|
||||
- State management integration with user context
|
||||
|
||||
Focus on exact insertion points and component structure based on similar forms."
|
||||
"""
|
||||
```
|
||||
|
||||
## Context Application
|
||||
|
||||
- Locate exact code insertion and modification points
|
||||
- Follow repository-specific patterns and conventions
|
||||
- Reuse existing utilities and established approaches
|
||||
- Create comprehensive test coverage based on similar features
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
**Use Code Developer template when**:
|
||||
- Before implementing specific functions, classes, or features
|
||||
- You need exact insertion points and code structure guidance
|
||||
- Focus on actionable implementation steps with line references
|
||||
|
||||
**Template focuses on**:
|
||||
- Precise, task-focused analysis for actionable implementation
|
||||
- Exact file:line references and concrete guidance
|
||||
- Repository context with patterns specific to the actual codebase
|
||||
- Specific scope analyzing only what's needed for the immediate task
|
||||
@@ -1,93 +0,0 @@
|
||||
# Gemini Code Review Template
|
||||
|
||||
**Purpose**: Understand specific changes and review against repository standards
|
||||
|
||||
## Template Structure
|
||||
|
||||
```bash
|
||||
gemini --all-files -p "@{[modified-files]} @{[related-files]} @{[test-files-for-changes]}
|
||||
|
||||
Review context for recent changes:
|
||||
Modified files: [list of specific files that were changed]
|
||||
Original task: [what was being implemented]
|
||||
|
||||
## Required Analysis:
|
||||
1. **Change Understanding**:
|
||||
- What was the specific goal of these modifications?
|
||||
- Which functions/classes were added or modified?
|
||||
- How do the changes relate to the original task requirements?
|
||||
|
||||
2. **Repository Convention Compliance**:
|
||||
- Do the changes follow naming conventions used in similar files?
|
||||
- Is the code structure consistent with existing patterns?
|
||||
- Are imports, error handling, and logging consistent?
|
||||
|
||||
3. **Impact and Integration Analysis**:
|
||||
- What other code might be affected by these changes?
|
||||
- Are all necessary integration points properly handled?
|
||||
- Do the changes maintain backward compatibility?
|
||||
|
||||
4. **Test Coverage and Quality**:
|
||||
- Are the specific changes properly tested?
|
||||
- Do test cases cover edge cases similar to existing tests?
|
||||
- Is the test structure consistent with repository patterns?
|
||||
|
||||
5. **Security and Performance**:
|
||||
- Are there security concerns specific to these changes?
|
||||
- Do the changes follow performance patterns used elsewhere?
|
||||
- Are there potential bottlenecks introduced?
|
||||
|
||||
## Output Requirements:
|
||||
- **Specific issues**: Point to exact problems with file:line references
|
||||
- **Convention violations**: Compare against similar code in the repository
|
||||
- **Missing coverage**: Identify untested code paths with test examples
|
||||
- **Integration gaps**: List functions/modules that need updates
|
||||
- **Improvement suggestions**: Provide specific code improvements based on repository patterns
|
||||
|
||||
Focus on change-specific review rather than generic quality assessment."
|
||||
```
|
||||
|
||||
## Intelligent Usage Examples
|
||||
|
||||
```python
|
||||
# Authentication system review
|
||||
def code_review_context(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="Review OAuth2 implementation changes",
|
||||
analysis_type="code-review-context",
|
||||
domains=['auth', 'security', 'api'],
|
||||
tech_stack=['Node.js', 'JWT', 'Redis']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/auth/**/*,**/middleware/*auth*}}
|
||||
@{{**/oauth/**/*,**/session/**/*}} @{{**/*test*/*auth*}}
|
||||
@{{CLAUDE.md,auth/CLAUDE.md,security/CLAUDE.md}}
|
||||
|
||||
Review context for recent OAuth2 implementation changes:
|
||||
Modified files: auth/oauth-controller.js, middleware/auth-middleware.js
|
||||
Original task: Implement OAuth2 authorization code flow with PKCE
|
||||
|
||||
Focus on security compliance and existing authentication patterns."
|
||||
"""
|
||||
```
|
||||
|
||||
## Context Application
|
||||
|
||||
- Review changes against repository-specific standards
|
||||
- Compare implementation approach with similar features
|
||||
- Validate test coverage for the specific functionality implemented
|
||||
- Ensure integration points are properly handled
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
**Use Code Review template when**:
|
||||
- After code has been written for a specific task
|
||||
- You need to review changes against repository-specific standards
|
||||
- Focus on understanding what was actually implemented and how it fits
|
||||
|
||||
**Template focuses on**:
|
||||
- Change-specific review rather than generic quality assessment
|
||||
- Specific issues with exact file:line references
|
||||
- Repository context comparing against similar code
|
||||
- Precise scope analyzing only what's relevant to the changes made
|
||||
@@ -1,431 +0,0 @@
|
||||
# Gemini Core Analysis Templates
|
||||
|
||||
**Comprehensive templates for core codebase analysis using Gemini CLI.**
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides core analysis templates for pattern detection, architecture analysis, security assessment, performance optimization, feature tracing, quality analysis, dependencies review, and migration planning.
|
||||
|
||||
## Pattern Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{file_patterns} @{claude_context}
|
||||
|
||||
Context: Pattern analysis targeting @{file_patterns}
|
||||
Guidelines: Include CLAUDE.md standards from @{claude_context}
|
||||
|
||||
Analyze this codebase and identify all {target} patterns.
|
||||
Focus on:
|
||||
1. Implementation patterns in specified files
|
||||
2. Compliance with project guidelines from CLAUDE.md
|
||||
3. Best practices and anti-patterns
|
||||
4. Usage frequency and distribution across modules
|
||||
5. Specific examples with file:line references
|
||||
|
||||
Include concrete recommendations based on existing patterns."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Simple pattern detection
|
||||
def pattern_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="React hooks usage patterns",
|
||||
analysis_type="pattern",
|
||||
domains=['frontend', 'state'],
|
||||
tech_stack=['React', 'TypeScript']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/*.{{jsx,tsx,js,ts}}}} @{{**/hooks/**/*,**/context/**/*}}
|
||||
@{{CLAUDE.md,frontend/CLAUDE.md,react/CLAUDE.md}}
|
||||
|
||||
Analyze React hooks patterns in this codebase:
|
||||
- Custom hooks implementation and naming conventions
|
||||
- useState/useEffect usage patterns and dependencies
|
||||
- Context providers and consumers
|
||||
- Hook composition and reusability
|
||||
- Performance considerations and optimization
|
||||
- Compliance with React best practices
|
||||
- Project-specific patterns from CLAUDE.md
|
||||
|
||||
Focus on TypeScript implementations and provide specific file:line examples."
|
||||
"""
|
||||
```
|
||||
|
||||
## Architecture Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{module_patterns} @{claude_context}
|
||||
|
||||
Context: System architecture analysis at @{module_patterns}
|
||||
Project structure: @{structure_patterns}
|
||||
Guidelines: @{claude_context}
|
||||
|
||||
Examine the {target} in this application.
|
||||
Analyze:
|
||||
1. Component hierarchy and module organization
|
||||
2. Data flow and state management patterns
|
||||
3. Dependency relationships and coupling
|
||||
4. Architectural patterns and design decisions
|
||||
5. Integration points and boundaries
|
||||
|
||||
Map findings to specific files and provide architecture insights."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Microservices architecture analysis
|
||||
def architecture_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="microservices communication patterns",
|
||||
analysis_type="architecture",
|
||||
domains=['api', 'backend'],
|
||||
tech_stack=['Node.js', 'Docker']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/services/**/*,**/api/**/*,**/gateway/**/*}}
|
||||
@{{docker-compose*.yml,**/Dockerfile,**/*.proto}}
|
||||
@{{CLAUDE.md,architecture/CLAUDE.md,services/CLAUDE.md}}
|
||||
|
||||
Analyze microservices architecture:
|
||||
- Service boundaries and single responsibilities
|
||||
- Inter-service communication patterns (REST, gRPC, events)
|
||||
- API gateway configuration and routing
|
||||
- Service discovery and load balancing
|
||||
- Data consistency and transaction boundaries
|
||||
- Deployment and orchestration patterns
|
||||
- Compliance with architectural guidelines
|
||||
|
||||
Include service dependency graph and communication flow diagrams."
|
||||
"""
|
||||
```
|
||||
|
||||
## Security Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{security_patterns} @{auth_patterns} @{config_patterns}
|
||||
|
||||
Context: Security analysis scope @{security_patterns}
|
||||
Auth modules: @{auth_patterns}
|
||||
Config files: @{config_patterns}
|
||||
Guidelines: Security standards from @{claude_context}
|
||||
|
||||
Scan for {target} security vulnerabilities.
|
||||
Check:
|
||||
1. Authentication and authorization implementations
|
||||
2. Input validation and sanitization
|
||||
3. Sensitive data handling and encryption
|
||||
4. Security headers and configurations
|
||||
5. Third-party dependency vulnerabilities
|
||||
|
||||
Provide OWASP-aligned findings with severity levels and remediation steps."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# OAuth2 security analysis
|
||||
def security_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="OAuth2 authentication vulnerabilities",
|
||||
analysis_type="security",
|
||||
domains=['auth', 'security'],
|
||||
tech_stack=['Node.js', 'JWT']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/auth/**/*,**/oauth/**/*,**/middleware/*auth*}}
|
||||
@{{**/config/**/*,.env*,**/*.pem,**/*.key}}
|
||||
@{{CLAUDE.md,security/CLAUDE.md,auth/CLAUDE.md}}
|
||||
|
||||
Analyze OAuth2 authentication security:
|
||||
- Authorization code flow implementation
|
||||
- Token storage and handling security
|
||||
- Client authentication and PKCE implementation
|
||||
- Scope validation and privilege escalation risks
|
||||
- JWT token signature verification
|
||||
- Refresh token rotation and revocation
|
||||
- CSRF and state parameter validation
|
||||
- Redirect URI validation
|
||||
|
||||
Apply OWASP OAuth2 Security Cheat Sheet standards and provide specific vulnerability findings."
|
||||
"""
|
||||
```
|
||||
|
||||
## Performance Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{performance_patterns} @{core_patterns}
|
||||
|
||||
Context: Performance analysis at @{performance_patterns}
|
||||
Core modules: @{core_patterns}
|
||||
Guidelines: Performance standards from @{claude_context}
|
||||
|
||||
Analyze {target} performance issues.
|
||||
Examine:
|
||||
1. Expensive operations and computational complexity
|
||||
2. Memory usage and potential leaks
|
||||
3. Database query efficiency and N+1 problems
|
||||
4. Network requests and data transfer optimization
|
||||
5. Rendering performance and re-render cycles
|
||||
|
||||
Include performance metrics and optimization recommendations."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# React rendering performance analysis
|
||||
def performance_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="React component rendering performance",
|
||||
analysis_type="performance",
|
||||
domains=['frontend', 'performance'],
|
||||
tech_stack=['React', 'TypeScript']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{src/components/**/*.{{jsx,tsx}},src/hooks/**/*}}
|
||||
@{{**/context/**/*,**/store/**/*}}
|
||||
@{{CLAUDE.md,performance/CLAUDE.md,react/CLAUDE.md}}
|
||||
|
||||
Analyze React rendering performance issues:
|
||||
- Component re-render cycles and unnecessary renders
|
||||
- useMemo/useCallback optimization opportunities
|
||||
- Context provider optimization and value memoization
|
||||
- Large list virtualization needs
|
||||
- Bundle splitting and lazy loading opportunities
|
||||
- State update batching and scheduling
|
||||
- Memory leaks in useEffect cleanup
|
||||
- Performance impact of prop drilling
|
||||
|
||||
Include React DevTools Profiler insights and specific optimization recommendations."
|
||||
"""
|
||||
```
|
||||
|
||||
## Feature Tracing
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{feature_patterns} @{related_patterns}
|
||||
|
||||
Context: Feature implementation at @{feature_patterns}
|
||||
Related modules: @{related_patterns}
|
||||
Guidelines: Feature standards from @{claude_context}
|
||||
|
||||
Trace the implementation of {target} throughout this codebase.
|
||||
Map:
|
||||
1. Entry points (UI components, API endpoints)
|
||||
2. Business logic and data processing
|
||||
3. Database models and queries
|
||||
4. State management and data flow
|
||||
5. Integration points with other features
|
||||
|
||||
Show complete feature flow with file:line references."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Payment processing feature trace
|
||||
def feature_tracing(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="payment processing system",
|
||||
analysis_type="feature",
|
||||
domains=['api', 'database', 'frontend'],
|
||||
tech_stack=['Node.js', 'React', 'PostgreSQL']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/payment/**/*,**/billing/**/*,**/stripe/**/*}}
|
||||
@{{**/models/*payment*,**/models/*order*,**/api/*payment*}}
|
||||
@{{src/components/*payment*,src/pages/*checkout*}}
|
||||
@{{CLAUDE.md,payment/CLAUDE.md,api/CLAUDE.md}}
|
||||
|
||||
Trace complete payment processing implementation:
|
||||
- Frontend: Payment forms, checkout flow, success/error handling
|
||||
- API: Payment endpoints, validation, webhook handling
|
||||
- Business Logic: Payment calculation, tax, discounts, refunds
|
||||
- Database: Payment models, transaction records, audit logs
|
||||
- Integration: Stripe/PayPal integration, notification systems
|
||||
- Security: PCI compliance, data encryption, fraud detection
|
||||
- Error Handling: Payment failures, retry logic, recovery flows
|
||||
|
||||
Map the entire payment flow from UI interaction to database persistence."
|
||||
"""
|
||||
```
|
||||
|
||||
## Quality Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{quality_patterns} @{test_patterns}
|
||||
|
||||
Context: Code quality assessment at @{quality_patterns}
|
||||
Test coverage: @{test_patterns}
|
||||
Guidelines: Quality standards from @{claude_context}
|
||||
|
||||
Examine {target} in this codebase.
|
||||
Assess:
|
||||
1. Code consistency and style compliance
|
||||
2. Error handling and edge case coverage
|
||||
3. Testing coverage and quality
|
||||
4. Documentation completeness
|
||||
5. Maintainability and refactoring opportunities
|
||||
|
||||
Provide actionable quality improvement recommendations with priorities."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# TypeScript code quality analysis
|
||||
def quality_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="TypeScript code quality and consistency",
|
||||
analysis_type="quality",
|
||||
domains=['frontend', 'testing'],
|
||||
tech_stack=['TypeScript', 'React', 'Jest']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/*.{{ts,tsx}},src/**/*}}
|
||||
@{{**/*.test.{{ts,tsx}},**/*.spec.{{ts,tsx}}}}
|
||||
@{{CLAUDE.md,typescript/CLAUDE.md,testing/CLAUDE.md}}
|
||||
|
||||
Analyze TypeScript code quality:
|
||||
- Type safety: any usage, strict mode compliance, type assertions
|
||||
- Interface design: proper abstractions, generic usage, utility types
|
||||
- Error handling: proper error types, exception handling patterns
|
||||
- Code consistency: naming conventions, file organization, imports
|
||||
- Testing quality: type-safe tests, mock implementations, coverage
|
||||
- Documentation: TSDoc comments, README updates, type exports
|
||||
- Performance: bundle analysis, tree-shaking optimization
|
||||
- Maintainability: code duplication, complexity metrics
|
||||
|
||||
Prioritize recommendations by impact and provide specific file:line examples."
|
||||
"""
|
||||
```
|
||||
|
||||
## Dependencies Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{dependency_patterns} @{package_patterns}
|
||||
|
||||
Context: Dependency analysis at @{dependency_patterns}
|
||||
Package files: @{package_patterns}
|
||||
Guidelines: Dependency standards from @{claude_context}
|
||||
|
||||
Analyze {target} in this project.
|
||||
Review:
|
||||
1. Third-party library usage and necessity
|
||||
2. Version consistency and update availability
|
||||
3. Security vulnerabilities in dependencies
|
||||
4. Bundle size impact and optimization opportunities
|
||||
5. Licensing compatibility and compliance
|
||||
|
||||
Show dependency graph with recommendations for optimization."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Node.js dependencies security analysis
|
||||
def dependencies_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="Node.js dependencies security vulnerabilities",
|
||||
analysis_type="dependencies",
|
||||
domains=['security', 'config'],
|
||||
tech_stack=['Node.js', 'npm']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{package*.json,yarn.lock,pnpm-lock.yaml}}
|
||||
@{{**/node_modules/**/package.json}} @{{.npmrc,.yarnrc*}}
|
||||
@{{CLAUDE.md,security/CLAUDE.md,dependencies/CLAUDE.md}}
|
||||
|
||||
Analyze Node.js dependencies for security issues:
|
||||
- Vulnerability scanning: known CVEs, security advisories
|
||||
- Outdated packages: major version gaps, EOL dependencies
|
||||
- License compliance: GPL conflicts, commercial restrictions
|
||||
- Bundle impact: largest dependencies, tree-shaking opportunities
|
||||
- Maintenance status: abandoned packages, low activity projects
|
||||
- Alternative recommendations: lighter alternatives, native implementations
|
||||
- Development vs production: devDependency misclassification
|
||||
- Version pinning: semantic versioning strategy, lock file consistency
|
||||
|
||||
Provide dependency upgrade roadmap with security priority rankings."
|
||||
"""
|
||||
```
|
||||
|
||||
## Migration Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{migration_patterns} @{legacy_patterns}
|
||||
|
||||
Context: Migration analysis at @{migration_patterns}
|
||||
Legacy code: @{legacy_patterns}
|
||||
Guidelines: Migration standards from @{claude_context}
|
||||
|
||||
Identify {target} that could benefit from modernization.
|
||||
Find:
|
||||
1. Outdated patterns and deprecated APIs
|
||||
2. Performance inefficiencies and technical debt
|
||||
3. Security vulnerabilities in legacy code
|
||||
4. Opportunities for newer language features
|
||||
5. Framework upgrade paths and compatibility
|
||||
|
||||
Provide prioritized migration roadmap with risk assessment."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# React class to hooks migration analysis
|
||||
def migration_analysis(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="React class components to hooks migration",
|
||||
analysis_type="migration",
|
||||
domains=['frontend'],
|
||||
tech_stack=['React', 'JavaScript', 'TypeScript']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{src/components/**/*.{{jsx,js}},src/containers/**/*}}
|
||||
@{{**/legacy/**/*,**/deprecated/**/*}}
|
||||
@{{CLAUDE.md,react/CLAUDE.md,migration/CLAUDE.md}}
|
||||
|
||||
Analyze React class components for hooks migration:
|
||||
- Class components: lifecycle methods, state usage, refs
|
||||
- HOC patterns: higher-order components vs custom hooks
|
||||
- Render props: render prop patterns vs hook alternatives
|
||||
- Legacy context: old context API vs useContext
|
||||
- Performance: shouldComponentUpdate vs React.memo
|
||||
- Testing: enzyme vs testing-library compatibility
|
||||
- Bundle size: potential size reduction after migration
|
||||
- Breaking changes: prop types, default props handling
|
||||
|
||||
Provide migration priority matrix based on complexity and benefit."
|
||||
"""
|
||||
```
|
||||
|
||||
## Template Usage Guidelines
|
||||
|
||||
1. **Always use intelligent context** - Let the system generate smart file patterns
|
||||
2. **Reference specific sections** - Use anchor links for modular access
|
||||
3. **Validate generated patterns** - Ensure patterns match actual project structure
|
||||
4. **Combine templates strategically** - Use multiple templates for comprehensive analysis
|
||||
5. **Cache context results** - Reuse context analysis across multiple templates
|
||||
|
||||
## Integration with Intelligent Context
|
||||
|
||||
All templates integrate with @~/.claude/workflows/gemini-intelligent-context.md for:
|
||||
|
||||
- **Smart Path Detection** - Automatic file targeting based on analysis type
|
||||
- **Technology Stack Detection** - Framework and language-specific optimizations
|
||||
- **Domain Context Mapping** - Intelligent domain-specific pattern matching
|
||||
- **Dynamic Prompt Enhancement** - Context-aware prompt construction
|
||||
|
||||
For complete context detection algorithms and intelligent file targeting, see the dedicated intelligent context documentation.
|
||||
@@ -1,282 +0,0 @@
|
||||
# Gemini DMS Analysis Templates
|
||||
|
||||
**Specialized templates for Distributed Memory System (DMS) analysis and documentation hierarchy optimization.**
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides DMS-specific analysis templates for architecture analysis, complexity assessment, content strategy, module analysis, and cross-module coordination for intelligent documentation hierarchy management.
|
||||
|
||||
## DMS Architecture Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{project_patterns} @{module_patterns}
|
||||
|
||||
Context: DMS architecture analysis for @{project_patterns}
|
||||
Module structure: @{module_patterns}
|
||||
Guidelines: Project standards from @{claude_context}
|
||||
|
||||
Analyze {target} hierarchical documentation structure:
|
||||
1. Project complexity assessment (file count, LOC, tech stack diversity)
|
||||
2. Module responsibility boundaries and architectural patterns
|
||||
3. Cross-module dependencies and integration points
|
||||
4. Technology stack analysis and framework usage patterns
|
||||
5. Content hierarchy strategy (depth 0-2 classification)
|
||||
|
||||
Provide intelligent classification recommendations with hierarchy mapping."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Project structure analysis for DMS hierarchy
|
||||
def dms_architecture_analysis(target_path):
|
||||
context = build_intelligent_context(
|
||||
user_input=f"DMS architecture analysis for {target_path}",
|
||||
analysis_type="architecture",
|
||||
domains=['dms', 'documentation'],
|
||||
tech_stack=detect_project_tech_stack(target_path)
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{{target_path}/**/*}} @{{**/*CLAUDE.md}}
|
||||
@{{CLAUDE.md,**/*CLAUDE.md,.claude/*/CLAUDE.md}}
|
||||
|
||||
Analyze project structure for DMS hierarchy optimization:
|
||||
- Project complexity: file count, lines of code, technology diversity
|
||||
- Module boundaries: logical groupings, responsibility separation
|
||||
- Cross-dependencies: integration patterns, shared utilities
|
||||
- Documentation needs: complexity-based hierarchy requirements
|
||||
- Content differentiation: level-specific focus areas
|
||||
- Classification thresholds: >3 files or >300 LOC triggers
|
||||
|
||||
Provide smart hierarchy recommendations with classification rationale."
|
||||
"""
|
||||
```
|
||||
|
||||
## DMS Complexity Assessment
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{assessment_patterns} @{technology_patterns}
|
||||
|
||||
Context: DMS complexity assessment at @{assessment_patterns}
|
||||
Technology stack: @{technology_patterns}
|
||||
Guidelines: Classification rules from @{claude_context}
|
||||
|
||||
Evaluate {target} for intelligent DMS classification:
|
||||
1. File count analysis and logical grouping assessment
|
||||
2. Lines of code distribution and complexity indicators
|
||||
3. Technology stack diversity and integration complexity
|
||||
4. Cross-module dependencies and architectural coupling
|
||||
5. Documentation requirements based on complexity metrics
|
||||
|
||||
Provide classification recommendations with threshold justification."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Project complexity evaluation for smart classification
|
||||
def dms_complexity_assessment(project_scope):
|
||||
context = build_intelligent_context(
|
||||
user_input=f"Complexity assessment for {project_scope}",
|
||||
analysis_type="quality",
|
||||
domains=['dms', 'classification'],
|
||||
project_info=analyze_project_structure(project_scope)
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{{project_scope}}} @{{package*.json,requirements.txt,pom.xml}}
|
||||
@{{CLAUDE.md,**/CLAUDE.md}}
|
||||
|
||||
Assess project complexity for DMS classification:
|
||||
- Single-file detection: 1-2 files → consolidated documentation
|
||||
- Simple project: 3-10 files, <800 LOC → minimal hierarchy
|
||||
- Medium project: 11-100 files, 800-3000 LOC → selective hierarchy
|
||||
- Complex project: >100 files, >3000 LOC → full hierarchy
|
||||
- Technology stack: framework diversity impact on documentation needs
|
||||
- Integration complexity: cross-module dependency analysis
|
||||
|
||||
Recommend optimal DMS structure with classification thresholds."
|
||||
"""
|
||||
```
|
||||
|
||||
## DMS Content Strategy
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{content_patterns} @{reference_patterns}
|
||||
|
||||
Context: DMS content strategy for @{content_patterns}
|
||||
Reference patterns: @{reference_patterns}
|
||||
Guidelines: Content standards from @{claude_context}
|
||||
|
||||
Develop {target} content differentiation strategy:
|
||||
1. Level-specific content focus and responsibility boundaries
|
||||
2. Content hierarchy optimization and redundancy elimination
|
||||
3. Implementation pattern identification and documentation priorities
|
||||
4. Cross-level content flow and reference strategies
|
||||
5. Quality standards and actionable guideline emphasis
|
||||
|
||||
Provide content strategy with level-specific focus areas."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Content strategy for hierarchical documentation
|
||||
def dms_content_strategy(hierarchy_levels):
|
||||
context = build_intelligent_context(
|
||||
user_input=f"Content strategy for {len(hierarchy_levels)} levels",
|
||||
analysis_type="quality",
|
||||
domains=['dms', 'content', 'hierarchy'],
|
||||
levels_info=hierarchy_levels
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/*.{{js,ts,jsx,tsx,py,java}}}} @{{**/CLAUDE.md}}
|
||||
@{{CLAUDE.md,.claude/*/CLAUDE.md}}
|
||||
|
||||
Develop content differentiation strategy:
|
||||
- Depth 0 (Project): Architecture, tech stack, global standards
|
||||
- Depth 1 (Module): Module patterns, integration, responsibilities
|
||||
- Depth 2 (Implementation): Details, gotchas, specific guidelines
|
||||
- Content consolidation: Merge depth 3+ content into depth 2
|
||||
- Redundancy elimination: Unique focus per level
|
||||
- Non-obvious priority: Essential decisions, actionable patterns
|
||||
|
||||
Provide level-specific content guidelines with focus differentiation."
|
||||
"""
|
||||
```
|
||||
|
||||
## DMS Module Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{module_patterns} @{integration_patterns}
|
||||
|
||||
Context: DMS module analysis for @{module_patterns}
|
||||
Integration context: @{integration_patterns}
|
||||
Guidelines: Module standards from @{claude_context}
|
||||
|
||||
Analyze {target} module-specific documentation needs:
|
||||
1. Module responsibility boundaries and architectural role
|
||||
2. Internal implementation patterns and conventions
|
||||
3. External integration points and dependency management
|
||||
4. Module-specific quality standards and best practices
|
||||
5. Documentation depth requirements based on complexity
|
||||
|
||||
Provide module documentation strategy with integration focus."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Module-specific analysis for targeted documentation
|
||||
def dms_module_analysis(module_path):
|
||||
context = build_intelligent_context(
|
||||
user_input=f"Module analysis for {module_path}",
|
||||
analysis_type="architecture",
|
||||
domains=['dms', 'module'],
|
||||
module_info=analyze_module_structure(module_path)
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{{module_path}/**/*}} @{{**/*{module_path.split('/')[-1]}*}}
|
||||
@{{CLAUDE.md,{module_path}/CLAUDE.md}}
|
||||
|
||||
Analyze module for documentation strategy:
|
||||
- Module boundaries: responsibility scope, architectural role
|
||||
- Implementation patterns: internal conventions, code organization
|
||||
- Integration points: external dependencies, API contracts
|
||||
- Quality standards: module-specific testing, validation patterns
|
||||
- Complexity indicators: >3 files or >300 LOC → dedicated CLAUDE.md
|
||||
- Documentation depth: implementation details vs architectural overview
|
||||
|
||||
Recommend module documentation approach with depth justification."
|
||||
"""
|
||||
```
|
||||
|
||||
## DMS Cross-Module Analysis
|
||||
|
||||
### Template Structure
|
||||
```bash
|
||||
gemini --all-files -p "@{cross_module_patterns} @{dependency_patterns}
|
||||
|
||||
Context: DMS cross-module analysis for @{cross_module_patterns}
|
||||
Dependencies: @{dependency_patterns}
|
||||
Guidelines: Integration standards from @{claude_context}
|
||||
|
||||
Analyze {target} cross-module documentation requirements:
|
||||
1. Inter-module dependency mapping and communication patterns
|
||||
2. Shared utility identification and documentation consolidation
|
||||
3. Integration complexity assessment and documentation depth
|
||||
4. Cross-cutting concern identification and hierarchy placement
|
||||
5. Documentation coordination strategy across module boundaries
|
||||
|
||||
Provide cross-module documentation strategy with integration focus."
|
||||
```
|
||||
|
||||
### Intelligent Usage Examples
|
||||
```python
|
||||
# Cross-module analysis for integration documentation
|
||||
def dms_cross_module_analysis(affected_modules):
|
||||
context = build_intelligent_context(
|
||||
user_input=f"Cross-module analysis for {len(affected_modules)} modules",
|
||||
analysis_type="architecture",
|
||||
domains=['dms', 'integration', 'modules'],
|
||||
modules_info=affected_modules
|
||||
)
|
||||
|
||||
module_patterns = ','.join([f"{m}/**/*" for m in affected_modules])
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{{module_patterns}}} @{{**/shared/**/*,**/common/**/*}}
|
||||
@{{CLAUDE.md,**/CLAUDE.md}}
|
||||
|
||||
Analyze cross-module integration for documentation:
|
||||
- Dependency mapping: module interdependencies, communication flow
|
||||
- Shared patterns: common utilities, cross-cutting concerns
|
||||
- Integration complexity: >5 modules → enhanced coordination documentation
|
||||
- Documentation coordination: avoid redundancy across module boundaries
|
||||
- Hierarchy placement: integration patterns at appropriate depth levels
|
||||
- Reference strategies: cross-module links and shared guideline access
|
||||
|
||||
Provide integration documentation strategy with coordination guidelines."
|
||||
"""
|
||||
```
|
||||
|
||||
## DMS Classification Matrix
|
||||
|
||||
### Project Complexity Thresholds
|
||||
|
||||
| Complexity Level | File Count | Lines of Code | Tech Stack | Hierarchy Strategy |
|
||||
|------------------|------------|---------------|------------|-------------------|
|
||||
| **Single File** | 1-2 files | <300 LOC | 1 technology | Consolidated docs |
|
||||
| **Simple** | 3-10 files | 300-800 LOC | 1-2 technologies | Minimal hierarchy |
|
||||
| **Medium** | 11-100 files | 800-3000 LOC | 2-3 technologies | Selective hierarchy |
|
||||
| **Complex** | >100 files | >3000 LOC | >3 technologies | Full hierarchy |
|
||||
|
||||
### Documentation Depth Strategy
|
||||
|
||||
| Depth Level | Focus Areas | Content Types | Triggers |
|
||||
|-------------|-------------|---------------|----------|
|
||||
| **Depth 0 (Project)** | Architecture, global standards, tech stack overview | High-level patterns, system design | Always present |
|
||||
| **Depth 1 (Module)** | Module patterns, integration points, responsibilities | Interface contracts, module APIs | >3 files or >300 LOC |
|
||||
| **Depth 2 (Implementation)** | Implementation details, gotchas, specific guidelines | Code patterns, edge cases | Complex modules |
|
||||
|
||||
## Integration with Intelligent Context
|
||||
|
||||
All DMS templates integrate with @~/.claude/workflows/gemini-intelligent-context.md for:
|
||||
|
||||
- **Smart Project Classification** - Automatic complexity assessment based on project metrics
|
||||
- **Module Boundary Detection** - Intelligent identification of logical module groupings
|
||||
- **Hierarchy Optimization** - Content differentiation strategies across documentation levels
|
||||
- **Cross-Module Coordination** - Integration pattern analysis for documentation coordination
|
||||
|
||||
## Template Usage Guidelines
|
||||
|
||||
1. **Assess Project Complexity First** - Use complexity assessment to determine appropriate hierarchy
|
||||
2. **Apply Classification Thresholds** - Follow established metrics for documentation depth decisions
|
||||
3. **Coordinate Across Modules** - Use cross-module analysis for integration documentation
|
||||
4. **Optimize Content Differentiation** - Ensure unique focus areas for each hierarchy level
|
||||
5. **Validate Documentation Strategy** - Check hierarchy alignment with project structure
|
||||
|
||||
These DMS-specific templates enable intelligent documentation hierarchy management and content optimization for distributed memory systems.
|
||||
@@ -1,225 +0,0 @@
|
||||
# Gemini Intelligent Context System
|
||||
|
||||
**Smart context detection and file targeting system for Gemini CLI analysis.**
|
||||
|
||||
## Overview
|
||||
|
||||
The intelligent context system automatically resolves file paths and context based on user input, analysis type, and project structure detection, enabling precise and efficient codebase analysis.
|
||||
|
||||
## Smart Path Detection
|
||||
|
||||
### Technology Stack Detection
|
||||
|
||||
```python
|
||||
def detect_technology_stack(project_path):
|
||||
"""Detect technologies used in the project"""
|
||||
indicators = {
|
||||
'React': ['package.json contains react', '**/*.jsx', '**/*.tsx'],
|
||||
'Vue': ['package.json contains vue', '**/*.vue'],
|
||||
'Angular': ['angular.json', '**/*.component.ts'],
|
||||
'Node.js': ['package.json', 'server.js', 'app.js'],
|
||||
'Python': ['requirements.txt', '**/*.py', 'setup.py'],
|
||||
'Java': ['pom.xml', '**/*.java', 'build.gradle'],
|
||||
'TypeScript': ['tsconfig.json', '**/*.ts'],
|
||||
'Express': ['package.json contains express'],
|
||||
'FastAPI': ['**/*main.py', 'requirements.txt contains fastapi'],
|
||||
'Spring': ['pom.xml contains spring', '**/*Application.java']
|
||||
}
|
||||
return analyze_indicators(indicators, project_path)
|
||||
```
|
||||
|
||||
### Project Structure Detection
|
||||
|
||||
```python
|
||||
def detect_project_structure(project_path):
|
||||
"""Identify common project patterns"""
|
||||
patterns = {
|
||||
'src_based': has_directory('src/'),
|
||||
'lib_based': has_directory('lib/'),
|
||||
'app_based': has_directory('app/'),
|
||||
'modules_based': has_directory('modules/'),
|
||||
'packages_based': has_directory('packages/'),
|
||||
'microservices': has_multiple_services(),
|
||||
'monorepo': has_workspaces_or_lerna()
|
||||
}
|
||||
return analyze_structure_patterns(patterns)
|
||||
```
|
||||
|
||||
### Domain Context Detection
|
||||
|
||||
```python
|
||||
def extract_domain_keywords(user_input):
|
||||
"""Extract domain-specific keywords for smart targeting"""
|
||||
domain_mapping = {
|
||||
'auth': ['authentication', 'login', 'session', 'auth', 'oauth', 'jwt', 'token'],
|
||||
'api': ['api', 'endpoint', 'route', 'controller', 'service'],
|
||||
'frontend': ['component', 'ui', 'view', 'react', 'vue', 'angular'],
|
||||
'backend': ['server', 'backend', 'api', 'database', 'model'],
|
||||
'database': ['database', 'db', 'model', 'query', 'migration', 'schema'],
|
||||
'security': ['security', 'vulnerability', 'xss', 'csrf', 'injection'],
|
||||
'performance': ['performance', 'slow', 'optimization', 'bottleneck'],
|
||||
'testing': ['test', 'spec', 'mock', 'unit', 'integration', 'e2e'],
|
||||
'state': ['state', 'redux', 'context', 'store', 'vuex'],
|
||||
'config': ['config', 'environment', 'settings', 'env']
|
||||
}
|
||||
return match_domains(user_input.lower(), domain_mapping)
|
||||
```
|
||||
|
||||
## Intelligent File Targeting
|
||||
|
||||
### Context-Aware Path Generation
|
||||
|
||||
| Domain Context | Generated File Patterns |
|
||||
|----------------|------------------------|
|
||||
| **Authentication** | `@{**/*auth*,**/*login*,**/*session*,**/middleware/*auth*,**/guards/**/*}` |
|
||||
| **API Endpoints** | `@{**/api/**/*,**/routes/**/*,**/controllers/**/*,**/handlers/**/*}` |
|
||||
| **Frontend Components** | `@{src/components/**/*,src/ui/**/*,src/views/**/*,components/**/*}` |
|
||||
| **Database Layer** | `@{**/models/**/*,**/db/**/*,**/migrations/**/*,**/repositories/**/*}` |
|
||||
| **State Management** | `@{**/store/**/*,**/redux/**/*,**/context/**/*,**/state/**/*}` |
|
||||
| **Configuration** | `@{*.config.*,**/config/**/*,.env*,**/settings/**/*}` |
|
||||
| **Testing** | `@{**/*.test.*,**/*.spec.*,**/test/**/*,**/spec/**/*,**/__tests__/**/*}` |
|
||||
| **Security** | `@{**/*security*,**/*auth*,**/*crypto*,**/middleware/**/*}` |
|
||||
| **Performance** | `@{**/core/**/*,**/services/**/*,**/utils/**/*,**/lib/**/*}` |
|
||||
|
||||
### Technology-Specific Extensions
|
||||
|
||||
```python
|
||||
def get_tech_extensions(technology_stack):
|
||||
"""Get relevant file extensions based on detected technologies"""
|
||||
extension_mapping = {
|
||||
'React': ['.jsx', '.tsx', '.js', '.ts'],
|
||||
'Vue': ['.vue', '.js', '.ts'],
|
||||
'Angular': ['.component.ts', '.service.ts', '.module.ts'],
|
||||
'Node.js': ['.js', '.ts', '.mjs'],
|
||||
'Python': ['.py', '.pyx', '.pyi'],
|
||||
'Java': ['.java', '.kt', '.scala'],
|
||||
'TypeScript': ['.ts', '.tsx', '.d.ts'],
|
||||
'CSS': ['.css', '.scss', '.sass', '.less', '.styl']
|
||||
}
|
||||
return build_extension_patterns(technology_stack, extension_mapping)
|
||||
```
|
||||
|
||||
## Dynamic Context Enhancement
|
||||
|
||||
### Smart Prompt Construction
|
||||
|
||||
```python
|
||||
def build_intelligent_context(user_input, analysis_type, project_info):
|
||||
"""Build context-aware Gemini CLI prompt"""
|
||||
|
||||
# Step 1: Detect domains and technologies
|
||||
domains = extract_domain_keywords(user_input)
|
||||
tech_stack = project_info.technology_stack
|
||||
|
||||
# Step 2: Generate smart file patterns
|
||||
file_patterns = generate_file_patterns(domains, tech_stack, analysis_type)
|
||||
|
||||
# Step 3: Include relevant CLAUDE.md contexts
|
||||
claude_patterns = generate_claude_patterns(domains, project_info.structure)
|
||||
|
||||
# Step 4: Build context-enriched prompt
|
||||
return construct_enhanced_prompt(
|
||||
base_prompt=user_input,
|
||||
file_patterns=file_patterns,
|
||||
claude_context=claude_patterns,
|
||||
analysis_focus=get_analysis_focus(analysis_type),
|
||||
tech_context=tech_stack
|
||||
)
|
||||
```
|
||||
|
||||
### Context Validation and Fallbacks
|
||||
|
||||
```python
|
||||
def validate_and_fallback_context(generated_patterns, project_path):
|
||||
"""Ensure generated patterns match actual project structure"""
|
||||
validated_patterns = []
|
||||
|
||||
for pattern in generated_patterns:
|
||||
if has_matching_files(pattern, project_path):
|
||||
validated_patterns.append(pattern)
|
||||
else:
|
||||
# Try fallback patterns
|
||||
fallback = generate_fallback_pattern(pattern, project_path)
|
||||
if fallback:
|
||||
validated_patterns.append(fallback)
|
||||
|
||||
return validated_patterns or get_generic_patterns(project_path)
|
||||
```
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Command Integration Examples
|
||||
|
||||
```python
|
||||
def gather_gemini_insights(user_input, base_enhancement):
|
||||
# Use intelligent context system
|
||||
context = build_intelligent_context(
|
||||
user_input=user_input,
|
||||
analysis_type=determine_analysis_type(base_enhancement),
|
||||
project_info=get_project_info()
|
||||
)
|
||||
|
||||
# Select appropriate template
|
||||
template = select_template(base_enhancement.complexity, base_enhancement.domains)
|
||||
|
||||
# Execute with enhanced context
|
||||
return execute_template(template, context)
|
||||
```
|
||||
|
||||
### Agent Workflow Integration
|
||||
|
||||
```python
|
||||
# Before agent execution, collect enhanced context
|
||||
def collect_enhanced_gemini_context(task_description):
|
||||
domains = extract_domain_keywords(task_description)
|
||||
analysis_types = determine_required_analysis(domains)
|
||||
|
||||
context_results = {}
|
||||
for analysis_type in analysis_types:
|
||||
# Use appropriate template file based on analysis type
|
||||
if analysis_type.startswith('dms'):
|
||||
template_path = f"workflows/gemini-dms-templates.md#{analysis_type}"
|
||||
elif analysis_type in ['planning-agent-context', 'code-developer-context', 'code-review-context', 'ui-design-context']:
|
||||
template_path = f"workflows/gemini-agent-templates.md#{analysis_type}"
|
||||
else:
|
||||
template_path = f"workflows/gemini-core-templates.md#{analysis_type}"
|
||||
|
||||
context_results[analysis_type] = execute_template_by_reference(
|
||||
template_path,
|
||||
task_description
|
||||
)
|
||||
|
||||
return consolidate_context(context_results)
|
||||
```
|
||||
|
||||
### Smart Template Selection
|
||||
|
||||
```python
|
||||
def select_optimal_template(task_complexity, domains, tech_stack):
|
||||
template_matrix = {
|
||||
('simple', ['frontend']): 'pattern-analysis',
|
||||
('medium', ['frontend', 'api']): ['pattern-analysis', 'architecture-analysis'],
|
||||
('complex', ['security', 'auth']): ['security-analysis', 'architecture-analysis', 'quality-analysis'],
|
||||
('critical', ['payment', 'crypto']): ['security-analysis', 'performance-analysis', 'dependencies-analysis']
|
||||
}
|
||||
|
||||
return template_matrix.get((task_complexity, sorted(domains)), ['pattern-analysis'])
|
||||
```
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
1. **Scope file patterns appropriately** - Too broad patterns slow analysis
|
||||
2. **Use technology-specific extensions** - More precise targeting improves results
|
||||
3. **Implement pattern validation** - Check patterns match files before execution
|
||||
4. **Consider project size** - Large projects may need pattern chunking
|
||||
|
||||
### Maintenance
|
||||
|
||||
1. **Update templates regularly** - Keep pace with new technologies and patterns
|
||||
2. **Validate anchor links** - Ensure cross-references remain accurate
|
||||
3. **Test intelligent context** - Verify smart targeting works across project types
|
||||
4. **Monitor template performance** - Track analysis quality and speed
|
||||
|
||||
This intelligent context system provides the foundation for all Gemini CLI analysis, ensuring efficient and precise codebase understanding across different commands and agents.
|
||||
@@ -1,72 +0,0 @@
|
||||
# Gemini Memory-Gemini-Bridge Template
|
||||
|
||||
**Purpose**: Comprehensive project structure analysis for hierarchical CLAUDE.md documentation generation
|
||||
|
||||
## Template Structure
|
||||
|
||||
```bash
|
||||
gemini --all-files -p "@{**/*} @{CLAUDE.md,**/*CLAUDE.md} @{package*.json,requirements.txt,pom.xml,Cargo.toml}
|
||||
|
||||
Project structure analysis for Memory-Gemini-Bridge documentation generation:
|
||||
Target: [project-name or specific scope]
|
||||
|
||||
## Required Analysis:
|
||||
1. **Project Architecture Assessment**:
|
||||
- Overall system structure and module organization
|
||||
- Technology stack diversity and integration complexity
|
||||
- Existing CLAUDE.md hierarchy and content gaps
|
||||
- Directory structure patterns and logical groupings
|
||||
|
||||
2. **Documentation Hierarchy Strategy**:
|
||||
- Identify optimal CLAUDE.md placement levels (root, module, sub-module)
|
||||
- Determine content differentiation across hierarchy levels
|
||||
- Assess complexity thresholds for documentation depth
|
||||
- Map existing documentation patterns and standards
|
||||
|
||||
3. **Cross-System Integration Analysis**:
|
||||
- Claude-Gemini compatibility requirements
|
||||
- Cross-system documentation synchronization patterns
|
||||
- Template and guideline reference patterns
|
||||
- Memory system synchronization needs
|
||||
|
||||
4. **Module Responsibility Mapping**:
|
||||
- Core module identification and purpose analysis
|
||||
- Inter-module dependencies and integration patterns
|
||||
- Component organization and architectural boundaries
|
||||
- Implementation pattern consistency across modules
|
||||
|
||||
5. **Technology Stack Integration**:
|
||||
- Framework usage patterns and configuration analysis
|
||||
- Build system and development workflow patterns
|
||||
- Testing architecture and quality standards
|
||||
- Deployment and infrastructure considerations
|
||||
|
||||
## Output Requirements:
|
||||
- **Hierarchy Recommendation**: Specific CLAUDE.md file structure with rationale
|
||||
- **Content Strategy**: Level-specific focus areas and content differentiation
|
||||
- **Template Selection**: Appropriate DMS and core templates for analysis
|
||||
- **Integration Plan**: Workflow coordination with update-memory and agent systems
|
||||
- **Quality Standards**: Cross-system compatibility and maintenance guidelines
|
||||
|
||||
Focus on architectural understanding for documentation strategy rather than implementation details."
|
||||
```
|
||||
|
||||
## Context Application
|
||||
|
||||
- Generate hierarchical documentation strategy based on project structure
|
||||
- Create comprehensive CLAUDE.md files with appropriate content depth
|
||||
- Ensure cross-system compatibility between Claude and Gemini CLI
|
||||
- Establish maintainable documentation patterns for ongoing development
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
**Use Memory-Gemini-Bridge template when**:
|
||||
- Creating or updating CLAUDE.md files for Gemini CLI compatibility
|
||||
- Establishing hierarchical documentation strategy for complex projects
|
||||
- Synchronizing memory systems between Claude and Gemini CLI
|
||||
|
||||
**Template focuses on**:
|
||||
- Comprehensive project structure analysis
|
||||
- Documentation hierarchy strategy and content differentiation
|
||||
- Cross-system integration analysis for Claude-Gemini compatibility
|
||||
- Architectural understanding for documentation strategy rather than implementation details
|
||||
@@ -1,91 +0,0 @@
|
||||
# Gemini Planning Agent Template
|
||||
|
||||
**Purpose**: Identify specific task scope, affected files, and concrete implementation plan
|
||||
|
||||
## Template Structure
|
||||
|
||||
```bash
|
||||
gemini --all-files -p "@{[task-related-files]} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
|
||||
Task-specific planning analysis for: [exact task description]
|
||||
|
||||
## Required Analysis:
|
||||
1. **Task Scope Identification**:
|
||||
- What exactly needs to be built/modified/fixed?
|
||||
- Which specific components, files, or modules are affected?
|
||||
- What is the precise deliverable?
|
||||
|
||||
2. **File and Modification Mapping**:
|
||||
- List exact files that need modification (with file:line references where possible)
|
||||
- Identify specific functions, classes, or components to change
|
||||
- Find configuration files, tests, or documentation that need updates
|
||||
|
||||
3. **Dependencies and Integration Points**:
|
||||
- What modules/services depend on the changes?
|
||||
- What external APIs, databases, or services are involved?
|
||||
- Which existing functions will need to call the new code?
|
||||
|
||||
4. **Risk and Complexity Assessment**:
|
||||
- What could break from these changes?
|
||||
- Are there critical paths that need special testing?
|
||||
- What rollback strategy is needed?
|
||||
|
||||
5. **Implementation Sequence**:
|
||||
- What order should changes be made in?
|
||||
- Which changes are prerequisites for others?
|
||||
- What can be done in parallel?
|
||||
|
||||
## Output Requirements:
|
||||
- **Concrete file list**: Exact files to modify with reasons
|
||||
- **Specific entry points**: Functions/classes that need changes with line references
|
||||
- **Clear sequence**: Step-by-step implementation order
|
||||
- **Risk mitigation**: Specific testing requirements and rollback plans
|
||||
- **Success criteria**: How to verify each step works
|
||||
|
||||
Focus on actionable, specific guidance rather than general patterns."
|
||||
```
|
||||
|
||||
## Intelligent Usage Examples
|
||||
|
||||
```python
|
||||
# API endpoint planning
|
||||
def planning_agent_context(user_input):
|
||||
context = build_intelligent_context(
|
||||
user_input="Add user profile management API",
|
||||
analysis_type="planning-agent-context",
|
||||
domains=['api', 'backend', 'database'],
|
||||
tech_stack=['Node.js', 'Express', 'PostgreSQL']
|
||||
)
|
||||
|
||||
return f"""
|
||||
gemini --all-files -p "@{{**/api/**/*,**/routes/**/*,**/controllers/**/*}}
|
||||
@{{**/models/**/*,**/db/**/*}} @{{CLAUDE.md,api/CLAUDE.md,backend/CLAUDE.md}}
|
||||
|
||||
Task-specific planning analysis for: Add user profile management API endpoints
|
||||
- Profile creation, update, retrieval, deletion endpoints
|
||||
- User avatar upload and management
|
||||
- Profile privacy settings and visibility controls
|
||||
|
||||
Focus on exact file modification points and implementation sequence."
|
||||
"""
|
||||
```
|
||||
|
||||
## Context Application
|
||||
|
||||
- Create detailed, file-specific implementation plan
|
||||
- Identify exact modification points with line references
|
||||
- Establish concrete success criteria for each stage
|
||||
- Plan specific testing and validation steps
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
**Use Planning Agent template when**:
|
||||
- Before creating implementation plans for specific features or fixes
|
||||
- You need to understand exact scope and modification points
|
||||
- Focus on concrete deliverables rather than architectural overviews
|
||||
|
||||
**Template focuses on**:
|
||||
- Task-specific analysis targeting exact requirements
|
||||
- Actionable output with specific file:line references
|
||||
- Repository context extracting patterns specific to the actual codebase
|
||||
- Precise scope analyzing only what's needed for the immediate task
|
||||
269
.claude/workflows/gemini-templates/commands/context-analysis.md
Normal file
269
.claude/workflows/gemini-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/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
|
||||
# 组合多个模板
|
||||
gemini -p "@{src/**/*} $(cat <<'EOF'
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt)
|
||||
|
||||
Additional focus:
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/quality.txt)
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
### 条件模板选择
|
||||
```bash
|
||||
# 基于项目特征动态选择模板
|
||||
if [ -f "package.json" ] && grep -q "react" package.json; then
|
||||
TEMPLATE="~/.claude/workflows/gemini-templates/prompts/tech/react-component.txt"
|
||||
elif [ -f "requirements.txt" ]; then
|
||||
TEMPLATE="~/.claude/workflows/gemini-templates/prompts/tech/python-api.txt"
|
||||
else
|
||||
TEMPLATE="~/.claude/workflows/gemini-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/gemini-templates/commands/folder-analysis.md
Normal file
410
.claude/workflows/gemini-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层，从数据模型到配置管理，确保每种目录类型都能得到最适合的分析方式。
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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,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.
|
||||
373
.claude/workflows/gemini-unified.md
Normal file
373
.claude/workflows/gemini-unified.md
Normal file
@@ -0,0 +1,373 @@
|
||||
---
|
||||
name: gemini-unified
|
||||
description: Consolidated Gemini CLI guidelines - core rules, syntax, patterns, templates, and best practices
|
||||
type: technical-guideline
|
||||
---
|
||||
|
||||
# Unified Gemini CLI Guidelines
|
||||
|
||||
## 🚀 Core Rules
|
||||
|
||||
### When to Trigger
|
||||
- **Semantic Intent**: User asks to "analyze with Gemini", "get context", or "understand codebase"
|
||||
- **Context Need**: Task requires understanding multiple files or relationships
|
||||
- **Complex Analysis**: Problem exceeds single-file scope
|
||||
|
||||
### Primary Use Cases
|
||||
- Project context acquisition and codebase understanding
|
||||
- Pattern detection and architectural analysis
|
||||
- Standards extraction and convention identification
|
||||
|
||||
### Standard Template Structure
|
||||
|
||||
#### Basic Structure (Manual Prompts)
|
||||
```bash
|
||||
gemini --all-files -p "@{target_patterns} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
|
||||
Context: [Analysis type] targeting @{target_patterns}
|
||||
Guidelines: Include CLAUDE.md standards
|
||||
|
||||
## Analysis:
|
||||
1. [Point 1]
|
||||
2. [Point 2]
|
||||
3. [Point 3]
|
||||
|
||||
## Output:
|
||||
- File:line references
|
||||
- Code examples
|
||||
- Actionable guidance
|
||||
- Standards compliance"
|
||||
```
|
||||
|
||||
#### Template-Enhanced Structure (Recommended)
|
||||
```bash
|
||||
# Using predefined templates for consistent analysis
|
||||
gemini --all-files -p "@{target_patterns} @{CLAUDE.md,**/*CLAUDE.md}
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/[category]/[template].txt)"
|
||||
```
|
||||
|
||||
#### Template Reference Examples
|
||||
```bash
|
||||
# Pattern analysis with template
|
||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
|
||||
# Architecture analysis with template
|
||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt)"
|
||||
|
||||
# Multi-template composition
|
||||
gemini -p "@{src/**/*} @{CLAUDE.md} $(cat <<'EOF'
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)
|
||||
|
||||
Additional Security Focus:
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/security.txt)
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
**Template Benefits:**
|
||||
- **Consistency**: Standardized analysis structure across all uses
|
||||
- **Completeness**: Pre-defined analysis points ensure comprehensive coverage
|
||||
- **Quality**: Proven analysis frameworks with specific output requirements
|
||||
- **Efficiency**: No need to manually construct analysis prompts
|
||||
|
||||
**Mandatory**: Always include `@{CLAUDE.md,**/*CLAUDE.md}` for project standards.
|
||||
|
||||
## ⚙️ Command Syntax
|
||||
|
||||
### Basic Structure
|
||||
```bash
|
||||
gemini [flags] -p "@{patterns} prompt"
|
||||
```
|
||||
|
||||
### Key Arguments
|
||||
- `--all-files`: Includes all files in current directory (path-dependent)
|
||||
- `-p`: Prompt string with file patterns and query
|
||||
- `@{pattern}`: File reference pattern
|
||||
|
||||
### Execution Modes
|
||||
|
||||
#### 1. Directory-Scoped
|
||||
Navigate first, then execute:
|
||||
```bash
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md} Analyze patterns"
|
||||
```
|
||||
|
||||
#### 2. Pattern-Based
|
||||
Target files directly:
|
||||
```bash
|
||||
gemini -p "@{src/components/**/*} @{CLAUDE.md} Component analysis"
|
||||
```
|
||||
|
||||
#### 3. Template-Injected
|
||||
Use `$(cat)` for templates:
|
||||
```bash
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
```
|
||||
|
||||
#### 4. Parallel Execution
|
||||
Multiple analyses concurrently:
|
||||
```bash
|
||||
(
|
||||
gemini -p "@{**/*auth*} @{CLAUDE.md} Auth patterns" &
|
||||
gemini -p "@{**/api/**/*} @{CLAUDE.md} API patterns" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
## 📂 File Patterns
|
||||
|
||||
### Pattern Syntax
|
||||
```bash
|
||||
@{pattern} # Single pattern
|
||||
@{pattern1,pattern2} # Multiple patterns
|
||||
```
|
||||
|
||||
### Wildcards
|
||||
```bash
|
||||
* # Any character (not path separators)
|
||||
** # Any directory levels
|
||||
? # Single character
|
||||
[abc] # Character in brackets
|
||||
{a,b,c} # Any option in braces
|
||||
```
|
||||
|
||||
### Frontend Patterns
|
||||
```bash
|
||||
# React
|
||||
@{src/components/**/*.{jsx,tsx}}
|
||||
@{src/hooks/**/*.{js,ts}}
|
||||
@{src/context/**/*.{jsx,tsx}}
|
||||
|
||||
# Vue
|
||||
@{src/components/**/*.vue}
|
||||
@{src/composables/**/*.{js,ts}}
|
||||
|
||||
# Angular
|
||||
@{src/app/**/*.component.{ts,html}}
|
||||
@{src/app/**/*.service.ts}
|
||||
```
|
||||
|
||||
### Backend Patterns
|
||||
```bash
|
||||
# Node.js
|
||||
@{routes/**/*.js,controllers/**/*.js}
|
||||
@{middleware/**/*.js}
|
||||
@{models/**/*.js}
|
||||
|
||||
# Python
|
||||
@{**/views.py,**/models.py,**/urls.py}
|
||||
@{**/serializers.py}
|
||||
|
||||
# Java
|
||||
@{**/*Controller.java}
|
||||
@{**/*Service.java,**/*Repository.java}
|
||||
```
|
||||
|
||||
### Config & Testing
|
||||
```bash
|
||||
# Configuration
|
||||
@{*.config.{js,ts},**/*.config.*}
|
||||
@{package.json,yarn.lock}
|
||||
@{Dockerfile,docker-compose.yml}
|
||||
|
||||
# Tests
|
||||
@{**/*.test.{js,ts,jsx,tsx}}
|
||||
@{**/*.spec.{js,ts}}
|
||||
@{**/__tests__/**/*}
|
||||
|
||||
# Documentation
|
||||
@{**/*.md,**/README*}
|
||||
@{**/*.d.ts,**/types/**/*.ts}
|
||||
```
|
||||
|
||||
### Domain Patterns
|
||||
```bash
|
||||
# Auth & Security
|
||||
@{**/*auth*,**/*login*,**/*session*}
|
||||
@{**/*permission*,**/*role*}
|
||||
@{**/*crypto*,**/*hash*}
|
||||
|
||||
# API & Data
|
||||
@{**/api/**/*,**/routes/**/*}
|
||||
@{**/controllers/**/*,**/handlers/**/*}
|
||||
@{**/models/**/*,**/entities/**/*}
|
||||
|
||||
# UI & Styling
|
||||
@{src/components/**/*,src/ui/**/*}
|
||||
@{src/styles/**/*,**/*.{css,scss,sass}}
|
||||
@{src/layouts/**/*}
|
||||
```
|
||||
|
||||
### Cross-Platform Rules
|
||||
- Always use forward slashes: `@{src/components/**/*}`
|
||||
- Quote paths with spaces: `@{"My Project/src/**/*"}`
|
||||
- Escape special chars: `@{src/**/*\[bracket\]*}`
|
||||
|
||||
## 📋 Template System
|
||||
|
||||
### Template Categories and Functions
|
||||
|
||||
#### Analysis Templates (`prompts/analysis/`)
|
||||
- **`pattern.txt`** - 分析代码模式、工具库、编码标准和反模式
|
||||
- **`architecture.txt`** - 映射模块依赖、集成点、可扩展性评估
|
||||
- **`security.txt`** - 扫描安全漏洞、认证问题、加密方法
|
||||
- **`performance.txt`** - 识别瓶颈、算法复杂度、缓存策略
|
||||
- **`quality.txt`** - 评估可维护性、技术债务、代码组织
|
||||
|
||||
#### Planning Templates (`prompts/planning/`)
|
||||
- **`task-breakdown.txt`** - 任务分解、依赖关系、工作量估算
|
||||
- **`migration.txt`** - 系统迁移规划、兼容性、风险评估
|
||||
|
||||
#### Implementation Templates (`prompts/implementation/`)
|
||||
- **`component.txt`** - 组件接口设计、状态管理、测试方法
|
||||
|
||||
#### Review Templates (`prompts/review/`)
|
||||
- **`code-review.txt`** - 全面代码审查、质量检查、标准合规
|
||||
|
||||
#### DMS Templates (`prompts/dms/`)
|
||||
- **`hierarchy-analysis.txt`** - 项目复杂度分析、文档结构优化
|
||||
|
||||
### Directory Structure
|
||||
```
|
||||
~/.claude/workflows/gemini-templates/
|
||||
├── prompts/
|
||||
│ ├── analysis/ # Code analysis templates
|
||||
│ │ ├── pattern.txt # ✨ Implementation patterns & conventions
|
||||
│ │ ├── architecture.txt # 🏗️ System architecture & dependencies
|
||||
│ │ ├── security.txt # 🔒 Security vulnerabilities & protection
|
||||
│ │ ├── performance.txt # ⚡ Performance bottlenecks & optimization
|
||||
│ │ └── quality.txt # 📊 Code quality & maintainability
|
||||
│ ├── planning/ # Planning templates
|
||||
│ │ ├── task-breakdown.txt # 📋 Task decomposition & dependencies
|
||||
│ │ └── migration.txt # 🚀 System migration & modernization
|
||||
│ ├── implementation/ # Development templates
|
||||
│ │ └── component.txt # 🧩 Component design & implementation
|
||||
│ ├── review/ # Review templates
|
||||
│ │ └── code-review.txt # ✅ Comprehensive review checklist
|
||||
│ └── dms/ # DMS-specific
|
||||
│ └── hierarchy-analysis.txt # 📚 Documentation structure optimization
|
||||
└── commands/ # Command examples
|
||||
├── context-analysis.md # Complete context gathering examples
|
||||
├── parallel-execution.md # Parallel analysis patterns
|
||||
└── folder-analysis.md # Directory-specific analysis
|
||||
```
|
||||
|
||||
### Template Selection Guide
|
||||
| 任务类型 | 主要模板 | 用途 |
|
||||
|---------|---------|------|
|
||||
| 理解现有代码 | `pattern.txt` | 学习代码库、入职培训 |
|
||||
| 规划新功能 | `task-breakdown.txt` | 功能开发规划 |
|
||||
| 安全审查 | `security.txt` | 安全审计、漏洞评估 |
|
||||
| 性能优化 | `performance.txt` | 性能问题排查 |
|
||||
| 代码质量改进 | `quality.txt` | 重构、技术债务减少 |
|
||||
| 系统现代化 | `migration.txt` | 技术升级、架构变更 |
|
||||
| 组件开发 | `component.txt` | 构建可复用组件 |
|
||||
| 发布前审查 | `code-review.txt` | 发布就绪检查 |
|
||||
|
||||
### Template Usage Examples
|
||||
|
||||
#### Basic Template Usage
|
||||
```bash
|
||||
# Single template - pattern analysis
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
|
||||
# Multi-template composition
|
||||
gemini -p "@{src/**/*} $(cat <<'EOF'
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/architecture.txt)
|
||||
|
||||
Additional Quality Focus:
|
||||
$(cat ~/.claude/workflows/gemini-templates/prompts/analysis/quality.txt)
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
#### Common Use Cases
|
||||
```bash
|
||||
# New feature development workflow
|
||||
gemini -p "@{src/**/*similar*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/planning/task-breakdown.txt)"
|
||||
|
||||
# Security audit
|
||||
gemini -p "@{**/*auth*,**/*login*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/security.txt)"
|
||||
|
||||
# Performance optimization
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/performance.txt)"
|
||||
```
|
||||
|
||||
#### Template Best Practices
|
||||
- **Single Template**: 专注分析、特定问题、时间限制
|
||||
- **Multiple Templates**: 综合审查、复杂项目、全面规划
|
||||
- **Performance**: 合并相关模板到单个命令，使用特定文件模式减少范围
|
||||
|
||||
## 🧠 Intelligent Features
|
||||
|
||||
### Technology Detection
|
||||
```python
|
||||
# Simplified logic
|
||||
indicators = {
|
||||
'React': ['package.json contains react', '**/*.jsx'],
|
||||
'Vue': ['package.json contains vue', '**/*.vue'],
|
||||
'Python': ['requirements.txt', '**/*.py'],
|
||||
'Java': ['pom.xml', '**/*.java']
|
||||
}
|
||||
```
|
||||
|
||||
### Domain Extraction
|
||||
```python
|
||||
# Domain mapping
|
||||
domains = {
|
||||
'auth': ['authentication', 'login', 'session'],
|
||||
'api': ['api', 'endpoint', 'route'],
|
||||
'frontend': ['component', 'ui', 'react'],
|
||||
'backend': ['server', 'database', 'model']
|
||||
}
|
||||
```
|
||||
|
||||
### Fallback Strategy
|
||||
1. **Primary Pattern**: Try user-specified pattern
|
||||
2. **Simplified Pattern**: Remove extensions/specificity
|
||||
3. **Directory Pattern**: Use common directories like `@{src/**/*}`
|
||||
|
||||
### Performance Tips
|
||||
- Avoid patterns matching >1000 files
|
||||
- Use directory-scoped execution for large projects
|
||||
- Prefer specific patterns over broad ones
|
||||
- Process large datasets in parallel chunks
|
||||
|
||||
## ⭐ Best Practices
|
||||
|
||||
### Core Principles
|
||||
- **Always include** `@{CLAUDE.md,**/*CLAUDE.md}` for project context
|
||||
- **Be specific** with patterns to reduce scope and improve performance
|
||||
- **Group logically** related patterns in single commands
|
||||
- **Use forward slashes** for cross-platform compatibility
|
||||
|
||||
### Common Patterns
|
||||
```bash
|
||||
# Get project context
|
||||
gemini --all-files -p "@{src/**/*} @{CLAUDE.md} Extract patterns and standards"
|
||||
|
||||
# Domain analysis
|
||||
gemini -p "@{**/*auth*} @{CLAUDE.md} Authentication implementation analysis"
|
||||
|
||||
# Technology-specific
|
||||
gemini -p "@{src/components/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/tech/react-component.txt)"
|
||||
```
|
||||
|
||||
### Error Handling
|
||||
- Validate patterns match files before execution
|
||||
- Use fallback patterns for robustness
|
||||
- Quote paths with spaces or special characters
|
||||
- Test patterns on small subsets first
|
||||
|
||||
### Agent Integration
|
||||
All agent workflows should begin with context analysis:
|
||||
```bash
|
||||
# Mandatory first step
|
||||
gemini --all-files -p "@{relevant_patterns} @{CLAUDE.md} Context for: [task_description]"
|
||||
```
|
||||
|
||||
### Integration References
|
||||
- This unified guide replaces all individual Gemini guideline files
|
||||
- Templates are stored in `~/.claude/workflows/gemini-templates/`
|
||||
- Always reference this file for Gemini CLI usage patterns
|
||||
Reference in New Issue
Block a user