| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 1 | 12 | 11 | 4% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 1 | 1 | 33% |
What each file covers
Sections
1 shared · 12 only in A · 11 only in B- − 🔄 Active Context
- − Current Focus
- − Recent Changes
- − Current Challenges
- − Active Decisions
- − Key Patterns & Preferences
- − Code Patterns
- − Architectural Decisions
- − Team Preferences
- − Learnings & Insights
- − Next Steps
- − Open Questions
- + 📋 Project Brief
- + Project Overview
- + Core Requirements
- + Project Scope
- + Key Stakeholders
- + Success Criteria
- + Timeline
- + Constraints
- + Assumptions
- + Risks
- + Dependencies
- Notes
Commands
neither file has anySection tags
1 shared · 1 only in A · 1 only in B- − code-style
- + dependencies
- architecture
Line diff
ruvnet/rUv-dev · .clinerules/🔄_activeContext.md
@@ −1 @@
1# 🔄 Active Context
2
3## Current Focus
4The current focus is on integrating the SPARC methodology into the `.clinerules/` folder structure. This includes updating core rule files, enhancing the memory bank system, and ensuring the system supports structured development workflows through the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) approach.
5
6## Recent Changes
7- Integrated SPARC methodology principles into core rule files
8- Enhanced coding standards with SPARC-based modular development guidelines
9- Updated system patterns documentation to reflect SPARC workflow
10- Created visual workflow diagrams for SPARC methodology integration
11- Maintained the existing directory structure while enhancing content
12
13## Current Challenges
14- Ensuring emoji file names work correctly across different file systems
15- Making sure the rule management script is user-friendly and intuitive
16- Balancing comprehensiveness with simplicity in the rule files
17- Ensuring the memory bank system provides sufficient context without overwhelming users
18
19## Active Decisions
20- Using emoji prefixes for memory bank files to make them visually distinct
21- Organizing rules into logical categories (general, code-specific, testing)
22- Using a bash script for rule management rather than a more complex solution
23- Keeping core rule files separate from context-specific rules in the bank
24
25## Key Patterns & Preferences
26
27### Code Patterns
28- Markdown formatting for all rule files
29- Consistent section headings across similar rule files
30- Bullet points for individual rules within sections
31- Descriptive file names that reflect content
32
33### Architectural Decisions
34- Directory-based approach rather than a single file
35- Separation of core rules from context-specific rules
36- Memory bank system for persistent context
37- Command-line tool for rule management
38
39### Team Preferences
40- Preference for clarity and simplicity in rule descriptions
41- Focus on practical, actionable guidelines rather than abstract principles
42- Emphasis on flexibility and contextual activation
43
44## Learnings & Insights
45- The directory structure approach provides much more flexibility than a single file
46- Emoji prefixes make memory bank files more visually distinct and memorable
47- Separating rules by context allows for more focused guidance
48- The management script makes it easier to activate and deactivate rules as needed
49
50## Next Steps
511. Test the rule management script with different rule combinations
522. Expand the rule bank with additional context-specific rule sets
533. Develop integration with the Cline UI for visual rule management
544. Create rule templates for common project types
555. Implement rule versioning and change tracking
56
57## Open Questions
58- How can we best handle rule conflicts when multiple rule files are activated?
59- What's the optimal balance between comprehensive rules and keeping things simple?
60- How can we measure the effectiveness of the new approach compared to the old one?
61
62## Notes
63The current implementation focuses on the core functionality. Future enhancements will include more sophisticated rule management, integration with the Cline UI, and additional rule templates for common project types.
64
ruvnet/rUv-dev · .clinerules/📋_projectbrief.md
@@ +1 @@
1# 📋 Project Brief
2
3## Project Overview
4This project implements a modular approach to organizing rules and guidelines for Cline to follow when working with projects, incorporating the SPARC methodology for structured development. It replaces the single `.clinerules` file with a directory structure that allows for contextual activation of specific rules, easier maintenance, team flexibility, and reduced noise while providing a structured workflow for development tasks.
5
6## Core Requirements
7- Create a modular folder structure for organizing Cline rules
8- Support contextual activation of specific rules
9- Provide a memory bank system for persistent memory between sessions
10- Enable easier maintenance of rules
11- Allow team flexibility with rule activation
12- Reduce noise by keeping the active ruleset focused
13- Integrate SPARC methodology (Specification, Pseudocode, Architecture, Refinement, Completion)
14- Support modular development with clear file and function size limits
15- Ensure security through proper environment variable handling
16
17## Project Scope
18- Creation of the `.clinerules/` directory structure
19- Implementation of core rule files
20- Creation of memory bank files
21- Development of a rule management script
22- Creation of a rule bank with categorized rule sets
23
24## Key Stakeholders
25- Development team members who will use the rules
26- Project managers who need to ensure consistent guidelines
27- Cline users who will benefit from the improved context
28
29## Success Criteria
30- Rules can be selectively activated and deactivated
31- Memory bank provides persistent context between sessions
32- Rule structure is clear and well-organized
33- System is easy to maintain and extend
34
35## Timeline
36- Initial implementation: Complete
37- Rule bank expansion: Ongoing
38- Integration with Cline UI: Pending
39
40## Constraints
41- Must maintain backward compatibility with existing Cline functionality
42- Should not require significant changes to user workflows
43
44## Assumptions
45- Users are familiar with basic Cline operations
46- The system will be used primarily by development teams
47
48## Risks
49- Complexity of rule management might discourage adoption
50- Emoji file naming might cause issues in some file systems
51
52## Dependencies
53- Cline's ability to process rules from a directory structure
54- File system support for the directory structure
55
56## Notes
57The clinerules-bank directory contains additional rule sets that can be activated as needed, and the manage-rules.sh script provides a command-line interface for managing rule activation.
58
@@ −1 +1 @@
1−# 🔄 Active Context
1+# 📋 Project Brief
22
3−## Current Focus
4−The current focus is on integrating the SPARC methodology into the `.clinerules/` folder structure. This includes updating core rule files, enhancing the memory bank system, and ensuring the system supports structured development workflows through the SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) approach.
3+## Project Overview
4+This project implements a modular approach to organizing rules and guidelines for Cline to follow when working with projects, incorporating the SPARC methodology for structured development. It replaces the single `.clinerules` file with a directory structure that allows for contextual activation of specific rules, easier maintenance, team flexibility, and reduced noise while providing a structured workflow for development tasks.
55
6−## Recent Changes
7−- Integrated SPARC methodology principles into core rule files
8−- Enhanced coding standards with SPARC-based modular development guidelines
9−- Updated system patterns documentation to reflect SPARC workflow
10−- Created visual workflow diagrams for SPARC methodology integration
11−- Maintained the existing directory structure while enhancing content
6+## Core Requirements
7+- Create a modular folder structure for organizing Cline rules
8+- Support contextual activation of specific rules
9+- Provide a memory bank system for persistent memory between sessions
10+- Enable easier maintenance of rules
11+- Allow team flexibility with rule activation
12+- Reduce noise by keeping the active ruleset focused
13+- Integrate SPARC methodology (Specification, Pseudocode, Architecture, Refinement, Completion)
14+- Support modular development with clear file and function size limits
15+- Ensure security through proper environment variable handling
1216
13−## Current Challenges
14−- Ensuring emoji file names work correctly across different file systems
15−- Making sure the rule management script is user-friendly and intuitive
16−- Balancing comprehensiveness with simplicity in the rule files
17−- Ensuring the memory bank system provides sufficient context without overwhelming users
17+## Project Scope
18+- Creation of the `.clinerules/` directory structure
19+- Implementation of core rule files
20+- Creation of memory bank files
21+- Development of a rule management script
22+- Creation of a rule bank with categorized rule sets
1823
19−## Active Decisions
20−- Using emoji prefixes for memory bank files to make them visually distinct
21−- Organizing rules into logical categories (general, code-specific, testing)
22−- Using a bash script for rule management rather than a more complex solution
23−- Keeping core rule files separate from context-specific rules in the bank
24+## Key Stakeholders
25+- Development team members who will use the rules
26+- Project managers who need to ensure consistent guidelines
27+- Cline users who will benefit from the improved context
2428
25−## Key Patterns & Preferences
29+## Success Criteria
30+- Rules can be selectively activated and deactivated
31+- Memory bank provides persistent context between sessions
32+- Rule structure is clear and well-organized
33+- System is easy to maintain and extend
2634
27−### Code Patterns
28−- Markdown formatting for all rule files
29−- Consistent section headings across similar rule files
30−- Bullet points for individual rules within sections
31−- Descriptive file names that reflect content
35+## Timeline
36+- Initial implementation: Complete
37+- Rule bank expansion: Ongoing
38+- Integration with Cline UI: Pending
3239
33−### Architectural Decisions
34−- Directory-based approach rather than a single file
35−- Separation of core rules from context-specific rules
36−- Memory bank system for persistent context
37−- Command-line tool for rule management
40+## Constraints
41+- Must maintain backward compatibility with existing Cline functionality
42+- Should not require significant changes to user workflows
3843
39−### Team Preferences
40−- Preference for clarity and simplicity in rule descriptions
41−- Focus on practical, actionable guidelines rather than abstract principles
42−- Emphasis on flexibility and contextual activation
44+## Assumptions
45+- Users are familiar with basic Cline operations
46+- The system will be used primarily by development teams
4347
44−## Learnings & Insights
45−- The directory structure approach provides much more flexibility than a single file
46−- Emoji prefixes make memory bank files more visually distinct and memorable
47−- Separating rules by context allows for more focused guidance
48−- The management script makes it easier to activate and deactivate rules as needed
48+## Risks
49+- Complexity of rule management might discourage adoption
50+- Emoji file naming might cause issues in some file systems
4951
50−## Next Steps
51−1. Test the rule management script with different rule combinations
52−2. Expand the rule bank with additional context-specific rule sets
53−3. Develop integration with the Cline UI for visual rule management
54−4. Create rule templates for common project types
55−5. Implement rule versioning and change tracking
52+## Dependencies
53+- Cline's ability to process rules from a directory structure
54+- File system support for the directory structure
5655
57−## Open Questions
58−- How can we best handle rule conflicts when multiple rule files are activated?
59−- What's the optimal balance between comprehensive rules and keeping things simple?
60−- How can we measure the effectiveness of the new approach compared to the old one?
61−
6256 ## Notes
63−The current implementation focuses on the core functionality. Future enhancements will include more sophisticated rule management, integration with the Cline UI, and additional rule templates for common project types.
57+The clinerules-bank directory contains additional rule sets that can be activated as needed, and the manage-rules.sh script provides a command-line interface for managing rule activation.
6458
