mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-12 02:37:45 +08:00
feat: Add v1.1 update-memory system with dual-mode operations and enhanced documentation
## New Features - **Dual-mode update-memory commands**: /update-memory-full and /update-memory-related - **Git-aware change detection**: Intelligent context-aware documentation updates - **Complexity-adaptive execution**: Auto-delegation to memory-gemini-bridge for complex projects - **Depth-parallel processing**: Bottom-up execution ensuring proper context propagation - **Enhanced issue tracking integration**: Complete /workflow:issue:* command set documentation ## New Scripts & Infrastructure - detect_changed_modules.sh: Git-based change detection with fallback strategies - get_modules_by_depth.sh: Hierarchical module discovery and organization - update_module_claude.sh: Core CLAUDE.md update execution engine ## Documentation Updates - **README.md**: Added comprehensive update-memory system documentation with usage examples - **README_CN.md**: Complete Chinese localization of new features and technical details - **Command reference tables**: Updated with new /update-memory-* commands and /workflow:issue:* set - **Technical highlights**: Enhanced with dual-mode operations and complexity thresholds - **Usage workflows**: Added detailed examples for different development scenarios ## Technical Improvements - Streamlined memory-gemini-bridge.md (reduced by 200+ lines) - Simplified gemini-unified.md workflow documentation - Added comprehensive CLAUDE.md files for new modules - Enhanced DMS (Distributed Memory System) with 4-layer hierarchy templates ## Architecture Enhancements - **Complexity thresholds**: related mode (>15 modules), full mode (>20 modules) - **Git integration**: Smart change detection with comprehensive status reporting - **User confirmation workflows**: Clear execution plans with mandatory approval steps - **Fallback strategies**: Graceful handling of non-git environments 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
@@ -0,0 +1,34 @@
|
||||
# Module: Analysis Prompts
|
||||
|
||||
## Overview
|
||||
|
||||
This module provides a collection of standardized prompt templates for conducting detailed analysis of software projects. Each template is designed to guide the language model in focusing on a specific area of concern, ensuring comprehensive and structured feedback.
|
||||
|
||||
## Component Documentation
|
||||
|
||||
The `analysis` module contains the following prompt templates:
|
||||
|
||||
- **`architecture.txt`**: Guides the analysis of high-level system architecture, design patterns, module dependencies, and scalability.
|
||||
- **`pattern.txt`**: Focuses on identifying and evaluating implementation patterns, code structure, and adherence to conventions.
|
||||
- **`performance.txt`**: Directs the analysis towards performance bottlenecks, algorithm efficiency, and optimization opportunities.
|
||||
- **`quality.txt`**: Used for assessing code quality, maintainability, error handling, and test coverage.
|
||||
- **`security.txt`**: Concentrates on identifying security vulnerabilities, including issues with authentication, authorization, input validation, and data encryption.
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
To use a template, its content should be prepended to a user's request for analysis. This primes the model with specific instructions and output requirements for the desired analysis type.
|
||||
|
||||
### Example: Requesting a Security Analysis
|
||||
|
||||
```
|
||||
[Content of security.txt]
|
||||
|
||||
---
|
||||
|
||||
Analyze the following codebase for security vulnerabilities:
|
||||
[Code or project context]
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
The prompt templates are plain text files and can be customized to adjust the focus or output requirements of the analysis. No special configuration is required to use them.
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update root-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 1: Root Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Project Overview and Purpose**
|
||||
- High-level project description and mission
|
||||
- Target audience and use cases
|
||||
- Key value propositions
|
||||
|
||||
2. **Technology Stack Summary**
|
||||
- Primary programming languages and frameworks
|
||||
- Key dependencies and tools
|
||||
- Platform and runtime requirements
|
||||
|
||||
3. **Architecture Decisions and Principles**
|
||||
- Core architectural patterns used
|
||||
- Design principles governing the codebase
|
||||
- Major technical decisions and rationale
|
||||
|
||||
4. **Development Workflow Overview**
|
||||
- Build and deployment processes
|
||||
- Testing approach and quality standards
|
||||
- Contributing guidelines and processes
|
||||
|
||||
5. **Quick Start Guide**
|
||||
- Installation prerequisites
|
||||
- Setup instructions
|
||||
- Basic usage examples
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Implementation details (belongs in module-level docs)
|
||||
- Module-specific patterns (belongs in module-level docs)
|
||||
- Code examples from specific modules (belongs in module-level docs)
|
||||
- Domain internal architecture (belongs in domain-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Use high-level, strategic perspective
|
||||
- Focus on "what" and "why" rather than "how"
|
||||
- Reference other documentation layers rather than duplicating content
|
||||
- Maintain concise, executive-summary style
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Project Name] - Development Guidelines
|
||||
|
||||
## 1. Project Overview and Purpose
|
||||
[Brief project description, mission, and target audience]
|
||||
|
||||
## 2. Technology Stack Summary
|
||||
[Primary technologies, frameworks, and tools]
|
||||
|
||||
## 3. Architecture Decisions and Principles
|
||||
[Core architectural patterns and design principles]
|
||||
|
||||
## 4. Development Workflow Overview
|
||||
[Build, test, and deployment processes]
|
||||
|
||||
## 5. Quick Start Guide
|
||||
[Installation and basic usage]
|
||||
```
|
||||
|
||||
Remember: This is Layer 1 - stay at the strategic level and avoid diving into implementation details.
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update domain-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 2: Domain Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Domain Architecture and Responsibilities**
|
||||
- Domain's role within the larger system
|
||||
- Core responsibilities and boundaries
|
||||
- Key abstractions and concepts
|
||||
|
||||
2. **Module Organization Within Domain**
|
||||
- How modules are structured within this domain
|
||||
- Module relationships and hierarchies
|
||||
- Organizational patterns used
|
||||
|
||||
3. **Inter-Module Communication Patterns**
|
||||
- How modules within this domain communicate
|
||||
- Data flow patterns and interfaces
|
||||
- Shared resources and dependencies
|
||||
|
||||
4. **Domain-Specific Conventions**
|
||||
- Coding standards specific to this domain
|
||||
- Naming conventions and patterns
|
||||
- Testing approaches for this domain
|
||||
|
||||
5. **Integration Points with Other Domains**
|
||||
- External dependencies and interfaces
|
||||
- Cross-domain communication protocols
|
||||
- Shared contracts and data formats
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Duplicating root project overview (belongs in root-level docs)
|
||||
- Component/function-level details (belongs in module-level docs)
|
||||
- Specific implementation code (belongs in module-level docs)
|
||||
- Module internal patterns (belongs in module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on domain-wide patterns and organization
|
||||
- Explain relationships between modules within the domain
|
||||
- Describe domain boundaries and responsibilities
|
||||
- Reference module-level docs for implementation details
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Domain Name] - Domain Architecture
|
||||
|
||||
## 1. Domain Overview
|
||||
[Domain's role and core responsibilities]
|
||||
|
||||
## 2. Module Organization
|
||||
[How modules are structured within this domain]
|
||||
|
||||
## 3. Inter-Module Communication
|
||||
[Communication patterns and data flow]
|
||||
|
||||
## 4. Domain Conventions
|
||||
[Domain-specific standards and patterns]
|
||||
|
||||
## 5. External Integration
|
||||
[Integration with other domains and systems]
|
||||
```
|
||||
|
||||
Remember: This is Layer 2 - focus on domain-wide organization and avoid both high-level project details and low-level implementation specifics.
|
||||
@@ -0,0 +1,66 @@
|
||||
Create or update module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 3: Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Module-Specific Implementation Patterns**
|
||||
- Implementation patterns used within this module
|
||||
- Common coding approaches and idioms
|
||||
- Module-specific design patterns
|
||||
|
||||
2. **Internal Architecture and Design Decisions**
|
||||
- How the module is internally organized
|
||||
- Key design decisions and their rationale
|
||||
- Component relationships within the module
|
||||
|
||||
3. **API Contracts and Interfaces**
|
||||
- Public interfaces exposed by this module
|
||||
- Input/output contracts and data formats
|
||||
- Integration points with other modules
|
||||
|
||||
4. **Module Dependencies and Relationships**
|
||||
- Direct dependencies of this module
|
||||
- How this module fits into the larger system
|
||||
- Data flow in and out of the module
|
||||
|
||||
5. **Testing Strategies for This Module**
|
||||
- Testing approaches specific to this module
|
||||
- Test coverage strategies and targets
|
||||
- Module-specific testing tools and frameworks
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Project overview content (belongs in root-level docs)
|
||||
- Domain-wide architectural patterns (belongs in domain-level docs)
|
||||
- Detailed function documentation (belongs in sub-module-level docs)
|
||||
- Configuration specifics (belongs in sub-module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on module-level architecture and patterns
|
||||
- Explain how components within the module work together
|
||||
- Document public interfaces and contracts
|
||||
- Reference sub-module docs for detailed implementation
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Module Name] - Module Architecture
|
||||
|
||||
## 1. Module Overview
|
||||
[Module's purpose and responsibilities]
|
||||
|
||||
## 2. Implementation Patterns
|
||||
[Common patterns and approaches used]
|
||||
|
||||
## 3. Internal Architecture
|
||||
[How the module is organized internally]
|
||||
|
||||
## 4. Public Interfaces
|
||||
[APIs and contracts exposed by this module]
|
||||
|
||||
## 5. Dependencies and Integration
|
||||
[Module dependencies and system integration]
|
||||
|
||||
## 6. Testing Strategy
|
||||
[Testing approaches for this module]
|
||||
```
|
||||
|
||||
Remember: This is Layer 3 - focus on module-level architecture and patterns, avoiding both domain-wide and detailed implementation concerns.
|
||||
@@ -0,0 +1,69 @@
|
||||
Create or update sub-module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 4: Sub-Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Detailed Implementation Specifics**
|
||||
- Specific implementation details and algorithms
|
||||
- Code-level patterns and idioms
|
||||
- Implementation trade-offs and decisions
|
||||
|
||||
2. **Component/Function Documentation**
|
||||
- Individual component descriptions
|
||||
- Function signatures and behaviors
|
||||
- Class/struct/interface documentation
|
||||
|
||||
3. **Configuration Details and Examples**
|
||||
- Configuration options and parameters
|
||||
- Environment-specific settings
|
||||
- Configuration examples and templates
|
||||
|
||||
4. **Usage Examples and Patterns**
|
||||
- Code examples and usage patterns
|
||||
- Common use cases and scenarios
|
||||
- Integration examples with other components
|
||||
|
||||
5. **Performance Considerations**
|
||||
- Performance characteristics and constraints
|
||||
- Optimization strategies and techniques
|
||||
- Resource usage and scalability notes
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Architecture decisions (belong in higher levels)
|
||||
- Module-level organizational patterns (belong in module-level docs)
|
||||
- Domain or project overview content (belong in higher levels)
|
||||
- Cross-module architectural concerns (belong in higher levels)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on detailed, actionable implementation information
|
||||
- Provide concrete examples and code snippets
|
||||
- Document specific behaviors and edge cases
|
||||
- Include troubleshooting and debugging guidance
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Sub-Module/Component Name] - Implementation Guide
|
||||
|
||||
## 1. Component Overview
|
||||
[Specific purpose and functionality]
|
||||
|
||||
## 2. Implementation Details
|
||||
[Detailed implementation specifics]
|
||||
|
||||
## 3. API Reference
|
||||
[Function/method documentation]
|
||||
|
||||
## 4. Configuration
|
||||
[Configuration options and examples]
|
||||
|
||||
## 5. Usage Examples
|
||||
[Code examples and patterns]
|
||||
|
||||
## 6. Performance and Optimization
|
||||
[Performance considerations and tips]
|
||||
|
||||
## 7. Troubleshooting
|
||||
[Common issues and solutions]
|
||||
```
|
||||
|
||||
Remember: This is Layer 4 - focus on concrete, actionable implementation details and avoid architectural or organizational concerns.
|
||||
@@ -1,4 +1,3 @@
|
||||
```markdown
|
||||
---
|
||||
name: gemini-unified
|
||||
description: Consolidated Gemini CLI guidelines - core rules, syntax, patterns, templates, and best practices
|
||||
@@ -47,28 +46,6 @@ type: technical-guideline
|
||||
)"
|
||||
```
|
||||
|
||||
### 🔄 Execution Modes
|
||||
|
||||
- **1. Directory-Scoped**: Navigate to a directory first, then run `gemini`.
|
||||
```bash
|
||||
cd src/components && gemini --all-files -p "@{CLAUDE.md} Analyze component patterns"
|
||||
```
|
||||
- **2. Pattern-Based**: Target files directly from any location using patterns.
|
||||
```bash
|
||||
gemini -p "@{src/components/**/*} @{CLAUDE.md} Analyze component patterns"
|
||||
```
|
||||
- **3. Template-Injected**: Use `$(cat)` to inject a predefined prompt template.
|
||||
```bash
|
||||
gemini -p "@{src/**/*} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)"
|
||||
```
|
||||
- **4. Parallel Execution**: Run multiple analyses concurrently for efficiency.
|
||||
```bash
|
||||
(
|
||||
gemini -p "@{**/*auth*} @{CLAUDE.md} Auth patterns" &
|
||||
gemini -p "@{**/api/**/*} @{CLAUDE.md} API patterns" &
|
||||
wait
|
||||
)
|
||||
```
|
||||
|
||||
### 📂 File Pattern Rules
|
||||
|
||||
@@ -88,109 +65,12 @@ type: technical-guideline
|
||||
- Enclose paths with spaces in quotes: `@{"My Project/src/**/*"}`.
|
||||
- Escape special characters like brackets: `@{src/**/*\[bracket\]*}`.
|
||||
|
||||
### 🧠 Smart Pattern Discovery - Logic Flow
|
||||
|
||||
This feature automates the process of finding relevant files for analysis.
|
||||
|
||||
`Step 1: Analyze File Extensions` -> `Step 2: Generate Patterns` -> `Step 3: Execute Gemini`
|
||||
|
||||
```pseudo
|
||||
FUNCTION analyze_and_run_gemini(analysis_type):
|
||||
// Step 1: Analyze the project's file types.
|
||||
// Corresponds to the `discover_extensions` shell function.
|
||||
discovered_extensions = analyze_project_extensions()
|
||||
log("Discovered extensions:", discovered_extensions)
|
||||
|
||||
// Also identify the likely primary programming language.
|
||||
// Corresponds to the `detect_primary_language` shell function.
|
||||
primary_language = detect_main_language(discovered_extensions)
|
||||
log("Primary language:", primary_language)
|
||||
|
||||
// Step 2: Generate file patterns based on the analysis type (e.g., "code", "config").
|
||||
// Corresponds to the `generate_patterns_by_extension` shell function.
|
||||
patterns = generate_patterns(analysis_type, discovered_extensions)
|
||||
log("Generated patterns:", patterns)
|
||||
|
||||
// Step 3: Construct and execute the gemini command.
|
||||
// Always include project standards from CLAUDE.md.
|
||||
// Uses a mode-defined analysis template for consistency.
|
||||
command = "gemini -p \"" + patterns + " @{CLAUDE.md} $(cat ~/.claude/workflows/gemini-templates/prompts/analysis/pattern.txt)\""
|
||||
execute_shell(command)
|
||||
|
||||
END FUNCTION
|
||||
```
|
||||
|
||||
### 📜 Smart Discovery - Shell Implementation
|
||||
|
||||
These functions provide the concrete implementation for the smart discovery logic.
|
||||
|
||||
- **Step 1: Analyze File Extensions & Language**
|
||||
```bash
|
||||
# Discover actual file types in project
|
||||
discover_extensions() {
|
||||
echo "=== File Extension Analysis ==="
|
||||
find . -type f -name "*.*" 2>/dev/null | \
|
||||
sed 's/.*\.//' | \
|
||||
sort | uniq -c | sort -rn | \
|
||||
head -10
|
||||
}
|
||||
|
||||
# Identify primary language
|
||||
detect_primary_language() {
|
||||
local extensions=$(find . -type f -name "*.*" 2>/dev/null | sed 's/.*\.//' | sort | uniq -c | sort -rn)
|
||||
if echo "$extensions" | grep -q "js\|jsx\|ts\|tsx"; then
|
||||
echo "JavaScript/TypeScript"
|
||||
elif echo "$extensions" | grep -q "py\|pyw"; then
|
||||
echo "Python"
|
||||
# ... other language checks ...
|
||||
else
|
||||
echo "Unknown/Mixed"
|
||||
fi
|
||||
}
|
||||
```
|
||||
- **Step 2: Generate Patterns**
|
||||
```bash
|
||||
# Generate patterns from discovered extensions
|
||||
generate_patterns_by_extension() {
|
||||
local analysis_type="$1"
|
||||
local top_exts=$(find . -type f -name "*.*" 2>/dev/null | sed 's/.*\.//' | sort | uniq -c | sort -rn | head -5 | awk '{print $2}')
|
||||
local pattern=""
|
||||
case "$analysis_type" in
|
||||
"code")
|
||||
for ext in $top_exts; do
|
||||
case $ext in
|
||||
js|ts|jsx|tsx|py|java|go|rs|cpp|c|h)
|
||||
pattern="${pattern}**/*.${ext},"
|
||||
;;
|
||||
esac
|
||||
done
|
||||
echo "@{${pattern%,}}"
|
||||
;;
|
||||
"config") echo "@{*.json,*.yml,*.yaml,*.toml,*.ini,*.env}" ;;
|
||||
"docs") echo "@{**/*.md,**/*.txt,**/README*}" ;;
|
||||
"all")
|
||||
for ext in $top_exts; do pattern="${pattern}**/*.${ext},"; done
|
||||
echo "@{${pattern%,}}"
|
||||
;;
|
||||
esac
|
||||
}
|
||||
```
|
||||
|
||||
### ⚡ Smart Discovery - Quick Commands
|
||||
|
||||
| Need | Command | Description |
|
||||
|------|---------|-------------|
|
||||
| Analyze Extensions | `discover_extensions` | View project file type distribution. |
|
||||
| Code Files | `generate_patterns_by_extension "code"` | Generate patterns for source code files only. |
|
||||
| Config Files | `generate_patterns_by_extension "config"` | Generate patterns for configuration files. |
|
||||
| Docs | `generate_patterns_by_extension "docs"` | Generate patterns for documentation. |
|
||||
| All Top Types | `generate_patterns_by_extension "all"` | Generate patterns for all discovered file types. |
|
||||
|
||||
### TPL (Templates)
|
||||
|
||||
#### 🗂️ Template Directory Structure
|
||||
This structure must be located at `~/.claude/workflows/gemini-templates/`.
|
||||
```
|
||||
|
||||
~/.claude/workflows/gemini-templates/
|
||||
├── prompts/
|
||||
│ ├── analysis/ # Code analysis templates
|
||||
@@ -209,7 +89,7 @@ This structure must be located at `~/.claude/workflows/gemini-templates/`.
|
||||
│ └── dms/ # DMS-specific
|
||||
│ └── hierarchy-analysis.txt # 📚 Documentation structure optimization
|
||||
└── commands/ # Command examples
|
||||
```
|
||||
|
||||
|
||||
#### 🧭 Template Selection Guide
|
||||
| Task Type | Primary Template | Purpose |
|
||||
@@ -279,16 +159,22 @@ These are recommended command templates for common scenarios.
|
||||
|
||||
### ⭐ Best Practices & Rules
|
||||
|
||||
- **Mandatory Context**: Always include `@{CLAUDE.md,**/*CLAUDE.md}` to ground the analysis in project-specific standards.
|
||||
- **Specificity**: Use precise file patterns to reduce scope, improve performance, and increase accuracy.
|
||||
- **Performance**: Avoid overly broad patterns (`@{**/*}`) on large projects. Prefer directory-scoped execution or parallel chunks.
|
||||
- **Agent Integration**: All agent workflows **must** begin with a context analysis step using `gemini`.
|
||||
```bash
|
||||
# Mandatory first step for any agent task
|
||||
gemini --all-files -p "@{relevant_patterns} @{CLAUDE.md} Context for: [task_description]"
|
||||
```
|
||||
- **Error Handling**:
|
||||
- Validate patterns match existing files before executing a long analysis.
|
||||
- Quote paths that contain spaces or special characters.
|
||||
- Test complex patterns on a small subset of files first.
|
||||
|
||||
**When to Use @ Patterns:**
|
||||
1. **User explicitly provides @ patterns** - ALWAYS preserve them exactly
|
||||
2. **Cross-directory analysis** - When analyzing relationships between modules
|
||||
3. **Configuration files** - When analyzing scattered config files
|
||||
4. **Selective inclusion** - When you only need specific file types
|
||||
|
||||
**CLAUDE.md Loading Rules:**
|
||||
- **With --all-files**: CLAUDE.md files automatically included (no @ needed)
|
||||
- **Without --all-files**: Must use `@{CLAUDE.md}` or `@{**/CLAUDE.md}`
|
||||
|
||||
|
||||
#### ⚠️ Error Prevention
|
||||
|
||||
- **Quote paths with spaces**: Use proper shell quoting
|
||||
- **Test patterns first**: Validate @ patterns match existing files
|
||||
- **Prefer directory navigation**: Reduces complexity and improves performance
|
||||
- **Preserve user patterns**: When user provides @, always keep them
|
||||
|
||||
|
||||
Reference in New Issue
Block a user