chore: remove deprecated templates and unused files

- Delete archived layer-based templates (Layer 1-4)
- Remove hierarchy-analysis.txt (no longer needed)
- Update intelligent-tools-strategy.md to remove references

Cleanup:
- Keep only claude-module-unified.txt in memory/ directory
- Remove outdated template references from strategy document
- Simplify template structure for installation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
2025-10-12 21:57:19 +08:00
parent 46f749605a
commit 177279b760
6 changed files with 1 additions and 280 deletions

View File

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

View File

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

View File

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

View File

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

View File

@@ -1,16 +0,0 @@
Analyze project structure for memory 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.

View File

@@ -274,7 +274,6 @@ RULES: Focus on type safety and component composition
| **Security** | Codex | Vulnerability assessment, fixes | `analysis/security.txt` |
| **Refactoring** | Multiple | Gemini/Qwen for analysis, Codex for execution | `development/refactor.txt` |
| **Module Documentation** | Gemini (Qwen fallback) | Universal module/file documentation for all levels | `memory/claude-module-unified.txt` |
| **Memory Hierarchy** | Gemini (Qwen fallback) | Project structure analysis for optimal doc hierarchy | `memory/hierarchy-analysis.txt` |
### Template System
@@ -293,8 +292,7 @@ prompts/
│ ├── refactor.txt - Refactoring tasks
│ └── testing.txt - Test generation
├── memory/
── claude-module-unified.txt - Universal module/file documentation template
│ └── hierarchy-analysis.txt - Project structure analysis
── claude-module-unified.txt - Universal module/file documentation template
└── planning/
└── task-breakdown.txt - Task decomposition