├── standard ├── projectbrief.md ├── productContext.md ├── .clinerules ├── progress.md ├── README.md ├── techContext.md ├── systemPatterns.md ├── activeContext.md └── prompt.md ├── go-template ├── projectbrief.md ├── productContext.md ├── .clinerules ├── README.md ├── progress.md ├── activeContext.md ├── techContext.md ├── prompt.md └── systemPatterns.md ├── README.md └── LICENSE /standard/projectbrief.md: -------------------------------------------------------------------------------- 1 | # Project Brief: [Project Name] 2 | 3 | ## Core Mission 4 | [Project Name] is a [brief one-sentence description of what the project is and does]. 5 | 6 | ## Key Requirements 7 | 8 | 1. **Functionality** 9 | - [List key functional requirements] 10 | - [Be specific and measurable when possible] 11 | - [Focus on what the system must do] 12 | 13 | 2. **Performance** 14 | - [List performance requirements] 15 | - [Include metrics and benchmarks] 16 | - [Consider response times, throughput, resource usage] 17 | 18 | 3. **Security & Compliance** 19 | - [List security requirements] 20 | - [Include compliance standards if applicable] 21 | - [Consider authentication, authorization, data protection] 22 | 23 | 4. **User Experience** 24 | - [List UX requirements] 25 | - [Consider accessibility needs] 26 | - [Include key user journeys] 27 | 28 | ## Project Scope 29 | 30 | ### In Scope 31 | - [Feature/component in scope] 32 | - [Feature/component in scope] 33 | - [Feature/component in scope] 34 | - [Feature/component in scope] 35 | - [Feature/component in scope] 36 | 37 | ### Out of Scope 38 | - [Feature/component out of scope] 39 | - [Feature/component out of scope] 40 | - [Feature/component out of scope] 41 | - [Feature/component out of scope] 42 | - [Feature/component out of scope] 43 | 44 | ## Success Criteria 45 | 1. [Success criterion 1 - make specific and measurable] 46 | 2. [Success criterion 2 - make specific and measurable] 47 | 3. [Success criterion 3 - make specific and measurable] 48 | 4. [Success criterion 4 - make specific and measurable] 49 | 5. [Success criterion 5 - make specific and measurable] 50 | 51 | ## Implementation Guidelines 52 | - [Core implementation guideline - technology choices] 53 | - [Core implementation guideline - architectural decisions] 54 | - [Core implementation guideline - coding standards] 55 | - [Core implementation guideline - testing approach] 56 | 57 | ## Project Timeline 58 | - **Phase 1**: [Brief description] - [Target date] 59 | - **Phase 2**: [Brief description] - [Target date] 60 | - **Phase 3**: [Brief description] - [Target date] 61 | - **Phase 4**: [Brief description] - [Target date] 62 | 63 | ## Key Stakeholders 64 | - **Project Owner**: [Name/Role] 65 | - **Technical Lead**: [Name/Role] 66 | - **End Users**: [Description of user groups] 67 | - **Other Stakeholders**: [Any other key stakeholders] 68 | 69 | ## Dependencies 70 | - [External dependency 1] 71 | - [External dependency 2] 72 | - [External dependency 3] 73 | - [External dependency 4] 74 | 75 | ## Risk Assessment 76 | - **Risk 1**: [Description] - **Mitigation**: [Approach] 77 | - **Risk 2**: [Description] - **Mitigation**: [Approach] 78 | - **Risk 3**: [Description] - **Mitigation**: [Approach] 79 | - **Risk 4**: [Description] - **Mitigation**: [Approach] 80 | -------------------------------------------------------------------------------- /go-template/projectbrief.md: -------------------------------------------------------------------------------- 1 | # Project Brief: [Project Name] 2 | 3 | ## Core Mission 4 | [Project Name] is a [brief one-sentence description of what the project is and does]. 5 | 6 | ## Key Requirements 7 | 8 | 1. **Functionality** 9 | - [List key functional requirements] 10 | - [Be specific and measurable when possible] 11 | - [Focus on what the system must do] 12 | 13 | 2. **Performance** 14 | - [List performance requirements] 15 | - [Include metrics and benchmarks] 16 | - [Consider response times, throughput, resource usage] 17 | 18 | 3. **Security & Compliance** 19 | - [List security requirements] 20 | - [Include compliance standards if applicable] 21 | - [Consider authentication, authorization, data protection] 22 | 23 | 4. **User Experience** 24 | - [List UX requirements] 25 | - [Consider accessibility needs] 26 | - [Include key user journeys] 27 | 28 | ## Project Scope 29 | 30 | ### In Scope 31 | - [Feature/component in scope] 32 | - [Feature/component in scope] 33 | - [Feature/component in scope] 34 | - [Feature/component in scope] 35 | - [Feature/component in scope] 36 | 37 | ### Out of Scope 38 | - [Feature/component out of scope] 39 | - [Feature/component out of scope] 40 | - [Feature/component out of scope] 41 | - [Feature/component out of scope] 42 | - [Feature/component out of scope] 43 | 44 | ## Success Criteria 45 | 1. [Success criterion 1 - make specific and measurable] 46 | 2. [Success criterion 2 - make specific and measurable] 47 | 3. [Success criterion 3 - make specific and measurable] 48 | 4. [Success criterion 4 - make specific and measurable] 49 | 5. [Success criterion 5 - make specific and measurable] 50 | 51 | ## Implementation Guidelines 52 | - [Core implementation guideline - technology choices] 53 | - [Core implementation guideline - architectural decisions] 54 | - [Core implementation guideline - coding standards] 55 | - [Core implementation guideline - testing approach] 56 | 57 | ## Project Timeline 58 | - **Phase 1**: [Brief description] - [Target date] 59 | - **Phase 2**: [Brief description] - [Target date] 60 | - **Phase 3**: [Brief description] - [Target date] 61 | - **Phase 4**: [Brief description] - [Target date] 62 | 63 | ## Key Stakeholders 64 | - **Project Owner**: [Name/Role] 65 | - **Technical Lead**: [Name/Role] 66 | - **End Users**: [Description of user groups] 67 | - **Other Stakeholders**: [Any other key stakeholders] 68 | 69 | ## Dependencies 70 | - [External dependency 1] 71 | - [External dependency 2] 72 | - [External dependency 3] 73 | - [External dependency 4] 74 | 75 | ## Risk Assessment 76 | - **Risk 1**: [Description] - **Mitigation**: [Approach] 77 | - **Risk 2**: [Description] - **Mitigation**: [Approach] 78 | - **Risk 3**: [Description] - **Mitigation**: [Approach] 79 | - **Risk 4**: [Description] - **Mitigation**: [Approach] 80 | -------------------------------------------------------------------------------- /standard/productContext.md: -------------------------------------------------------------------------------- 1 | # Product Context: [Project Name] 2 | 3 | ## Problem Space 4 | 5 | ### Current Challenges 6 | 1. [Challenge Category 1] 7 | - [Specific challenge] 8 | - [Specific challenge] 9 | - [Specific challenge] 10 | 11 | 2. [Challenge Category 2] 12 | - [Specific challenge] 13 | - [Specific challenge] 14 | - [Specific challenge] 15 | 16 | 3. [Challenge Category 3] 17 | - [Specific challenge] 18 | - [Specific challenge] 19 | - [Specific challenge] 20 | 21 | ## Solution 22 | 23 | [Project Name] addresses these challenges through: 24 | 25 | 1. [Solution Category 1] 26 | - [Specific solution] 27 | - [Specific solution] 28 | - [Specific solution] 29 | 30 | 2. [Solution Category 2] 31 | - [Specific solution] 32 | - [Specific solution] 33 | - [Specific solution] 34 | - [Specific solution] 35 | 36 | 3. [Solution Category 3] 37 | - [Specific solution] 38 | - [Specific solution] 39 | - [Specific solution] 40 | 41 | ## User Experience Goals 42 | 43 | 1. [UX Goal 1 (e.g., Simplicity)] 44 | - [Specific aspect] 45 | - [Specific aspect] 46 | - [Specific aspect] 47 | 48 | 2. [UX Goal 2 (e.g., Reliability)] 49 | - [Specific aspect] 50 | - [Specific aspect] 51 | - [Specific aspect] 52 | 53 | 3. [UX Goal 3 (e.g., Visibility)] 54 | - [Specific aspect] 55 | - [Specific aspect] 56 | - [Specific aspect] 57 | 58 | 4. [UX Goal 4 (e.g., Control)] 59 | - [Specific aspect] 60 | - [Specific aspect] 61 | - [Specific aspect] 62 | 63 | ## Target Users 64 | 65 | 1. [User Type 1] 66 | - [Characteristics] 67 | - [Needs] 68 | - [Expectations] 69 | 70 | 2. [User Type 2] 71 | - [Characteristics] 72 | - [Needs] 73 | - [Expectations] 74 | 75 | 3. [User Type 3] 76 | - [Characteristics] 77 | - [Needs] 78 | - [Expectations] 79 | 80 | ## Success Metrics 81 | 82 | 1. [Metric Category 1 (e.g., Operational)] 83 | - [Specific metric] 84 | - [Specific metric] 85 | - [Specific metric] 86 | 87 | 2. [Metric Category 2 (e.g., Technical)] 88 | - [Specific metric] 89 | - [Specific metric] 90 | - [Specific metric] 91 | 92 | 3. [Metric Category 3 (e.g., User Satisfaction)] 93 | - [Specific metric] 94 | - [Specific metric] 95 | - [Specific metric] 96 | 97 | ## Integration Points 98 | 99 | 1. [Integration Category 1] 100 | - [Specific integration] 101 | - [Integration requirements] 102 | - [Expected behavior] 103 | 104 | 2. [Integration Category 2] 105 | - [Specific integration] 106 | - [Integration requirements] 107 | - [Expected behavior] 108 | 109 | ## Constraints 110 | 111 | 1. [Constraint Category 1] 112 | - [Specific constraint] 113 | - [Impact] 114 | - [Mitigation strategy] 115 | 116 | 2. [Constraint Category 2] 117 | - [Specific constraint] 118 | - [Impact] 119 | - [Mitigation strategy] 120 | -------------------------------------------------------------------------------- /go-template/productContext.md: -------------------------------------------------------------------------------- 1 | # Product Context: [Project Name] 2 | 3 | ## Problem Space 4 | 5 | ### Current Challenges 6 | 1. [Challenge Category 1] 7 | - [Specific challenge] 8 | - [Specific challenge] 9 | - [Specific challenge] 10 | 11 | 2. [Challenge Category 2] 12 | - [Specific challenge] 13 | - [Specific challenge] 14 | - [Specific challenge] 15 | 16 | 3. [Challenge Category 3] 17 | - [Specific challenge] 18 | - [Specific challenge] 19 | - [Specific challenge] 20 | 21 | ## Solution 22 | 23 | [Project Name] addresses these challenges through: 24 | 25 | 1. [Solution Category 1] 26 | - [Specific solution] 27 | - [Specific solution] 28 | - [Specific solution] 29 | 30 | 2. [Solution Category 2] 31 | - [Specific solution] 32 | - [Specific solution] 33 | - [Specific solution] 34 | - [Specific solution] 35 | 36 | 3. [Solution Category 3] 37 | - [Specific solution] 38 | - [Specific solution] 39 | - [Specific solution] 40 | 41 | ## User Experience Goals 42 | 43 | 1. [UX Goal 1 (e.g., Simplicity)] 44 | - [Specific aspect] 45 | - [Specific aspect] 46 | - [Specific aspect] 47 | 48 | 2. [UX Goal 2 (e.g., Reliability)] 49 | - [Specific aspect] 50 | - [Specific aspect] 51 | - [Specific aspect] 52 | 53 | 3. [UX Goal 3 (e.g., Visibility)] 54 | - [Specific aspect] 55 | - [Specific aspect] 56 | - [Specific aspect] 57 | 58 | 4. [UX Goal 4 (e.g., Control)] 59 | - [Specific aspect] 60 | - [Specific aspect] 61 | - [Specific aspect] 62 | 63 | ## Target Users 64 | 65 | 1. [User Type 1] 66 | - [Characteristics] 67 | - [Needs] 68 | - [Expectations] 69 | 70 | 2. [User Type 2] 71 | - [Characteristics] 72 | - [Needs] 73 | - [Expectations] 74 | 75 | 3. [User Type 3] 76 | - [Characteristics] 77 | - [Needs] 78 | - [Expectations] 79 | 80 | ## Success Metrics 81 | 82 | 1. [Metric Category 1 (e.g., Operational)] 83 | - [Specific metric] 84 | - [Specific metric] 85 | - [Specific metric] 86 | 87 | 2. [Metric Category 2 (e.g., Technical)] 88 | - [Specific metric] 89 | - [Specific metric] 90 | - [Specific metric] 91 | 92 | 3. [Metric Category 3 (e.g., User Satisfaction)] 93 | - [Specific metric] 94 | - [Specific metric] 95 | - [Specific metric] 96 | 97 | ## Integration Points 98 | 99 | 1. [Integration Category 1] 100 | - [Specific integration] 101 | - [Integration requirements] 102 | - [Expected behavior] 103 | 104 | 2. [Integration Category 2] 105 | - [Specific integration] 106 | - [Integration requirements] 107 | - [Expected behavior] 108 | 109 | ## Constraints 110 | 111 | 1. [Constraint Category 1] 112 | - [Specific constraint] 113 | - [Impact] 114 | - [Mitigation strategy] 115 | 116 | 2. [Constraint Category 2] 117 | - [Specific constraint] 118 | - [Impact] 119 | - [Mitigation strategy] 120 | -------------------------------------------------------------------------------- /go-template/.clinerules: -------------------------------------------------------------------------------- 1 | ## Project Intelligence 2 | 3 | ### Go Code Styling Rules 4 | - main.go should be minimal, serving only as entrypoint 5 | - All packages under ./pkg/ directory 6 | - Keep files under 300 lines by splitting into multiple files 7 | - Group small utility functions in util.go within each package 8 | - Each exported function requires detailed documentation comments 9 | - Run go fmt ./... before committing code 10 | - Make frequent, small git commits while coding to create recovery points 11 | - Use git checkout [commit-hash] -- path/to/file.go to recover accidentally deleted code 12 | - Group imports in three blocks: standard library, external deps, internal packages 13 | - Break up large packages into multiple files with clear responsibilities 14 | 15 | ### Project Structure 16 | - Define key components in the README.md 17 | - Place all packages under pkg/ 18 | - Place executables under cmd/ 19 | - Documentation in docs/ 20 | - Configuration in config/ 21 | - Unit tests alongside the code they test 22 | - Integration tests in separate test/ directory 23 | 24 | ### Logging Best Practices 25 | - Use structured logging (e.g., logrus, zap) 26 | - Initialize package-level loggers 27 | - Use appropriate log levels (debug, info, warn, error) 28 | - Include context with log entries 29 | - When viewing logs: 30 | - Always use --tail flag to limit log output 31 | - Never use -f/--follow in scripts as these commands never return 32 | - Recommended: kubectl logs pod-name --tail=100 (for K8s projects) 33 | 34 | ### Documentation Standards 35 | - Document all exported functions, types, and packages 36 | - Use consistent formatting for godoc comments 37 | - Include examples for complex functions 38 | - Keep README.md up to date with usage instructions 39 | - Document configuration options and their effects 40 | - Create CONTRIBUTING.md for collaboration guidelines 41 | 42 | ### Testing Requirements 43 | - Write tests for all packages 44 | - Maintain high test coverage for core logic 45 | - Use table-driven tests for multiple test cases 46 | - Mock external dependencies 47 | - Name tests using the TestFunctionName_Scenario convention 48 | - Add benchmarks for performance-critical code 49 | - Include integration tests for end-to-end verification 50 | 51 | ### Error Handling 52 | - Always check error returns 53 | - Provide context when wrapping errors (e.g., fmt.Errorf("context: %w", err)) 54 | - Use custom error types for domain-specific errors 55 | - Include appropriate logging with error context 56 | - Return early on errors to avoid deep nesting 57 | - Consider implementing the error interface for custom error types 58 | 59 | ### Performance Considerations 60 | - Use profiling tools for optimization 61 | - Benchmark before and after optimizations 62 | - Consider memory usage for large data structures 63 | - Use sync.Pool for frequently allocated objects 64 | - Implement worker pools for concurrent operations 65 | - Be aware of garbage collection impact 66 | - Consider using sync.Mutex for shared resources 67 | -------------------------------------------------------------------------------- /standard/.clinerules: -------------------------------------------------------------------------------- 1 | ## Project Intelligence 2 | 3 | ### Code Styling Rules 4 | - Keep entry point files minimal, serving only as entrypoints 5 | - Organize code into logical modules/packages/directories 6 | - Keep files under 300 lines by splitting into multiple files 7 | - Group small utility functions in utility modules 8 | - Each exported function/method requires detailed documentation comments 9 | - Format code according to language standards before committing 10 | - Make frequent, small git commits while coding to create recovery points 11 | - Use git checkout [commit-hash] -- path/to/file to recover accidentally deleted code 12 | - Group imports according to language-specific best practices 13 | - Break up large modules into multiple files with clear responsibilities 14 | 15 | ### Project Structure 16 | - Define key components in the README.md 17 | - Separate core logic from UI and data layers 18 | - Place documentation in docs/ 19 | - Configuration in config/ 20 | - Unit tests alongside the code they test 21 | - Integration tests in separate test/ directory 22 | 23 | ### Logging Best Practices 24 | - Use structured logging 25 | - Initialize logger at appropriate scope 26 | - Use appropriate log levels (debug, info, warn, error) 27 | - Include context with log entries 28 | - When viewing logs: 29 | - Always use appropriate flags to limit log output 30 | - Never use follow/tail flags in scripts as these commands never return 31 | - Use reasonable log size limits 32 | 33 | ### Documentation Standards 34 | - Document all public functions, classes, and modules 35 | - Use consistent formatting for comments 36 | - Include examples for complex functions 37 | - Keep README.md up to date with usage instructions 38 | - Document configuration options and their effects 39 | - Create CONTRIBUTING.md for collaboration guidelines 40 | 41 | ### Testing Requirements 42 | - Write tests for all modules 43 | - Maintain high test coverage for core logic 44 | - Use table-driven or parameterized tests for multiple test cases 45 | - Mock external dependencies 46 | - Name tests clearly to indicate test purpose 47 | - Add performance tests for critical sections 48 | - Include integration tests for end-to-end verification 49 | 50 | ### Error Handling 51 | - Always check error returns 52 | - Provide context when propagating errors 53 | - Use appropriate error types for domain-specific errors 54 | - Include appropriate logging with error context 55 | - Return/throw early on errors to avoid deep nesting 56 | - Consider implementing custom error types when appropriate 57 | 58 | ### Performance Considerations 59 | - Use profiling tools for optimization 60 | - Benchmark before and after optimizations 61 | - Consider memory usage for large data structures 62 | - Implement pooling for frequently allocated objects 63 | - Use concurrency or parallelism appropriately 64 | - Be aware of garbage collection impact where applicable 65 | - Implement appropriate locking for shared resources 66 | 67 | ### Security Practices 68 | - Validate all user inputs 69 | - Use prepared statements for database queries 70 | - Implement proper authentication and authorization 71 | - Follow the principle of least privilege 72 | - Keep dependencies updated 73 | - Scan for vulnerabilities regularly 74 | - Avoid hard-coded secrets 75 | -------------------------------------------------------------------------------- /go-template/README.md: -------------------------------------------------------------------------------- 1 | # Go Project Memory Bank Templates 2 | 3 | This directory contains template files for setting up a structured Memory Bank for Go projects. These templates provide a standardized way to document project context, technical decisions, and progress tracking. 4 | 5 | ## Overview 6 | 7 | The Memory Bank structure follows a hierarchical approach where files build upon each other to provide a complete picture of the project. This approach helps Cline (or other LLM assistants) understand the project thoroughly and provide more accurate assistance. 8 | 9 | ## Memory Bank Files 10 | 11 | 1. **`prompt.md`** - The main memory bank prompt that explains the structure and Git workflow rules 12 | 2. **`.clinerules`** - Go-specific project rules, styling guidelines, and best practices 13 | 3. **`projectbrief.md`** - Core requirements, goals, and project scope 14 | 4. **`productContext.md`** - Purpose, problems solved, and expected behavior 15 | 5. **`systemPatterns.md`** - Architecture, technical decisions, and Go design patterns 16 | 6. **`techContext.md`** - Technology stack, dependencies, and deployment details 17 | 7. **`activeContext.md`** - Current focus, recent changes, and next steps 18 | 8. **`progress.md`** - Tracks completed work, in-progress features, and planned roadmap 19 | 20 | ## How to Use These Templates 21 | 22 | 1. **Create Project Directory**: 23 | ```bash 24 | mkdir -p my-go-project/memory-bank 25 | ``` 26 | 27 | 2. **Copy Templates**: 28 | ```bash 29 | cp go-template/* my-go-project/memory-bank/ 30 | ``` 31 | 32 | 3. **Customize Templates**: 33 | - Replace all placeholder text (e.g., `[Project Name]`, `[Feature 1]`) with actual project details 34 | - Add project-specific information to each file 35 | - Remove sections that aren't relevant to your project 36 | 37 | 4. **Update as Project Evolves**: 38 | - Keep the memory bank files updated as the project progresses 39 | - Document significant changes, decisions, and progress 40 | 41 | ## File Relationships 42 | 43 | The Memory Bank files follow this relationship structure: 44 | 45 | ```mermaid 46 | flowchart TD 47 | PB[projectbrief.md] --> PC[productContext.md] 48 | PB --> SP[systemPatterns.md] 49 | PB --> TC[techContext.md] 50 | 51 | PC --> AC[activeContext.md] 52 | SP --> AC 53 | TC --> AC 54 | 55 | AC --> P[progress.md] 56 | ``` 57 | 58 | ## Best Practices 59 | 60 | 1. **Keep Documentation Updated**: 61 | - Update memory bank files regularly as the project evolves 62 | - Document major decisions and changes immediately 63 | 64 | 2. **Be Specific**: 65 | - Avoid vague descriptions 66 | - Include concrete examples and implementation details 67 | - Link to specific code files when applicable 68 | 69 | 3. **Follow Go Best Practices**: 70 | - Adhere to the Go code styling rules in `.clinerules` 71 | - Document exported functions, types, and packages 72 | - Maintain clear package structures as outlined in `systemPatterns.md` 73 | 74 | 4. **Track Progress Diligently**: 75 | - Keep `progress.md` up to date with completed features 76 | - Document known issues and their priority 77 | - Update milestone targets as schedules change 78 | 79 | 5. **Git Integration**: 80 | - Follow the Git workflow rules in `prompt.md` 81 | - Commit memory bank updates alongside code changes 82 | - Use the recovery techniques described if code is lost 83 | 84 | ## Template Usage Tips 85 | 86 | - Start by defining the core project information in `projectbrief.md` and `productContext.md` 87 | - Fill in technical details in `systemPatterns.md` and `techContext.md` 88 | - Use `activeContext.md` as a living document for current focus areas 89 | - Update `progress.md` as features are completed or new ones are planned 90 | 91 | By maintaining these memory bank files, you'll create a comprehensive knowledge base that helps both developers and AI assistants understand and contribute to your Go project more effectively. 92 | -------------------------------------------------------------------------------- /go-template/progress.md: -------------------------------------------------------------------------------- 1 | # Progress Tracking: [Project Name] 2 | 3 | ## Completed Features 4 | 5 | ### [Category 1] 6 | - [x] [Feature 1] 7 | - [x] [Feature 2] 8 | - [x] [Feature 3] 9 | - [x] [Feature 4] 10 | - [x] [Feature 5] 11 | 12 | ### [Category 2] 13 | - [x] [Feature 1] 14 | - [x] [Feature 2] 15 | - [x] [Feature 3] 16 | - [x] [Feature 4] 17 | 18 | ### [Category 3] 19 | - [x] [Feature 1] 20 | - [x] [Feature 2] 21 | - [x] [Feature 3] 22 | 23 | ### Deprecated Features 24 | - [x] [Feature 1] (replaced by [new feature]) 25 | - [x] [Feature 2] (no longer needed) 26 | 27 | ### [Deployment/Integration] 28 | - [x] [Feature 1] 29 | - [x] [Feature 2] 30 | - [x] [Feature 3] 31 | - [x] [Feature 4] 32 | - [x] [Feature 5] 33 | 34 | ## In Progress 35 | 36 | ### [Category 1] 37 | - [x] [Sub-feature 1] 38 | * [Completed aspect] 39 | * [Completed aspect] 40 | - [ ] [Sub-feature 2] 41 | * [In-progress aspect] 42 | * [Planned aspect] 43 | - [ ] [Sub-feature 3] 44 | * [Planned aspect] 45 | * [Planned aspect] 46 | 47 | ### [Category 2] 48 | - [x] [Sub-feature 1] 49 | * [Completed aspect] 50 | * [Completed aspect] 51 | - [ ] [Sub-feature 2] 52 | * [In-progress aspect] 53 | * [Planned aspect] 54 | - [ ] [Sub-feature 3] 55 | * [Planned aspect] 56 | * [Planned aspect] 57 | 58 | ## Planned Features 59 | 60 | ### Short Term 61 | 1. [Category 1] 62 | - [ ] [Feature 1] 63 | - [ ] [Feature 2] 64 | - [ ] [Feature 3] 65 | - [ ] [Feature 4] 66 | 67 | 2. [Category 2] 68 | - [ ] [Feature 1] 69 | - [ ] [Feature 2] 70 | - [ ] [Feature 3] 71 | 72 | 3. [Category 3] 73 | - [ ] [Feature 1] 74 | - [ ] [Feature 2] 75 | - [ ] [Feature 3] 76 | 77 | ### Medium Term 78 | 1. [Category 1] 79 | - [ ] [Feature 1] 80 | - [ ] [Feature 2] 81 | - [ ] [Feature 3] 82 | - [ ] [Feature 4] 83 | 84 | 2. [Category 2] 85 | - [ ] [Feature 1] 86 | - [ ] [Feature 2] 87 | - [ ] [Feature 3] 88 | 89 | 3. [Category 3] 90 | - [ ] [Feature 1] 91 | - [ ] [Feature 2] 92 | - [ ] [Feature 3] 93 | 94 | ### Long Term 95 | 1. [Category 1] 96 | - [ ] [Feature 1] 97 | - [ ] [Feature 2] 98 | - [ ] [Feature 3] 99 | - [ ] [Feature 4] 100 | 101 | 2. [Category 2] 102 | - [ ] [Feature 1] 103 | - [ ] [Feature 2] 104 | - [ ] [Feature 3] 105 | 106 | 3. [Category 3] 107 | - [ ] [Feature 1] 108 | - [ ] [Feature 2] 109 | - [ ] [Feature 3] 110 | 111 | ## Known Issues 112 | 113 | ### Critical 114 | - [Critical issue 1] 115 | - [Critical issue 2] 116 | 117 | ### Resolved 118 | - [x] [Resolved issue 1] - Fixed by [solution] 119 | - [x] [Resolved issue 2] - Fixed by [solution] 120 | 121 | ### High Priority 122 | 1. [Category 1] 123 | - [Issue 1] 124 | - [Issue 2] 125 | - [Issue 3] 126 | 127 | 2. [Category 2] 128 | - [Issue 1] 129 | - [Issue 2] 130 | - [Issue 3] 131 | 132 | ### Medium Priority 133 | 1. [Category 1] 134 | - [Issue 1] 135 | - [Issue 2] 136 | - [Issue 3] 137 | 138 | 2. [Category 2] 139 | - [Issue 1] 140 | - [Issue 2] 141 | - [Issue 3] 142 | 143 | ## Release History 144 | 145 | ### [Version Number] ([Date]) 146 | - [Release type] 147 | - Key changes: 148 | * [Change 1] 149 | * [Change 2] 150 | * [Change 3] 151 | * [Change 4] 152 | 153 | ### [Previous Version Number] ([Date]) 154 | - [Release type] 155 | - Key components: 156 | * [Component 1] 157 | * [Component 2] 158 | * [Component 3] 159 | * [Component 4] 160 | 161 | ## Next Milestones 162 | 163 | ### [Version Number] 164 | - [Planned date] 165 | - Key features: 166 | * [Feature 1] 167 | * [Feature 2] 168 | * [Feature 3] 169 | * [Feature 4] 170 | 171 | ### [Version Number] 172 | - [Planned date] 173 | - Key features: 174 | * [Feature 1] 175 | * [Feature 2] 176 | * [Feature 3] 177 | * [Feature 4] 178 | 179 | ### [Version Number] 180 | - [Planned date] 181 | - Key features: 182 | * [Feature 1] 183 | * [Feature 2] 184 | * [Feature 3] 185 | * [Feature 4] 186 | -------------------------------------------------------------------------------- /standard/progress.md: -------------------------------------------------------------------------------- 1 | # Progress Tracking: [Project Name] 2 | 3 | ## Completed Features 4 | 5 | ### [Category 1] 6 | - [x] [Feature 1] 7 | - [x] [Feature 2] 8 | - [x] [Feature 3] 9 | - [x] [Feature 4] 10 | - [x] [Feature 5] 11 | 12 | ### [Category 2] 13 | - [x] [Feature 1] 14 | - [x] [Feature 2] 15 | - [x] [Feature 3] 16 | - [x] [Feature 4] 17 | 18 | ### [Category 3] 19 | - [x] [Feature 1] 20 | - [x] [Feature 2] 21 | - [x] [Feature 3] 22 | 23 | ### Deprecated Features 24 | - [x] [Feature 1] (replaced by [new feature]) 25 | - [x] [Feature 2] (no longer needed) 26 | 27 | ### [Deployment/Integration] 28 | - [x] [Feature 1] 29 | - [x] [Feature 2] 30 | - [x] [Feature 3] 31 | - [x] [Feature 4] 32 | - [x] [Feature 5] 33 | 34 | ## In Progress 35 | 36 | ### [Category 1] 37 | - [x] [Sub-feature 1] 38 | * [Completed aspect] 39 | * [Completed aspect] 40 | - [ ] [Sub-feature 2] 41 | * [In-progress aspect] 42 | * [Planned aspect] 43 | - [ ] [Sub-feature 3] 44 | * [Planned aspect] 45 | * [Planned aspect] 46 | 47 | ### [Category 2] 48 | - [x] [Sub-feature 1] 49 | * [Completed aspect] 50 | * [Completed aspect] 51 | - [ ] [Sub-feature 2] 52 | * [In-progress aspect] 53 | * [Planned aspect] 54 | - [ ] [Sub-feature 3] 55 | * [Planned aspect] 56 | * [Planned aspect] 57 | 58 | ## Planned Features 59 | 60 | ### Short Term 61 | 1. [Category 1] 62 | - [ ] [Feature 1] 63 | - [ ] [Feature 2] 64 | - [ ] [Feature 3] 65 | - [ ] [Feature 4] 66 | 67 | 2. [Category 2] 68 | - [ ] [Feature 1] 69 | - [ ] [Feature 2] 70 | - [ ] [Feature 3] 71 | 72 | 3. [Category 3] 73 | - [ ] [Feature 1] 74 | - [ ] [Feature 2] 75 | - [ ] [Feature 3] 76 | 77 | ### Medium Term 78 | 1. [Category 1] 79 | - [ ] [Feature 1] 80 | - [ ] [Feature 2] 81 | - [ ] [Feature 3] 82 | - [ ] [Feature 4] 83 | 84 | 2. [Category 2] 85 | - [ ] [Feature 1] 86 | - [ ] [Feature 2] 87 | - [ ] [Feature 3] 88 | 89 | 3. [Category 3] 90 | - [ ] [Feature 1] 91 | - [ ] [Feature 2] 92 | - [ ] [Feature 3] 93 | 94 | ### Long Term 95 | 1. [Category 1] 96 | - [ ] [Feature 1] 97 | - [ ] [Feature 2] 98 | - [ ] [Feature 3] 99 | - [ ] [Feature 4] 100 | 101 | 2. [Category 2] 102 | - [ ] [Feature 1] 103 | - [ ] [Feature 2] 104 | - [ ] [Feature 3] 105 | 106 | 3. [Category 3] 107 | - [ ] [Feature 1] 108 | - [ ] [Feature 2] 109 | - [ ] [Feature 3] 110 | 111 | ## Known Issues 112 | 113 | ### Critical 114 | - [Critical issue 1] 115 | - [Critical issue 2] 116 | 117 | ### Resolved 118 | - [x] [Resolved issue 1] - Fixed by [solution] 119 | - [x] [Resolved issue 2] - Fixed by [solution] 120 | 121 | ### High Priority 122 | 1. [Category 1] 123 | - [Issue 1] 124 | - [Issue 2] 125 | - [Issue 3] 126 | 127 | 2. [Category 2] 128 | - [Issue 1] 129 | - [Issue 2] 130 | - [Issue 3] 131 | 132 | ### Medium Priority 133 | 1. [Category 1] 134 | - [Issue 1] 135 | - [Issue 2] 136 | - [Issue 3] 137 | 138 | 2. [Category 2] 139 | - [Issue 1] 140 | - [Issue 2] 141 | - [Issue 3] 142 | 143 | ## Release History 144 | 145 | ### [Version Number] ([Date]) 146 | - [Release type] 147 | - Key changes: 148 | * [Change 1] 149 | * [Change 2] 150 | * [Change 3] 151 | * [Change 4] 152 | 153 | ### [Previous Version Number] ([Date]) 154 | - [Release type] 155 | - Key components: 156 | * [Component 1] 157 | * [Component 2] 158 | * [Component 3] 159 | * [Component 4] 160 | 161 | ## Next Milestones 162 | 163 | ### [Version Number] 164 | - [Planned date] 165 | - Key features: 166 | * [Feature 1] 167 | * [Feature 2] 168 | * [Feature 3] 169 | * [Feature 4] 170 | 171 | ### [Version Number] 172 | - [Planned date] 173 | - Key features: 174 | * [Feature 1] 175 | * [Feature 2] 176 | * [Feature 3] 177 | * [Feature 4] 178 | 179 | ### [Version Number] 180 | - [Planned date] 181 | - Key features: 182 | * [Feature 1] 183 | * [Feature 2] 184 | * [Feature 3] 185 | * [Feature 4] 186 | -------------------------------------------------------------------------------- /standard/README.md: -------------------------------------------------------------------------------- 1 | # Project Memory Bank Templates 2 | 3 | This directory contains template files for setting up a structured Memory Bank for any software project. These templates provide a standardized way to document project context, technical decisions, and progress tracking. 4 | 5 | ## Overview 6 | 7 | The Memory Bank structure follows a hierarchical approach where files build upon each other to provide a complete picture of the project. This approach helps Cline (or other LLM assistants) understand the project thoroughly and provide more accurate assistance. 8 | 9 | ## Memory Bank Files 10 | 11 | 1. **`prompt.md`** - The main memory bank prompt that explains the structure and Git workflow rules 12 | 2. **`.clinerules`** - Project-specific rules, styling guidelines, and best practices 13 | 3. **`projectbrief.md`** - Core requirements, goals, and project scope 14 | 4. **`productContext.md`** - Purpose, problems solved, and expected behavior 15 | 5. **`systemPatterns.md`** - Architecture, technical decisions, and design patterns 16 | 6. **`techContext.md`** - Technology stack, dependencies, and deployment details 17 | 7. **`activeContext.md`** - Current focus, recent changes, and next steps 18 | 8. **`progress.md`** - Tracks completed work, in-progress features, and planned roadmap 19 | 20 | ## How to Use These Templates 21 | 22 | 1. **Create Project Directory**: 23 | ```bash 24 | mkdir -p my-project/memory-bank 25 | ``` 26 | 27 | 2. **Copy Templates**: 28 | ```bash 29 | cp standard/* my-project/memory-bank/ 30 | ``` 31 | 32 | 3. **Customize Templates**: 33 | - Replace all placeholder text (e.g., `[Project Name]`, `[Feature 1]`) with actual project details 34 | - Add project-specific information to each file 35 | - Remove sections that aren't relevant to your project 36 | - Update language-specific references based on your project's programming language 37 | 38 | 4. **Update as Project Evolves**: 39 | - Keep the memory bank files updated as the project progresses 40 | - Document significant changes, decisions, and progress 41 | 42 | ## File Relationships 43 | 44 | The Memory Bank files follow this relationship structure: 45 | 46 | ```mermaid 47 | flowchart TD 48 | PB[projectbrief.md] --> PC[productContext.md] 49 | PB --> SP[systemPatterns.md] 50 | PB --> TC[techContext.md] 51 | 52 | PC --> AC[activeContext.md] 53 | SP --> AC 54 | TC --> AC 55 | 56 | AC --> P[progress.md] 57 | ``` 58 | 59 | ## Best Practices 60 | 61 | 1. **Keep Documentation Updated**: 62 | - Update memory bank files regularly as the project evolves 63 | - Document major decisions and changes immediately 64 | 65 | 2. **Be Specific**: 66 | - Avoid vague descriptions 67 | - Include concrete examples and implementation details 68 | - Link to specific code files when applicable 69 | 70 | 3. **Follow Project Best Practices**: 71 | - Adhere to the code styling rules in `.clinerules` 72 | - Document exported functions, types, and packages 73 | - Maintain clear project structures as outlined in `systemPatterns.md` 74 | 75 | 4. **Track Progress Diligently**: 76 | - Keep `progress.md` up to date with completed features 77 | - Document known issues and their priority 78 | - Update milestone targets as schedules change 79 | 80 | 5. **Git Integration**: 81 | - Follow the Git workflow rules in `prompt.md` 82 | - Commit memory bank updates alongside code changes 83 | - Use the recovery techniques described if code is lost 84 | 85 | ## Template Usage Tips 86 | 87 | - Start by defining the core project information in `projectbrief.md` and `productContext.md` 88 | - Fill in technical details in `systemPatterns.md` and `techContext.md` 89 | - Use `activeContext.md` as a living document for current focus areas 90 | - Update `progress.md` as features are completed or new ones are planned 91 | 92 | By maintaining these memory bank files, you'll create a comprehensive knowledge base that helps both developers and AI assistants understand and contribute to your project more effectively. 93 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Cline Memory Bank Templates 2 | 3 | This repository contains a collection of Memory Bank templates designed to enhance AI assistant interactions, particularly with Cline (Claude). These structured documentation templates enable AI assistants to maintain persistent context across conversations, leading to more effective assistance for complex software projects. 4 | 5 | ## What is a Memory Bank? 6 | 7 | A Memory Bank is a structured set of documentation files that serves as a persistent knowledge base for AI assistants. After each conversation reset or new session, the assistant reads these files to regain context about your project. 8 | 9 | Key benefits: 10 | - **Persistent Context**: AI assistants can maintain project knowledge across sessions 11 | - **Structured Information**: Organized documentation helps the assistant understand project architecture, goals, and progress 12 | - **Efficient Collaboration**: Reduces repetitive explanations and increases productive work 13 | - **Improved Assistance**: Better code suggestions, bug fixes, and architectural guidance 14 | 15 | ## Template Collections 16 | 17 | This repository includes two template collections: 18 | 19 | ### 1. Go Project Templates (`go-template/`) 20 | 21 | Specialized templates for Go projects with: 22 | - Go-specific best practices and coding standards 23 | - Standard Go project structure guidance 24 | - Error handling patterns for Go development 25 | - Documentation patterns for Go packages and functions 26 | 27 | ### 2. Standard Project Templates (`standard/`) 28 | 29 | Language-agnostic templates for any software project: 30 | - Generic coding standards applicable to any language 31 | - Flexible project organization principles 32 | - Universal documentation patterns 33 | - General error handling and security practices 34 | 35 | ## Memory Bank Structure 36 | 37 | Each template collection follows the same core structure: 38 | 39 | ```mermaid 40 | flowchart TD 41 | PB[projectbrief.md] --> PC[productContext.md] 42 | PB --> SP[systemPatterns.md] 43 | PB --> TC[techContext.md] 44 | 45 | PC --> AC[activeContext.md] 46 | SP --> AC 47 | TC --> AC 48 | 49 | AC --> P[progress.md] 50 | ``` 51 | 52 | 1. **`prompt.md`** - Main memory bank prompt explaining structure and Git workflow 53 | 2. **`.clinerules`** - Project rules, styling guidelines, and best practices 54 | 3. **`projectbrief.md`** - Core requirements and goals 55 | 4. **`productContext.md`** - Problem space and solution description 56 | 5. **`systemPatterns.md`** - Architecture and design patterns 57 | 6. **`techContext.md`** - Technology stack and setup 58 | 7. **`activeContext.md`** - Current focus, recent changes, and next steps 59 | 8. **`progress.md`** - Feature progress tracking and roadmap 60 | 61 | ## How to Use These Templates 62 | 63 | 1. **Choose a Template Set**: 64 | - Select `go-template/` for Go projects 65 | - Select `standard/` for other projects 66 | 67 | 2. **Create Project Directory**: 68 | ```bash 69 | mkdir -p my-project/memory-bank 70 | ``` 71 | 72 | 3. **Copy Templates**: 73 | ```bash 74 | # For Go projects 75 | cp go-template/* my-project/memory-bank/ 76 | 77 | # For other projects 78 | cp standard/* my-project/memory-bank/ 79 | ``` 80 | 81 | 4. **Customize Templates**: 82 | - Replace placeholder text with actual project details 83 | - Add project-specific information to each file 84 | - Remove any sections not relevant to your project 85 | 86 | 5. **Reference in AI Conversations**: 87 | - Direct Cline (or another AI assistant) to read these files at the beginning of sessions 88 | - Keep the files updated as your project evolves 89 | 90 | ## Best Practices 91 | 92 | - Keep Memory Bank files updated with project progress 93 | - Document all major decisions and changes 94 | - Commit Memory Bank updates alongside code changes 95 | - Be specific and concrete rather than vague 96 | - Include examples and code snippets when relevant 97 | 98 | ## Public Use and Contributions 99 | 100 | This repository is provided for public use. Feel free to: 101 | - Fork and adapt these templates for your own projects 102 | - Create your own specialized templates for different languages or frameworks 103 | - Share improvements or additional template collections 104 | 105 | Pull requests with improvements or new template collections are welcome. 106 | 107 | ## License 108 | 109 | These templates are available under the Apache License 2.0. See the LICENSE file for details. 110 | -------------------------------------------------------------------------------- /standard/techContext.md: -------------------------------------------------------------------------------- 1 | # Technical Context: [Project Name] 2 | 3 | ## Technology Stack 4 | 5 | ### Core Technologies 6 | 1. [Primary Language/Platform] 7 | - Version: [X.Y]+ 8 | - Key frameworks/libraries 9 | - Core functionality provided 10 | 11 | 2. [Secondary Technology] 12 | - [Purpose in the project] 13 | - [Key features used] 14 | - [Version requirements] 15 | 16 | 3. [Tertiary Technology] 17 | - [Purpose in the project] 18 | - [Key features used] 19 | - [Version requirements] 20 | 21 | ### Dependencies 22 | 23 | 1. [Key Dependency 1] 24 | - [Purpose in the project] 25 | - [Specific features used] 26 | - [Version constraints] 27 | - [License considerations] 28 | 29 | 2. [Key Dependency 2] 30 | - [Purpose in the project] 31 | - [Specific features used] 32 | - [Version constraints] 33 | - [License considerations] 34 | 35 | 3. [Key Dependency 3] 36 | - [Purpose in the project] 37 | - [Specific features used] 38 | - [Version constraints] 39 | - [License considerations] 40 | 41 | ## Development Setup 42 | 43 | ### Prerequisites 44 | 1. Development Tools 45 | - [Language/Platform] [version] 46 | - [Tool 1] 47 | - [Tool 2] 48 | - [Tool 3] 49 | - [IDE/Editor of choice] 50 | 51 | 2. Environment Setup 52 | ```bash 53 | # Install required tools 54 | [Command to install tool 1] 55 | [Command to install tool 2] 56 | 57 | # Setup environment variables 58 | export [ENV_VAR1]=[value1] 59 | export [ENV_VAR2]=[value2] 60 | 61 | # Clone repository 62 | git clone [repository URL] 63 | cd [project directory] 64 | 65 | # Initialize dependencies 66 | [Command to install dependencies] 67 | ``` 68 | 69 | ### Build Process 70 | 1. Building the Application 71 | ```bash 72 | [Build command] 73 | ``` 74 | 75 | 2. Running Tests 76 | ```bash 77 | # Run all tests 78 | [Test command] 79 | 80 | # Run specific test suite 81 | [Specific test command] 82 | 83 | # Generate test coverage report 84 | [Coverage command] 85 | ``` 86 | 87 | 3. Build Scripts/Automation 88 | ```bash 89 | # Build the application 90 | [Build script command] 91 | 92 | # Run tests 93 | [Test script command] 94 | 95 | # Clean build artifacts 96 | [Clean script command] 97 | 98 | # Build and run 99 | [Run script command] 100 | 101 | # Generate documentation 102 | [Documentation script command] 103 | ``` 104 | 105 | ## Deployment 106 | 107 | ### Container Deployment 108 | 1. Container Structure 109 | ``` 110 | project/ 111 | ├── [Container definition file] 112 | ├── [Container ignore file] 113 | └── [Container compose file] (if applicable) 114 | ``` 115 | 116 | 2. Image Building 117 | ```bash 118 | # Build container image 119 | [Command to build container] 120 | 121 | # Run container locally 122 | [Command to run container] 123 | ``` 124 | 125 | 3. Container Registry 126 | - Registry: [Registry name/URL] 127 | - Image naming convention: [convention details] 128 | - Tag strategy: [tag strategy] 129 | 130 | ### Cloud Deployment 131 | 1. [Cloud Provider] 132 | - Service: [Service name] 133 | - Region: [Primary deployment region] 134 | - Configuration: [Key configuration details] 135 | 136 | 2. Infrastructure as Code 137 | - Tool: [IaC tool name] 138 | - Repository: [Repository location] 139 | - Apply process: [Process details] 140 | 141 | ### CI/CD Pipeline 142 | 1. [CI/CD Platform] 143 | - Repository: [Repository location] 144 | - Triggers: [When pipelines run] 145 | - Stages: 146 | * Build 147 | * Test 148 | * Deploy to Staging 149 | * Approval Gate 150 | * Deploy to Production 151 | 152 | ## Technical Constraints 153 | 154 | 1. Resource Limitations 155 | - Memory usage requirements 156 | - CPU usage expectations 157 | - Storage constraints 158 | - Network bandwidth considerations 159 | 160 | 2. Security Constraints 161 | - Authentication requirements 162 | - Authorization model 163 | - Data protection needs 164 | - Compliance requirements (if applicable) 165 | 166 | 3. Operational Constraints 167 | - Availability requirements 168 | - Backup and recovery needs 169 | - Monitoring requirements 170 | - Performance expectations 171 | 172 | ## Development Patterns 173 | 174 | 1. Code Organization 175 | ``` 176 | [Project-specific directory structure] 177 | ``` 178 | 179 | 2. Logging and Telemetry 180 | - Logging library/framework: [name] 181 | - Log format: [format details] 182 | - Log levels: [debug, info, warn, error, etc.] 183 | - Telemetry solution: [solution name if applicable] 184 | 185 | 3. Testing Strategy 186 | - Unit testing approach 187 | - Integration testing approach 188 | - End-to-end testing approach 189 | - Performance testing approach 190 | - Testing tools and libraries: 191 | * [Tool/library 1] 192 | * [Tool/library 2] 193 | 194 | 4. Documentation 195 | - API documentation: [tool/approach] 196 | - Architecture documentation: [location/format] 197 | - Operation guides: [location/format] 198 | - Developer guides: [location/format] 199 | 200 | 5. Configuration Management 201 | - Configuration format: [format] 202 | - Environment variable usage 203 | - Default configuration values 204 | - Configuration validation approach 205 | - Secrets management approach 206 | -------------------------------------------------------------------------------- /standard/systemPatterns.md: -------------------------------------------------------------------------------- 1 | # System Patterns: [Project Name] 2 | 3 | ## Architecture Overview 4 | 5 | ### Core Components 6 | 1. [Component 1] 7 | - [Description and responsibility] 8 | - [Relationship to other components] 9 | - [Key design decisions] 10 | 11 | 2. [Component 2] 12 | - [Description and responsibility] 13 | - [Relationship to other components] 14 | - [Key design decisions] 15 | 16 | 3. [Component 3] 17 | - [Description and responsibility] 18 | - [Relationship to other components] 19 | - [Key design decisions] 20 | 21 | ### Data Flow 22 | - [High-level description of how data flows through the system] 23 | - [Key data transformation points] 24 | - [Critical path description] 25 | 26 | ## Design Patterns 27 | 28 | 1. [Pattern 1] 29 | - [Description and purpose] 30 | - [Where it's applied] 31 | - [Benefits] 32 | 33 | 2. [Pattern 2] 34 | - [Description and purpose] 35 | - [Where it's applied] 36 | - [Benefits] 37 | 38 | 3. [Pattern 3] 39 | - [Description and purpose] 40 | - [Where it's applied] 41 | - [Benefits] 42 | 43 | ## Component Relationships 44 | 45 | 1. [Component 1] → [Component 2] 46 | - [Description of relationship] 47 | - [API/interface details] 48 | - [Error handling expectations] 49 | 50 | 2. [Component 2] → [Component 3] 51 | - [Description of relationship] 52 | - [API/interface details] 53 | - [Error handling expectations] 54 | 55 | ## Code Styling 56 | 57 | ### Project Organization 58 | 59 | 1. Project Structure 60 | - [Language-specific directory structure] 61 | - [Module/package organization] 62 | - [Configuration management] 63 | - [Resource organization] 64 | 65 | 2. File Organization 66 | - [File naming conventions] 67 | - [Code organization within files] 68 | - [Module/class/function grouping strategies] 69 | - [Example structure] 70 | 71 | 3. Function/Method Organization 72 | - [Documentation standards] 73 | - [Parameter/return value documentation] 74 | - [Complexity management] 75 | - [Example documentation] 76 | 77 | ### Source Control Practices 78 | 79 | 1. Git Commit Strategy 80 | - [Commit frequency guidelines] 81 | - [Commit message format] 82 | - [Branch management] 83 | - [Example commit messages] 84 | 85 | 2. Code Recovery with Git 86 | - [Recovery procedures] 87 | - [Stashing strategies] 88 | - [History navigation techniques] 89 | 90 | 3. Branching Strategy 91 | - [Branch naming conventions] 92 | - [Branch lifecycle] 93 | - [Merge/PR strategies] 94 | - [Review requirements] 95 | 96 | ### Formatting and Organization 97 | 98 | 1. Code Formatting 99 | - [Style guide reference] 100 | - [Line length standards] 101 | - [Indentation rules] 102 | - [White space usage] 103 | 104 | 2. Import/Include Organization 105 | - [Grouping strategy] 106 | - [Sorting rules] 107 | - [Example structure] 108 | 109 | 3. Package/Module Organization 110 | - [Organization principles] 111 | - [Naming conventions] 112 | - [Dependency management] 113 | 114 | ### Naming Conventions 115 | 116 | 1. General Naming 117 | - [Case standards for different identifiers] 118 | - [Abbreviation policies] 119 | - [Common prefixes/suffixes and their meanings] 120 | 121 | 2. Component-Specific Naming 122 | - [Naming patterns by component type] 123 | - [Interface/implementation naming] 124 | - [Constant naming] 125 | 126 | 3. Variable Naming 127 | - [Context-specific naming patterns] 128 | - [Temporary vs. long-lived variable naming] 129 | - [Collection naming] 130 | 131 | ### Error Handling Patterns 132 | 133 | 1. Standard Error Handling 134 | - [Error propagation patterns] 135 | - [Logging strategies] 136 | - [Recovery mechanisms] 137 | - [Example code] 138 | 139 | 2. Error Context 140 | - [Context enrichment patterns] 141 | - [Error wrapping strategy] 142 | - [Example code] 143 | 144 | 3. Error Logging 145 | - [Log level usage] 146 | - [Context inclusion] 147 | - [Sensitive data handling] 148 | - [Example code] 149 | 150 | ### Documentation Standards 151 | 152 | 1. Component Documentation 153 | - [Required documentation sections] 154 | - [Format and style] 155 | - [Example documentation] 156 | 157 | 2. API Documentation 158 | - [Documentation format] 159 | - [Required sections] 160 | - [Example documentation] 161 | 162 | 3. Implementation Documentation 163 | - [When to document implementation details] 164 | - [Complex algorithm documentation] 165 | - [Example documentation] 166 | 167 | ### Testing Patterns 168 | 169 | 1. Test Organization 170 | - [Test directory structure] 171 | - [Test naming conventions] 172 | - [Test grouping strategies] 173 | 174 | 2. Test Helpers 175 | - [Helper function patterns] 176 | - [Mock/stub management] 177 | - [Fixture handling] 178 | 179 | 3. Test Coverage 180 | - [Coverage targets] 181 | - [Critical path testing] 182 | - [Edge case handling] 183 | 184 | ## Best Practices 185 | 186 | 1. Resource Management 187 | - [Resource acquisition patterns] 188 | - [Cleanup strategies] 189 | - [Defensive programming techniques] 190 | 191 | 2. Security 192 | - [Input validation] 193 | - [Authentication/authorization patterns] 194 | - [Data protection strategies] 195 | - [Dependency management] 196 | 197 | 3. Performance 198 | - [Optimization strategies] 199 | - [Caching patterns] 200 | - [Resource pooling] 201 | - [Concurrency management] 202 | 203 | 4. Monitoring 204 | - [Logging strategy] 205 | - [Metrics collection] 206 | - [Health check implementation] 207 | - [Alerting strategy] 208 | 209 | 5. Logging Pattern 210 | - [Initialization] 211 | - [Context enrichment] 212 | - [Level usage] 213 | - [Format standards] 214 | - [Example usage] 215 | -------------------------------------------------------------------------------- /standard/activeContext.md: -------------------------------------------------------------------------------- 1 | # Active Context: [Project Name] 2 | 3 | ## Release Status 4 | 5 | ### [Version Number] - [Release Type] 6 | - Tag created: [tag] 7 | - Date: [date] 8 | - Status: [Released/In Progress/Planned] 9 | - Release Type: [Major/Minor/Patch/Release Candidate] 10 | - Key Changes: 11 | * [Change 1] 12 | * [Change 2] 13 | * [Change 3] 14 | * [Change 4] 15 | 16 | ### [Previous Version Number] - [Release Type] 17 | - Tag created: [tag] 18 | - Date: [date] 19 | - Status: [Released/In Progress/Planned] 20 | - Release Type: [Major/Minor/Patch] 21 | - Key Components: 22 | * [Component 1] 23 | * [Component 2] 24 | * [Component 3] 25 | * [Component 4] 26 | 27 | ## Current State 28 | 29 | ### Implementation Status 30 | 1. [Core Component 1] 31 | - Status: [Complete/In Progress/Planned] 32 | - Branch: [branch name] 33 | - Components: 34 | * [Subcomponent 1] 35 | * [Subcomponent 2] 36 | * [Subcomponent 3] 37 | - Key Features: 38 | * [Feature 1] 39 | * [Feature 2] 40 | * [Feature 3] 41 | - Recent Improvements: 42 | * [Improvement 1] 43 | * [Improvement 2] 44 | * [Improvement 3] 45 | 46 | 2. [Core Component 2] 47 | - Status: [Complete/In Progress/Planned] 48 | - Branch: [branch name] 49 | - Components: 50 | * [Subcomponent 1] 51 | * [Subcomponent 2] 52 | * [Subcomponent 3] 53 | - Key Features: 54 | * [Feature 1] 55 | * [Feature 2] 56 | * [Feature 3] 57 | 58 | 3. Implementation Plan: 59 | - Phase 1: [Phase Name] 60 | * [Task 1] 61 | * [Task 2] 62 | * [Task 3] 63 | ✓ [Complete/In Progress] 64 | - Phase 2: [Phase Name] 65 | * [Task 1] 66 | * [Task 2] 67 | * [Task 3] 68 | ✓ [Complete/In Progress] 69 | - Phase 3: [Phase Name] 70 | * [Task 1] 71 | * [Task 2] 72 | * [Task 3] 73 | ✓ [Complete/In Progress] 74 | - Phase 4: [Phase Name] 75 | * [Task 1] 76 | * [Task 2] 77 | * [Task 3] 78 | ✓ [Complete/In Progress] 79 | 80 | ### Active Development Areas 81 | 82 | 1. [Development Area 1] 83 | - Current Focus: [Focus area] 84 | - Status: [In Progress/Planned] 85 | - Priority: [High/Medium/Low] 86 | - Progress Tracking: 87 | * [x] [Task 1] 88 | * [x] [Task 2] 89 | * [ ] [Task 3] 90 | * [ ] [Task 4] 91 | * [ ] [Task 5] 92 | 93 | 2. [Development Area 2] 94 | - Current Focus: [Focus area] 95 | - Status: [In Progress/Planned] 96 | - Priority: [High/Medium/Low] 97 | - Progress Tracking: 98 | * [x] [Task 1] 99 | * [ ] [Task 2] 100 | * [ ] [Task 3] 101 | 102 | 3. [Development Area 3] 103 | - Current Focus: [Focus area] 104 | - Status: [In Progress/Planned] 105 | - Priority: [High/Medium/Low] 106 | - Progress Tracking: 107 | * [ ] [Task 1] 108 | * [ ] [Task 2] 109 | * [ ] [Task 3] 110 | 111 | ## Recent Changes 112 | 113 | 1. [Change Category 1] 114 | - [Change 1 description] 115 | - [Change 2 description] 116 | - [Change 3 description] 117 | 118 | 2. [Change Category 2] 119 | - [Change 1 description] 120 | - [Change 2 description] 121 | - [Change 3 description] 122 | 123 | 3. [Change Category 3] 124 | - [Change 1 description] 125 | - [Change 2 description] 126 | - [Change 3 description] 127 | 128 | 4. [Change Category 4] 129 | - [Change 1 description] 130 | - [Change 2 description] 131 | - [Change 3 description] 132 | 133 | ## Active Decisions 134 | 135 | 1. [Decision Category 1] 136 | - [Decision 1] 137 | - [Decision 2] 138 | - [Decision 3] 139 | 140 | 2. [Decision Category 2] 141 | - [Decision 1] 142 | - [Decision 2] 143 | - [Decision 3] 144 | 145 | 3. [Decision Category 3] 146 | - [Decision 1] 147 | - [Decision 2] 148 | - [Decision 3] 149 | 150 | ## Current Considerations 151 | 152 | 1. [Consideration Category 1] 153 | - [Consideration 1] 154 | - [Consideration 2] 155 | - [Consideration 3] 156 | 157 | 2. [Consideration Category 2] 158 | - [Consideration 1] 159 | - [Consideration 2] 160 | - [Consideration 3] 161 | 162 | 3. [Consideration Category 3] 163 | - [Consideration 1] 164 | - [Consideration 2] 165 | - [Consideration 3] 166 | 167 | ## Current Implementation Tasks 168 | 169 | ### Task 1: [Task Name] 170 | - Status: [Completed/In Progress/Planned] 171 | - Files to Modify: 172 | * [File path 1] 173 | * [File path 2] 174 | * [File path 3] 175 | - Key Changes: 176 | * [Change 1] 177 | * [Change 2] 178 | * [Change 3] 179 | - Success Criteria: 180 | * [Criterion 1] 181 | * [Criterion 2] 182 | * [Criterion 3] 183 | 184 | ### Task 2: [Task Name] 185 | - Status: [Completed/In Progress/Planned] 186 | - Files to Create/Modify: 187 | * [File path 1] 188 | * [File path 2] 189 | * [File path 3] 190 | - Key Changes: 191 | * [Change 1] 192 | * [Change 2] 193 | * [Change 3] 194 | - Success Criteria: 195 | * [Criterion 1] 196 | * [Criterion 2] 197 | * [Criterion 3] 198 | 199 | ### Task 3: [Task Name] 200 | - Status: [Completed/In Progress/Planned] 201 | - Files Created/Modified: 202 | * [File path 1] 203 | * [File path 2] 204 | * [File path 3] 205 | - Key Changes: 206 | * [Change 1] 207 | * [Change 2] 208 | * [Change 3] 209 | - Success Criteria: 210 | * [Criterion 1] 211 | * [Criterion 2] 212 | * [Criterion 3] 213 | 214 | ## Next Steps 215 | 216 | 1. Short Term 217 | - [Short-term task 1] 218 | - [Short-term task 2] 219 | - [Short-term task 3] 220 | - [Short-term task 4] 221 | - [Short-term task 5] 222 | 223 | 2. Medium Term 224 | - [Medium-term task 1] 225 | - [Medium-term task 2] 226 | - [Medium-term task 3] 227 | - [Medium-term task 4] 228 | 229 | 3. Long Term 230 | - [Long-term task 1] 231 | - [Long-term task 2] 232 | - [Long-term task 3] 233 | - [Long-term task 4] 234 | 235 | ## Recent Improvements 236 | 237 | ### [Improvement Area 1] 238 | - Status: [Completed] 239 | - Files Created/Modified: 240 | * [File path 1] 241 | * [File path 2] 242 | * [File path 3] 243 | - Key Features: 244 | * [Feature 1] 245 | * [Feature 2] 246 | * [Feature 3] 247 | - Benefits: 248 | * [Benefit 1] 249 | * [Benefit 2] 250 | * [Benefit 3] 251 | - Implementation Notes: 252 | * [Note 1] 253 | * [Note 2] 254 | * [Note 3] 255 | -------------------------------------------------------------------------------- /go-template/activeContext.md: -------------------------------------------------------------------------------- 1 | # Active Context: [Project Name] 2 | 3 | ## Release Status 4 | 5 | ### [Version Number] - [Release Type] 6 | - Tag created: [tag] 7 | - Date: [date] 8 | - Status: [Released/In Progress/Planned] 9 | - Release Type: [Major/Minor/Patch/Release Candidate] 10 | - Key Changes: 11 | * [Change 1] 12 | * [Change 2] 13 | * [Change 3] 14 | * [Change 4] 15 | 16 | ### [Previous Version Number] - [Release Type] 17 | - Tag created: [tag] 18 | - Date: [date] 19 | - Status: [Released/In Progress/Planned] 20 | - Release Type: [Major/Minor/Patch] 21 | - Key Components: 22 | * [Component 1] 23 | * [Component 2] 24 | * [Component 3] 25 | * [Component 4] 26 | 27 | ## Current State 28 | 29 | ### Implementation Status 30 | 1. [Core Component 1] 31 | - Status: [Complete/In Progress/Planned] 32 | - Branch: [branch name] 33 | - Components: 34 | * [Subcomponent 1] 35 | * [Subcomponent 2] 36 | * [Subcomponent 3] 37 | - Key Features: 38 | * [Feature 1] 39 | * [Feature 2] 40 | * [Feature 3] 41 | - Recent Improvements: 42 | * [Improvement 1] 43 | * [Improvement 2] 44 | * [Improvement 3] 45 | 46 | 2. [Core Component 2] 47 | - Status: [Complete/In Progress/Planned] 48 | - Branch: [branch name] 49 | - Components: 50 | * [Subcomponent 1] 51 | * [Subcomponent 2] 52 | * [Subcomponent 3] 53 | - Key Features: 54 | * [Feature 1] 55 | * [Feature 2] 56 | * [Feature 3] 57 | 58 | 3. Implementation Plan: 59 | - Phase 1: [Phase Name] 60 | * [Task 1] 61 | * [Task 2] 62 | * [Task 3] 63 | ✓ [Complete/In Progress] 64 | - Phase 2: [Phase Name] 65 | * [Task 1] 66 | * [Task 2] 67 | * [Task 3] 68 | ✓ [Complete/In Progress] 69 | - Phase 3: [Phase Name] 70 | * [Task 1] 71 | * [Task 2] 72 | * [Task 3] 73 | ✓ [Complete/In Progress] 74 | - Phase 4: [Phase Name] 75 | * [Task 1] 76 | * [Task 2] 77 | * [Task 3] 78 | ✓ [Complete/In Progress] 79 | 80 | ### Active Development Areas 81 | 82 | 1. [Development Area 1] 83 | - Current Focus: [Focus area] 84 | - Status: [In Progress/Planned] 85 | - Priority: [High/Medium/Low] 86 | - Progress Tracking: 87 | * [x] [Task 1] 88 | * [x] [Task 2] 89 | * [ ] [Task 3] 90 | * [ ] [Task 4] 91 | * [ ] [Task 5] 92 | 93 | 2. [Development Area 2] 94 | - Current Focus: [Focus area] 95 | - Status: [In Progress/Planned] 96 | - Priority: [High/Medium/Low] 97 | - Progress Tracking: 98 | * [x] [Task 1] 99 | * [ ] [Task 2] 100 | * [ ] [Task 3] 101 | 102 | 3. [Development Area 3] 103 | - Current Focus: [Focus area] 104 | - Status: [In Progress/Planned] 105 | - Priority: [High/Medium/Low] 106 | - Progress Tracking: 107 | * [ ] [Task 1] 108 | * [ ] [Task 2] 109 | * [ ] [Task 3] 110 | 111 | ## Recent Changes 112 | 113 | 1. [Change Category 1] 114 | - [Change 1 description] 115 | - [Change 2 description] 116 | - [Change 3 description] 117 | 118 | 2. [Change Category 2] 119 | - [Change 1 description] 120 | - [Change 2 description] 121 | - [Change 3 description] 122 | 123 | 3. [Change Category 3] 124 | - [Change 1 description] 125 | - [Change 2 description] 126 | - [Change 3 description] 127 | 128 | 4. [Change Category 4] 129 | - [Change 1 description] 130 | - [Change 2 description] 131 | - [Change 3 description] 132 | 133 | ## Active Decisions 134 | 135 | 1. [Decision Category 1] 136 | - [Decision 1] 137 | - [Decision 2] 138 | - [Decision 3] 139 | 140 | 2. [Decision Category 2] 141 | - [Decision 1] 142 | - [Decision 2] 143 | - [Decision 3] 144 | 145 | 3. [Decision Category 3] 146 | - [Decision 1] 147 | - [Decision 2] 148 | - [Decision 3] 149 | 150 | ## Current Considerations 151 | 152 | 1. [Consideration Category 1] 153 | - [Consideration 1] 154 | - [Consideration 2] 155 | - [Consideration 3] 156 | 157 | 2. [Consideration Category 2] 158 | - [Consideration 1] 159 | - [Consideration 2] 160 | - [Consideration 3] 161 | 162 | 3. [Consideration Category 3] 163 | - [Consideration 1] 164 | - [Consideration 2] 165 | - [Consideration 3] 166 | 167 | ## Current Implementation Tasks 168 | 169 | ### Task 1: [Task Name] 170 | - Status: [Completed/In Progress/Planned] 171 | - Files to Modify: 172 | * [File path 1] 173 | * [File path 2] 174 | * [File path 3] 175 | - Key Changes: 176 | * [Change 1] 177 | * [Change 2] 178 | * [Change 3] 179 | - Success Criteria: 180 | * [Criterion 1] 181 | * [Criterion 2] 182 | * [Criterion 3] 183 | 184 | ### Task 2: [Task Name] 185 | - Status: [Completed/In Progress/Planned] 186 | - Files to Create/Modify: 187 | * [File path 1] 188 | * [File path 2] 189 | * [File path 3] 190 | - Key Changes: 191 | * [Change 1] 192 | * [Change 2] 193 | * [Change 3] 194 | - Success Criteria: 195 | * [Criterion 1] 196 | * [Criterion 2] 197 | * [Criterion 3] 198 | 199 | ### Task 3: [Task Name] 200 | - Status: [Completed/In Progress/Planned] 201 | - Files Created/Modified: 202 | * [File path 1] 203 | * [File path 2] 204 | * [File path 3] 205 | - Key Changes: 206 | * [Change 1] 207 | * [Change 2] 208 | * [Change 3] 209 | - Success Criteria: 210 | * [Criterion 1] 211 | * [Criterion 2] 212 | * [Criterion 3] 213 | 214 | ## Next Steps 215 | 216 | 1. Short Term 217 | - [Short-term task 1] 218 | - [Short-term task 2] 219 | - [Short-term task 3] 220 | - [Short-term task 4] 221 | - [Short-term task 5] 222 | 223 | 2. Medium Term 224 | - [Medium-term task 1] 225 | - [Medium-term task 2] 226 | - [Medium-term task 3] 227 | - [Medium-term task 4] 228 | 229 | 3. Long Term 230 | - [Long-term task 1] 231 | - [Long-term task 2] 232 | - [Long-term task 3] 233 | - [Long-term task 4] 234 | 235 | ## Recent Improvements 236 | 237 | ### [Improvement Area 1] 238 | - Status: [Completed] 239 | - Files Created/Modified: 240 | * [File path 1] 241 | * [File path 2] 242 | * [File path 3] 243 | - Key Features: 244 | * [Feature 1] 245 | * [Feature 2] 246 | * [Feature 3] 247 | - Benefits: 248 | * [Benefit 1] 249 | * [Benefit 2] 250 | * [Benefit 3] 251 | - Implementation Notes: 252 | * [Note 1] 253 | * [Note 2] 254 | * [Note 3] 255 | -------------------------------------------------------------------------------- /go-template/techContext.md: -------------------------------------------------------------------------------- 1 | # Technical Context: [Project Name] 2 | 3 | ## Technology Stack 4 | 5 | ### Core Technologies 6 | 1. Go (version [X.Y]+) 7 | - Primary implementation language 8 | - Standard library utilization 9 | - Go modules for dependency management 10 | 11 | 2. [Secondary Technology] 12 | - [Purpose in the project] 13 | - [Key features used] 14 | - [Version requirements] 15 | 16 | 3. [Tertiary Technology] 17 | - [Purpose in the project] 18 | - [Key features used] 19 | - [Version requirements] 20 | 21 | ### Dependencies 22 | 23 | 1. [Key Dependency 1] 24 | ```go 25 | [import path] 26 | ``` 27 | - [Purpose in the project] 28 | - [Specific features used] 29 | - [Version constraints] 30 | 31 | 2. [Key Dependency 2] 32 | ```go 33 | [import path] 34 | ``` 35 | - [Purpose in the project] 36 | - [Specific features used] 37 | - [Version constraints] 38 | 39 | 3. [Key Dependency 3] 40 | ```go 41 | [import path] 42 | ``` 43 | - [Purpose in the project] 44 | - [Specific features used] 45 | - [Version constraints] 46 | 47 | ## Development Setup 48 | 49 | ### Prerequisites 50 | 1. Development Tools 51 | - Go [version] 52 | - [Tool 1] 53 | - [Tool 2] 54 | - [Tool 3] 55 | - [IDE/Editor of choice] 56 | 57 | 2. Environment Setup 58 | ```bash 59 | # Install required tools 60 | go install [tool1]@[version] 61 | go install [tool2]@[version] 62 | 63 | # Setup environment variables 64 | export [ENV_VAR1]=[value1] 65 | export [ENV_VAR2]=[value2] 66 | 67 | # Clone repository 68 | git clone [repository URL] 69 | cd [project directory] 70 | 71 | # Initialize dependencies 72 | go mod download 73 | ``` 74 | 75 | ### Build Process 76 | 1. Building the Application 77 | ```bash 78 | go build -o [output name] [main file path] 79 | ``` 80 | 81 | 2. Running Tests 82 | ```bash 83 | # Run tests with default verbosity 84 | go test ./... 85 | 86 | # Run tests with verbose output 87 | go test -v ./... 88 | 89 | # Run tests with coverage 90 | go test -cover ./... 91 | 92 | # Generate coverage report 93 | go test -coverprofile=coverage.out ./... 94 | go tool cover -html=coverage.out 95 | ``` 96 | 97 | 3. Makefile Options (if applicable) 98 | ```bash 99 | # Build the application 100 | make build 101 | 102 | # Run tests 103 | make test 104 | 105 | # Clean build artifacts 106 | make clean 107 | 108 | # Build and run 109 | make run 110 | 111 | # Generate documentation 112 | make docs 113 | ``` 114 | 115 | ## Deployment 116 | 117 | ### Container Deployment 118 | 1. Dockerfile Structure 119 | ``` 120 | project/ 121 | ├── Dockerfile 122 | ├── .dockerignore 123 | └── docker-compose.yml (if applicable) 124 | ``` 125 | 126 | 2. Image Building 127 | ```bash 128 | # Build container image 129 | docker build -t [image name]:[tag] . 130 | 131 | # Run container locally 132 | docker run -p [host port]:[container port] [image name]:[tag] 133 | ``` 134 | 135 | 3. Container Registry 136 | - Registry: [Registry name/URL] 137 | - Image naming convention: [convention details] 138 | - Tag strategy: [tag strategy] 139 | 140 | ### Cloud Deployment 141 | 1. [Cloud Provider] 142 | - Service: [Service name (e.g., GKE, ECS, App Engine)] 143 | - Region: [Primary deployment region] 144 | - Configuration: [Key configuration details] 145 | 146 | 2. Infrastructure as Code 147 | - Tool: [e.g., Terraform, Pulumi, CloudFormation] 148 | - Repository: [Repository location] 149 | - Apply process: [Process details] 150 | 151 | ### CI/CD Pipeline 152 | 1. [CI/CD Platform] 153 | - Repository: [Repository location] 154 | - Triggers: [When pipelines run] 155 | - Stages: 156 | * Build 157 | * Test 158 | * Deploy to Staging 159 | * Approval Gate 160 | * Deploy to Production 161 | 162 | ## Technical Constraints 163 | 164 | 1. Resource Limitations 165 | - Memory usage requirements 166 | - CPU usage expectations 167 | - Storage constraints 168 | - Network bandwidth considerations 169 | 170 | 2. Security Constraints 171 | - Authentication requirements 172 | - Authorization model 173 | - Data protection needs 174 | - Compliance requirements (if applicable) 175 | 176 | 3. Operational Constraints 177 | - Availability requirements 178 | - Backup and recovery needs 179 | - Monitoring requirements 180 | - Performance expectations 181 | 182 | ## Development Patterns 183 | 184 | 1. Code Organization 185 | ``` 186 | ├── cmd/ # Command-line applications 187 | │ └── [app name]/ # Main application entry point 188 | │ └── main.go # Application entrypoint 189 | ├── pkg/ # Public library packages 190 | │ ├── [component 1]/ # Component 1 implementation 191 | │ └── [component 2]/ # Component 2 implementation 192 | ├── internal/ # Private implementation packages 193 | │ ├── [component 3]/ # Internal component 1 194 | │ └── [component 4]/ # Internal component 2 195 | ├── api/ # API definitions (proto files, OpenAPI specs) 196 | ├── web/ # Web assets (if applicable) 197 | ├── configs/ # Configuration files 198 | ├── scripts/ # Helper scripts 199 | └── test/ # Integration and end-to-end tests 200 | ``` 201 | 202 | 2. Logging and Telemetry 203 | - Logging library: [library name] 204 | - Log format: [format details] 205 | - Log levels: [debug, info, warn, error, etc.] 206 | - Telemetry solution: [solution name if applicable] 207 | 208 | 3. Testing Strategy 209 | - Unit tests for all packages 210 | - Integration tests for component interaction 211 | - End-to-end tests for critical flows 212 | - Performance testing for key operations 213 | - Testing tools and libraries: 214 | * [Tool/library 1] 215 | * [Tool/library 2] 216 | 217 | 4. Documentation 218 | - API documentation: [godoc, custom solution, etc.] 219 | - Architecture documentation: [location/format] 220 | - Operation guides: [location/format] 221 | - Developer guides: [location/format] 222 | 223 | 5. Configuration Management 224 | - Configuration format: [YAML, JSON, TOML, etc.] 225 | - Environment variable usage 226 | - Default configuration values 227 | - Configuration validation approach 228 | - Secrets management 229 | -------------------------------------------------------------------------------- /standard/prompt.md: -------------------------------------------------------------------------------- 1 | # Project Memory Bank System 2 | 3 | ## Role and Expertise 4 | You are Cline, a world-class full-stack developer and UI/UX designer. Your expertise covers: 5 | - Rapid, efficient application development 6 | - The full spectrum from MVP creation to complex system architecture 7 | - Intuitive and beautiful design 8 | 9 | Adapt your approach based on project needs and user preferences, always aiming to guide users in efficiently creating functional applications. 10 | 11 | ## Core Purpose 12 | This memory bank system enables AI assistants to maintain persistent context for complex projects. It provides structured documentation that's critical for understanding project architecture, design decisions, and current development state. 13 | 14 | ## Objectives 15 | - Maintain project continuity across sessions 16 | - **Prioritize incremental improvements over large-scale refactoring**: 17 | - Make targeted, small changes when possible 18 | - Focus on fixing specific issues rather than rewriting systems 19 | - Improve code incrementally to minimize disruption 20 | - Preserve existing functionality while making enhancements 21 | - Ensure **systems function effectively** with minimal disruption 22 | 23 | ## AI Assistant Guidelines 24 | 1. **Persistent Context** – After each conversation reset or new session, the AI assistant **must rely entirely** on the Memory Bank to understand the project and continue effective assistance. 25 | 2. **Mandatory Pre-Task Review** – At the start of **each new task**, the AI assistant **must**: 26 | - **Read all Memory Bank files** without exception 27 | - **Validate project structure** (e.g., verify file access, confirm dependencies) 28 | - **Identify potential issues** before proceeding with any work 29 | ## **Documentation Systems** 30 | 31 | ### **Core Documentation: Memory Bank** 32 | The primary documentation system is the Memory Bank - a structured set of Markdown files that maintain project context across sessions. 33 | 34 | ### **Supplementary Documentation: cline_docs** 35 | In addition to the Memory Bank, maintain a 'cline_docs' folder in the root directory (create if it doesn't exist) with these files: 36 | 37 | 1. **projectRoadmap.md** - High-level goals and progress tracking 38 | - Track project goals, features, and completion criteria 39 | - Maintain a "completed tasks" section for history 40 | - Use checkboxes for task tracking (- [ ] / - [x]) 41 | 42 | 2. **currentTask.md** - Current objectives and next steps 43 | - Update after completing each task or subtask 44 | - Reference tasks from projectRoadmap.md 45 | - Include context and clear next steps 46 | 47 | 3. **techStack.md** - Technology choices and architecture decisions 48 | - Update when technology decisions change 49 | - Detail technologies with brief justifications 50 | 51 | 4. **codebaseSummary.md** - Overview of project structure 52 | - Include sections on components, data flow, dependencies 53 | - Document recent changes and their impact 54 | 55 | ### **Workflow Guidelines** 56 | - Read documentation in order: projectRoadmap → currentTask → techStack → codebaseSummary 57 | - Update documents based on significant changes, not minor steps 58 | - If conflicting information exists between documents, request clarification 59 | - Prioritize frequent testing during development 60 | 61 | ## **Git Workflow Rules** 62 | - Commit code after every meaningful change 63 | - Restore lost code before continuing new work 64 | - Restoring code takes priority over new changes 65 | 66 | ### **Standard Workflow** 67 | 1. Create feature branches for changes 68 | 2. Commit changes with descriptive messages 69 | 3. Merge completed work to main branch 70 | 71 | ### **Work Recovery Process** 72 | If code is lost, follow these recovery steps in order: 73 | 74 | 1. **Check History** (`git reflog`) to find and restore previous commits 75 | 2. **Find Uncommitted Changes** (`git fsck --lost-found`) 76 | 3. **Compare Differences** (`git diff HEAD~1 HEAD` or `git log -p -1`) 77 | 4. **Restore from Commits** (`git cherry-pick`) 78 | 79 | Always verify full recovery before proceeding with new work. 80 | 81 | ## **Memory Bank Structure** 82 | 83 | The Memory Bank consists of required core files in Markdown format, following this hierarchy: 84 | 85 | ```mermaid 86 | flowchart TD 87 | PB[projectbrief.md] --> PC[productContext.md] 88 | PB --> SP[systemPatterns.md] 89 | PB --> TC[techContext.md] 90 | 91 | PC --> AC[activeContext.md] 92 | SP --> AC 93 | TC --> AC 94 | 95 | AC --> P[progress.md] 96 | ``` 97 | 98 | ### **Core Files (Required)** 99 | 1. **`projectbrief.md`** – Defines core requirements and goals 100 | 2. **`productContext.md`** – Describes purpose, problems solved, and expected behavior 101 | 3. **`activeContext.md`** – Current focus, recent changes, next steps 102 | 4. **`systemPatterns.md`** – Defines architecture, key technical decisions, and design patterns 103 | 5. **`techContext.md`** – Specifies hosting environment and deployment pipelines 104 | 6. **`progress.md`** – Tracks what works, what's left, and known issues 105 | 106 | ## **Operational Workflows** 107 | 108 | ### **Plan Mode** 109 | ```mermaid 110 | flowchart TD 111 | Start[Start] --> ReadFiles[Read Memory Bank] 112 | ReadFiles --> CheckFiles{Files Complete?} 113 | 114 | CheckFiles -->|No| Plan[Create Plan] 115 | Plan --> Document[Document in Chat] 116 | 117 | CheckFiles -->|Yes| Verify[Verify Context] 118 | Verify --> Strategy[Develop Strategy] 119 | Strategy --> Present[Present Approach] 120 | ``` 121 | 122 | ### **Act Mode** 123 | ```mermaid 124 | flowchart TD 125 | Start[Start] --> Context[Check Memory Bank] 126 | Context --> Update[Update Documentation] 127 | Update --> Rules[Update .clinerules if needed] 128 | Rules --> Execute[Execute Task] 129 | Execute --> Commit[Commit to Git] 130 | Commit --> Validate[Validate State] 131 | Validate --> Document[Document Changes] 132 | ``` 133 | 134 | ## **Best Practices** 135 | ### **User Interaction** 136 | - Ask follow-up questions only when critical information is missing 137 | - Adjust approach based on project complexity and user preferences 138 | - Minimize back-and-forth while ensuring task completion 139 | - Present technical decisions concisely for user feedback 140 | 141 | ### **Code Management** 142 | - Organize projects efficiently based on type and dependencies 143 | - Create modular, reusable components 144 | - Follow tech stack best practices 145 | - Document code with clear comments 146 | - Test frequently throughout development 147 | - **Prefer small, targeted changes over large refactors**: 148 | - Fix isolated issues with minimal code changes 149 | - Maintain existing patterns when adding new features 150 | - Refactor only when necessary and in small, testable increments 151 | 152 | ## **Critical Requirements** 153 | - Read and verify the Memory Bank before making changes 154 | - Document all major changes 155 | - Commit to Git for every meaningful change 156 | - Use Git recovery tools to restore lost work 157 | - Never proceed with new work until previous work is recovered 158 | - Take time between steps to allow for testing 159 | -------------------------------------------------------------------------------- /go-template/prompt.md: -------------------------------------------------------------------------------- 1 | # Go Project Memory Bank System 2 | 3 | ## Role and Expertise 4 | You are Cline, a world-class GO developer. Your expertise covers: 5 | - Rapid, efficient Go application development 6 | - The full spectrum from Go MVPs to complex system architecture 7 | - Clean, well-structured Go code following best practices 8 | 9 | Adapt your approach based on project needs and user preferences, always aiming to guide users in efficiently creating functional Go applications. 10 | 11 | ## Core Purpose 12 | This memory bank system enables AI assistants to maintain persistent context for complex Go projects. It provides structured documentation that's critical for understanding project architecture, design decisions, and current development state. 13 | 14 | ## Objectives 15 | - Maintain project continuity across sessions 16 | - **Prioritize incremental improvements over large-scale refactoring**: 17 | - Make targeted, small changes when possible 18 | - Focus on fixing specific issues rather than rewriting systems 19 | - Improve Go code incrementally to minimize disruption 20 | - Preserve existing functionality while making enhancements 21 | - Ensure **systems function effectively** with minimal disruption 22 | 23 | ## AI Assistant Guidelines 24 | 1. **Persistent Context** – After each conversation reset or new session, the AI assistant **must rely entirely** on the Memory Bank to understand the project and continue effective assistance. 25 | 2. **Mandatory Pre-Task Review** – At the start of **each new task**, the AI assistant **must**: 26 | - **Read all Memory Bank files** without exception 27 | - **Validate project structure** (e.g., verify file access, confirm dependencies) 28 | - **Identify potential issues** before proceeding with any work 29 | 30 | ## **Documentation Systems** 31 | 32 | ### **Core Documentation: Memory Bank** 33 | The primary documentation system is the Memory Bank - a structured set of Markdown files that maintain project context across sessions. 34 | 35 | ### **Supplementary Documentation: cline_docs** 36 | In addition to the Memory Bank, maintain a 'cline_docs' folder in the root directory (create if it doesn't exist) with these files: 37 | 38 | 1. **projectRoadmap.md** - High-level goals and progress tracking 39 | - Track project goals, features, and completion criteria 40 | - Maintain a "completed tasks" section for history 41 | - Use checkboxes for task tracking (- [ ] / - [x]) 42 | 43 | 2. **currentTask.md** - Current objectives and next steps 44 | - Update after completing each task or subtask 45 | - Reference tasks from projectRoadmap.md 46 | - Include context and clear next steps 47 | 48 | 3. **techStack.md** - Technology choices and architecture decisions 49 | - Update when technology decisions change 50 | - Detail Go-specific technologies with brief justifications 51 | - Document key packages and dependencies 52 | 53 | 4. **codebaseSummary.md** - Overview of project structure 54 | - Include sections on components, data flow, dependencies 55 | - Document package structure and relationships 56 | - Track recent changes and their impact 57 | 58 | ### **Workflow Guidelines** 59 | - Read documentation in order: projectRoadmap → currentTask → techStack → codebaseSummary 60 | - Update documents based on significant changes, not minor steps 61 | - If conflicting information exists between documents, request clarification 62 | - Prioritize frequent testing during development 63 | 64 | ## **Git Workflow Rules** 65 | - Commit code after every meaningful change 66 | - Restore lost code before continuing new work 67 | - Restoring code takes priority over new changes 68 | 69 | ### **Standard Workflow** 70 | 1. Create feature branches for changes 71 | 2. Commit changes with descriptive messages 72 | 3. Merge completed work to main branch 73 | 74 | ### **Work Recovery Process** 75 | If code is lost, follow these recovery steps in order: 76 | 77 | 1. **Check History** (`git reflog`) to find and restore previous commits 78 | 2. **Find Uncommitted Changes** (`git fsck --lost-found`) 79 | 3. **Compare Differences** (`git diff HEAD~1 HEAD` or `git log -p -1`) 80 | 4. **Restore from Commits** (`git cherry-pick`) 81 | 82 | Always verify full recovery before proceeding with new work. 83 | 84 | ## **Memory Bank Structure** 85 | 86 | The Memory Bank consists of required core files in Markdown format, following this hierarchy: 87 | 88 | ```mermaid 89 | flowchart TD 90 | PB[projectbrief.md] --> PC[productContext.md] 91 | PB --> SP[systemPatterns.md] 92 | PB --> TC[techContext.md] 93 | 94 | PC --> AC[activeContext.md] 95 | SP --> AC 96 | TC --> AC 97 | 98 | AC --> P[progress.md] 99 | ``` 100 | 101 | ### **Core Files (Required)** 102 | 1. **`projectbrief.md`** – Defines core requirements and goals 103 | 2. **`productContext.md`** – Describes purpose, problems solved, and expected behavior 104 | 3. **`activeContext.md`** – Current focus, recent changes, next steps 105 | 4. **`systemPatterns.md`** – Defines architecture, key technical decisions, and design patterns 106 | 5. **`techContext.md`** – Specifies hosting environment and deployment pipelines 107 | 6. **`progress.md`** – Tracks what works, what's left, and known issues 108 | 109 | ## **Operational Workflows** 110 | 111 | ### **Plan Mode** 112 | ```mermaid 113 | flowchart TD 114 | Start[Start] --> ReadFiles[Read Memory Bank] 115 | ReadFiles --> CheckFiles{Files Complete?} 116 | 117 | CheckFiles -->|No| Plan[Create Plan] 118 | Plan --> Document[Document in Chat] 119 | 120 | CheckFiles -->|Yes| Verify[Verify Context] 121 | Verify --> Strategy[Develop Strategy] 122 | Strategy --> Present[Present Approach] 123 | ``` 124 | 125 | ### **Act Mode** 126 | ```mermaid 127 | flowchart TD 128 | Start[Start] --> Context[Check Memory Bank] 129 | Context --> Update[Update Documentation] 130 | Update --> Rules[Update .clinerules if needed] 131 | Rules --> Execute[Execute Task] 132 | Execute --> Commit[Commit to Git] 133 | Commit --> Validate[Validate State] 134 | Validate --> Document[Document Changes] 135 | ``` 136 | 137 | ## **Best Practices** 138 | ### **User Interaction** 139 | - Ask follow-up questions only when critical information is missing 140 | - Adjust approach based on project complexity and user preferences 141 | - Minimize back-and-forth while ensuring task completion 142 | - Present technical decisions concisely for user feedback 143 | 144 | ### **Go-Specific Code Management** 145 | - Organize projects following standard Go project layout 146 | - Create modular, reusable components 147 | - Follow Go best practices for error handling and package design 148 | - Document code with clear comments 149 | - **Test-Driven Development for Go**: 150 | - Write tests concurrently with function development, not after 151 | - Add or update tests for every function created or modified 152 | - Follow Go's testing conventions (`*_test.go` files in the same package) 153 | - Include both unit tests and integration tests where appropriate 154 | - Use table-driven tests for testing multiple scenarios efficiently 155 | - Aim for high test coverage, especially for critical business logic 156 | - Use Go's built-in testing and benchmarking tools 157 | - **Prefer small, targeted changes over large refactors**: 158 | - Fix isolated issues with minimal code changes 159 | - Maintain existing Go idioms and patterns when adding new features 160 | - Refactor only when necessary and in small, testable increments 161 | - Preserve API compatibility when making changes 162 | 163 | ## **Critical Requirements** 164 | - Read and verify the Memory Bank before making changes 165 | - Document all major changes 166 | - Commit to Git for every meaningful change 167 | - Use Git recovery tools to restore lost work 168 | - Never proceed with new work until previous work is recovered 169 | - Take time between steps to allow for testing 170 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /go-template/systemPatterns.md: -------------------------------------------------------------------------------- 1 | # System Patterns: [Project Name] 2 | 3 | ## Architecture Overview 4 | 5 | ### Core Components 6 | 1. [Component 1] 7 | - [Description and responsibility] 8 | - [Relationship to other components] 9 | - [Key design decisions] 10 | 11 | 2. [Component 2] 12 | - [Description and responsibility] 13 | - [Relationship to other components] 14 | - [Key design decisions] 15 | 16 | 3. [Component 3] 17 | - [Description and responsibility] 18 | - [Relationship to other components] 19 | - [Key design decisions] 20 | 21 | ### Data Flow 22 | - [High-level description of how data flows through the system] 23 | - [Key data transformation points] 24 | - [Critical path description] 25 | 26 | ## Design Patterns 27 | 28 | 1. [Pattern 1] 29 | - [Description and purpose] 30 | - [Where it's applied] 31 | - [Benefits] 32 | 33 | 2. [Pattern 2] 34 | - [Description and purpose] 35 | - [Where it's applied] 36 | - [Benefits] 37 | 38 | 3. [Pattern 3] 39 | - [Description and purpose] 40 | - [Where it's applied] 41 | - [Benefits] 42 | 43 | ## Component Relationships 44 | 45 | 1. [Component 1] → [Component 2] 46 | - [Description of relationship] 47 | - [API/interface details] 48 | - [Error handling expectations] 49 | 50 | 2. [Component 2] → [Component 3] 51 | - [Description of relationship] 52 | - [API/interface details] 53 | - [Error handling expectations] 54 | 55 | ## Go Code Styling 56 | 57 | ### Project Organization 58 | 59 | 1. Project Structure 60 | - `main.go` should be kept as small as possible, serving only as the application entrypoint 61 | - All packages should be placed under the `./pkg/` directory 62 | - Command-line tools should be in `./cmd/` 63 | - Use `./internal/` for packages that should not be imported by other projects 64 | - Configuration in `./config/` 65 | - Tests should be in the same package as the code they test (e.g., `foo_test.go` alongside `foo.go`) 66 | 67 | 2. File Organization 68 | - Break up package files into multiple smaller files, keeping each under 300 lines 69 | - Group small utility, helper, and setup functions in a `util.go` file within each package 70 | - Name files according to their primary responsibility (e.g., `server.go`, `handler.go`, `client.go`) 71 | - Example package structure: 72 | ``` 73 | pkg/service/ 74 | ├── client.go // Client setup and operations 75 | ├── handler.go // Request handling logic 76 | ├── server.go // Server initialization and configuration 77 | ├── model.go // Data models and types 78 | └── util.go // Small utility and helper functions 79 | ``` 80 | 81 | 3. Function Organization 82 | - Each exported function must have a detailed comment explaining what it does 83 | - Example function documentation: 84 | ```go 85 | // ProcessRequest handles incoming requests by validating the input, 86 | // performing the required business logic, and returning a response. 87 | // It includes error handling for invalid inputs and processing failures. 88 | // 89 | // Parameters: 90 | // - ctx: Context for the operation 91 | // - req: The request to process 92 | // 93 | // Returns: 94 | // - Response: The processed result 95 | // - error: Any error encountered during processing 96 | func ProcessRequest(ctx context.Context, req *Request) (*Response, error) { 97 | // Implementation 98 | } 99 | ``` 100 | 101 | ### Source Control Practices 102 | 103 | 1. Git Commit Strategy 104 | - Make frequent, small commits while coding to create recovery points 105 | - Each commit should represent a logical unit of work 106 | - Use descriptive commit messages with a clear structure: 107 | ``` 108 | [Component] Brief description of change 109 | 110 | More detailed explanation if needed 111 | ``` 112 | - Example commit messages: 113 | ``` 114 | [API] Add pagination support to list endpoint 115 | 116 | Adds query parameters for page size and number with 117 | appropriate validation and documentation. 118 | ``` 119 | ``` 120 | [CLI] Fix error handling in config command 121 | 122 | Improves error messages when config file is invalid and adds 123 | validation for required fields. 124 | ``` 125 | 126 | 2. Code Recovery with Git 127 | - Use git to recover accidentally deleted code: 128 | ```bash 129 | # Find the commit where code was deleted 130 | git log -p -- path/to/file.go 131 | 132 | # Recover specific file from a previous commit without affecting other files 133 | git checkout [commit-hash] -- path/to/file.go 134 | 135 | # For recovering just part of a file, use git blame to find the right commit 136 | git blame path/to/file.go 137 | 138 | # Then checkout that specific file and manually extract the needed parts 139 | git checkout [commit-hash] -- path/to/file.go 140 | ``` 141 | - Consider using `git stash` to temporarily save changes when switching tasks: 142 | ```bash 143 | # Save current changes 144 | git stash save "description of changes" 145 | 146 | # List saved stashes 147 | git stash list 148 | 149 | # Apply a specific stash (keeping it in the stash list) 150 | git stash apply stash@{0} 151 | 152 | # Remove stash after applying it 153 | git stash pop 154 | ``` 155 | 156 | 3. Branching Strategy 157 | - Use feature branches for new features or significant changes 158 | - Keep feature branches short-lived (1-5 days) 159 | - Regularly rebase feature branches on the main branch 160 | - Use pull requests for code review 161 | - Clean up branches after merging 162 | 163 | ### Formatting and Organization 164 | 165 | 1. Code Formatting 166 | - Use `go fmt` or `gofmt` for automatic formatting 167 | - Maintain 80-100 character line length where reasonable 168 | - Follow standard Go indentation (tabs, not spaces) 169 | - Run formatting before committing: `go fmt ./...` 170 | 171 | 2. Import Organization 172 | - Group imports in three distinct blocks: 173 | * Standard library 174 | * External dependencies 175 | * Internal project packages 176 | ```go 177 | import ( 178 | "context" 179 | "fmt" 180 | "time" 181 | 182 | "github.com/example/external/package" 183 | "github.com/another/dependency" 184 | 185 | "github.com/your-org/your-project/pkg/logging" 186 | ) 187 | ``` 188 | - Use explicit import names when necessary to avoid collisions 189 | - Avoid dot imports (e.g., `import . "fmt"`) 190 | 191 | 3. Package Organization 192 | - Organize packages by functional domain, not by type 193 | - Keep package names short, clear, and descriptive 194 | - Avoid package name collisions with common libraries 195 | - Follow established package patterns: 196 | * cmd/[executable] - Command-line executables 197 | * pkg/[component] - Public library packages 198 | * internal/[component] - Private implementation packages 199 | 200 | ### Naming Conventions 201 | 202 | 1. General Naming 203 | - Use camelCase for private identifiers 204 | - Use PascalCase for exported identifiers 205 | - Avoid abbreviations except for common ones (e.g., HTTP, API, URL) 206 | - Be explicit and descriptive in naming 207 | 208 | 2. Package-Specific Naming 209 | - Types should have descriptive names that reflect their purpose 210 | - Methods should start with verbs that describe what they do 211 | - Constants should be ALL_CAPS with underscores 212 | - Interfaces should end with 'er' if they describe behavior (e.g., `Reader`, `Writer`, `Formatter`) 213 | 214 | 3. Variable Naming 215 | - Contextual variables: `ctx` for context.Context 216 | - Loop indices: `i`, `j`, etc., or descriptive names for complex loops 217 | - Error returns: `err` 218 | - Short-lived variables: short names are acceptable 219 | - Long-lived variables: descriptive names that explain purpose 220 | 221 | ### Error Handling Patterns 222 | 223 | 1. Standard Error Handling 224 | ```go 225 | if err != nil { 226 | // Log the error with context 227 | log.WithError(err).WithField("input", input).Error("operation failed") 228 | 229 | // Return with error 230 | return nil, fmt.Errorf("failed to process request: %w", err) 231 | } 232 | ``` 233 | 234 | 2. Error Wrapping 235 | - Wrap errors with context using `fmt.Errorf("context: %w", err)` 236 | - Include relevant details when wrapping errors 237 | - Use error wrapping for operation context, not just message 238 | 239 | 3. Error Logging 240 | - Use structured logging with error fields: 241 | ```go 242 | log.WithError(err).WithField("requestID", req.ID).Error("failed to process request") 243 | ``` 244 | - Include appropriate context in error logs 245 | - Use consistent verbosity levels 246 | 247 | ### Documentation Standards 248 | 249 | 1. Package Documentation 250 | - Add package documentation comments at the top of each package's primary file: 251 | ```go 252 | // Package handler implements HTTP handlers for the API endpoints. 253 | // It processes incoming requests, performs necessary validations, 254 | // and delegates to the appropriate service components. 255 | package handler 256 | ``` 257 | 258 | 2. Type and Function Documentation 259 | - Document all exported types and functions with detailed comments 260 | - Include usage examples for complex functions 261 | - Document all parameters and return values 262 | ```go 263 | // ProcessItem processes an item according to the provided configuration. 264 | // 265 | // It validates the item, applies processing rules, and returns the 266 | // processed result. If validation fails or processing encounters an error, 267 | // it returns an appropriate error. 268 | // 269 | // Parameters: 270 | // - ctx: Context for the operation 271 | // - item: The item to process 272 | // - config: Processing configuration options 273 | // 274 | // Returns: 275 | // - result: The processed item result 276 | // - error: Any error encountered during processing 277 | func ProcessItem(ctx context.Context, item *Item, config Config) (*Result, error) { 278 | // Implementation 279 | } 280 | ``` 281 | 282 | 3. Implementation Comments 283 | - Add comments for complex or non-obvious code sections 284 | - Explain algorithm choices and design decisions 285 | - Document known limitations or edge cases 286 | 287 | ### Testing Patterns 288 | 289 | 1. Test Organization 290 | - Use table-driven tests for multiple test cases 291 | - Group related test cases 292 | - Name tests clearly: `TestFunctionName_Scenario` 293 | 294 | 2. Test Helpers 295 | - Create shared test fixtures and helpers 296 | - Use testing.T helpers for common assertions 297 | - Isolate test dependencies 298 | 299 | 3. Test Coverage 300 | - Aim for high test coverage on core business logic 301 | - Test error cases and edge conditions 302 | - Include integration tests for component interaction 303 | 304 | ## Best Practices 305 | 306 | 1. Resource Management 307 | - Use defer for cleanup operations 308 | - Close resources in the reverse order of acquisition 309 | - Implement io.Closer interface where appropriate 310 | - Consider using sync.Pool for frequently allocated resources 311 | 312 | 2. Security 313 | - Validate all user inputs 314 | - Use prepared statements for database queries 315 | - Implement proper authentication and authorization 316 | - Follow the principle of least privilege 317 | - Keep dependencies updated and scan for vulnerabilities 318 | 319 | 3. Performance 320 | - Profile before optimizing 321 | - Use buffered I/O operations 322 | - Consider connection pooling for external services 323 | - Implement caching where appropriate 324 | - Use concurrency with care and proper synchronization 325 | 326 | 4. Monitoring 327 | - Implement health checks 328 | - Expose metrics for monitoring 329 | - Use structured logging 330 | - Add tracingfor complex operations 331 | 332 | 5. Logging Pattern 333 | - Package-level logger initialization via logger.go 334 | - Shared logging setup across packages 335 | - Consistent logging interface 336 | - Example logging setup: 337 | ```go 338 | // logger.go in each package 339 | package mypackage 340 | 341 | import "github.com/project/pkg/logging" 342 | 343 | var log = logging.GetLogger("mypackage") 344 | ``` 345 | - Usage pattern in package files: 346 | ```go 347 | log.Info("message") 348 | log.WithError(err).Error("error message") 349 | ``` 350 | - Benefits: 351 | * Centralized logging configuration 352 | * Consistent logging format 353 | * Package-level logging control 354 | * Clean separation of concerns 355 | * Easy logging level management 356 | --------------------------------------------------------------------------------