| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 13 | 7 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 1 | 1 | 2 | 25% |
What each file covers
Sections
0 shared · 13 only in A · 7 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
- − Notes
- + 📖 Cline Rules
- + Structure
- + SPARC Methodology
- + Usage
- + Benefits of the Folder Approach
- + Managing Rules with the Toggleable Popover
- + Memory Bank
Commands
neither file has anySection tags
1 shared · 1 only in A · 2 only in B- − code-style
- + performance
- + do-not
- 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/📖_README.md
@@ +1 @@
1# 📖 Cline Rules
2
3This directory contains rules and guidelines for Cline to follow when working with this project, incorporating the SPARC methodology for structured development.
4
5## Structure
6
7- `rules/` - Contains general guidelines and rules for Cline
8- `rules-code/` - Contains code-specific guidelines and rules
9- `tests/` - Contains testing guidelines and rules
10
11## SPARC Methodology
12
13The SPARC methodology provides a structured workflow for development:
14
151. **Specification** - Define goals, scope, constraints, and acceptance criteria
162. **Pseudocode** - Develop high-level logic with TDD anchors
173. **Architecture** - Design modular components with clear interfaces
184. **Refinement** - Implement with TDD, debugging, and optimization
195. **Completion** - Integrate, document, test, and verify against criteria
20
21## Usage
22
23Cline automatically processes all Markdown files inside the `.clinerules/` directory, combining them into a unified set of rules. The numeric prefixes (optional) help organize files in a logical sequence.
24
25## Benefits of the Folder Approach
26
27- **Contextual Activation**: Copy only relevant rules from the bank to the active folder
28- **Easier Maintenance**: Update individual rule files without affecting others
29- **Team Flexibility**: Different team members can activate rules specific to their current task
30- **Reduced Noise**: Keep the active ruleset focused and relevant
31
32## Managing Rules with the Toggleable Popover
33
34Located under the chat input field, the popover UI allows you to:
35
36- Instantly See Active Rules: View which global rules and workspace rules are currently active
37- Quickly Toggle Rules: Enable or disable specific rule files within your workspace
38- Easily Add/Manage Rules: Create a workspace `.clinerules` file or folder if one doesn't exist
39
40## Memory Bank
41
42The Memory Bank files (prefixed with emojis) provide Cline with persistent memory between sessions:
43
44- 📋 `_projectbrief.md` - Foundation document defining core requirements and goals
45- 🔍 `_productContext.md` - Why this project exists and how it should work
46- 🔄 `_activeContext.md` - Current work focus, recent changes, and next steps
47- 🏗️ `_systemPatterns.md` - System architecture and key technical decisions
48- ⚙️ `_techContext.md` - Technologies used and development setup
49- 📊 `_progress.md` - Project status, completed features, and known issues
50- 🧠 `_memory-bank.md` - Core documentation about the Memory Bank system itself
51
@@ −1 +1 @@
1−# 🔄 Active Context
1+# 📖 Cline Rules
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+This directory contains rules and guidelines for Cline to follow when working with this project, incorporating the SPARC methodology for structured development.
54
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
5+## Structure
126
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
7+- `rules/` - Contains general guidelines and rules for Cline
8+- `rules-code/` - Contains code-specific guidelines and rules
9+- `tests/` - Contains testing guidelines and rules
1810
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
11+## SPARC Methodology
2412
25−## Key Patterns & Preferences
13+The SPARC methodology provides a structured workflow for development:
2614
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
15+1. **Specification** - Define goals, scope, constraints, and acceptance criteria
16+2. **Pseudocode** - Develop high-level logic with TDD anchors
17+3. **Architecture** - Design modular components with clear interfaces
18+4. **Refinement** - Implement with TDD, debugging, and optimization
19+5. **Completion** - Integrate, document, test, and verify against criteria
3220
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
21+## Usage
3822
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
23+Cline automatically processes all Markdown files inside the `.clinerules/` directory, combining them into a unified set of rules. The numeric prefixes (optional) help organize files in a logical sequence.
4324
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
25+## Benefits of the Folder Approach
4926
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
27+- **Contextual Activation**: Copy only relevant rules from the bank to the active folder
28+- **Easier Maintenance**: Update individual rule files without affecting others
29+- **Team Flexibility**: Different team members can activate rules specific to their current task
30+- **Reduced Noise**: Keep the active ruleset focused and relevant
5631
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?
32+## Managing Rules with the Toggleable Popover
6133
62−## 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.
34+Located under the chat input field, the popover UI allows you to:
35+
36+- Instantly See Active Rules: View which global rules and workspace rules are currently active
37+- Quickly Toggle Rules: Enable or disable specific rule files within your workspace
38+- Easily Add/Manage Rules: Create a workspace `.clinerules` file or folder if one doesn't exist
39+
40+## Memory Bank
41+
42+The Memory Bank files (prefixed with emojis) provide Cline with persistent memory between sessions:
43+
44+- 📋 `_projectbrief.md` - Foundation document defining core requirements and goals
45+- 🔍 `_productContext.md` - Why this project exists and how it should work
46+- 🔄 `_activeContext.md` - Current work focus, recent changes, and next steps
47+- 🏗️ `_systemPatterns.md` - System architecture and key technical decisions
48+- ⚙️ `_techContext.md` - Technologies used and development setup
49+- 📊 `_progress.md` - Project status, completed features, and known issues
50+- 🧠 `_memory-bank.md` - Core documentation about the Memory Bank system itself
6451
