--- alwaysApply: true --- # Software Development Ruleset ## Purpose Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing. ## Core Principles ### 1. Evidence-First Development - **Code Citations Required**: Always cite specific file:line references when making claims - **Execution Path Tracing**: Trace actual code execution before proposing architectural changes - **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based" ### 2. Code Review Standards - **Trace Before Proposing**: Always trace execution paths before suggesting changes - **Evidence Over Inference**: Prefer code citations over logical deductions - **Scope Validation**: Confirm the actual scope of problems before proposing solutions ### 3. Problem-Solution Validation - **Problem Scope**: Does the solution address the actual problem? - **Evidence Alignment**: Does the solution match the evidence? - **Complexity Justification**: Is added complexity justified by real needs? - **Alternative Analysis**: What simpler solutions were considered? ## Required Workflows ### Before Proposing Changes - [ ] **Code Path Tracing**: Map execution flow from entry to exit - [ ] **Evidence Collection**: Gather specific code citations and logs - [ ] **Assumption Surfacing**: Identify what's proven vs. inferred - [ ] **Scope Validation**: Confirm the actual extent of the problem ### During Solution Design - [ ] **Evidence Alignment**: Ensure solution addresses proven problems - [ ] **Complexity Assessment**: Justify any added complexity - [ ] **Alternative Evaluation**: Consider simpler approaches first - [ ] **Impact Analysis**: Assess effects on existing systems ## Software-Specific Competence Hooks ### Evidence Validation - **"What code path proves this claim?"** - **"How does data actually flow through the system?"** - **"What am I assuming vs. what can I prove?"** ### Code Tracing - **"What's the execution path from user action to system response?"** - **"Which components actually interact in this scenario?"** - **"Where does the data originate and where does it end up?"** ### Architecture Decisions - **"What evidence shows this change is necessary?"** - **"What simpler solution could achieve the same goal?"** - **"How does this change affect the existing system architecture?"** ## Integration with Other Rulesets ### With base_context.mdc - Inherits generic competence principles - Adds software-specific evidence requirements - Maintains collaboration and learning focus ### With research_diagnostic.mdc - Enhances investigation with code path tracing - Adds evidence validation to diagnostic workflow - Strengthens problem identification accuracy ## Usage Guidelines ### When to Use This Ruleset - Code reviews and architectural decisions - Bug investigation and debugging - Performance optimization - Feature implementation planning - Testing strategy development ### When to Combine with Others - **base_context + software_development**: General development tasks - **research_diagnostic + software_development**: Technical investigations - **All three**: Complex architectural decisions or major refactoring ## Self-Check (model, before responding) - [ ] Code path traced and documented - [ ] Evidence cited with specific file:line references - [ ] Assumptions clearly flagged as proven vs. inferred - [ ] Solution complexity justified by evidence - [ ] Simpler alternatives considered and documented - [ ] Impact on existing systems assessed # Software Development Ruleset ## Purpose Specialized guidelines for software development tasks including code review, debugging, architecture decisions, and testing. ## Core Principles ### 1. Evidence-First Development - **Code Citations Required**: Always cite specific file:line references when making claims - **Execution Path Tracing**: Trace actual code execution before proposing architectural changes - **Assumption Validation**: Flag assumptions as "assumed" vs "evidence-based" ### 2. Code Review Standards - **Trace Before Proposing**: Always trace execution paths before suggesting changes - **Evidence Over Inference**: Prefer code citations over logical deductions - **Scope Validation**: Confirm the actual scope of problems before proposing solutions ### 3. Problem-Solution Validation - **Problem Scope**: Does the solution address the actual problem? - **Evidence Alignment**: Does the solution match the evidence? - **Complexity Justification**: Is added complexity justified by real needs? - **Alternative Analysis**: What simpler solutions were considered? ## Required Workflows ### Before Proposing Changes - [ ] **Code Path Tracing**: Map execution flow from entry to exit - [ ] **Evidence Collection**: Gather specific code citations and logs - [ ] **Assumption Surfacing**: Identify what's proven vs. inferred - [ ] **Scope Validation**: Confirm the actual extent of the problem ### During Solution Design - [ ] **Evidence Alignment**: Ensure solution addresses proven problems - [ ] **Complexity Assessment**: Justify any added complexity - [ ] **Alternative Evaluation**: Consider simpler approaches first - [ ] **Impact Analysis**: Assess effects on existing systems ## Software-Specific Competence Hooks ### Evidence Validation - **"What code path proves this claim?"** - **"How does data actually flow through the system?"** - **"What am I assuming vs. what can I prove?"** ### Code Tracing - **"What's the execution path from user action to system response?"** - **"Which components actually interact in this scenario?"** - **"Where does the data originate and where does it end up?"** ### Architecture Decisions - **"What evidence shows this change is necessary?"** - **"What simpler solution could achieve the same goal?"** - **"How does this change affect the existing system architecture?"** ## Integration with Other Rulesets ### With base_context.mdc - Inherits generic competence principles - Adds software-specific evidence requirements - Maintains collaboration and learning focus ### With research_diagnostic.mdc - Enhances investigation with code path tracing - Adds evidence validation to diagnostic workflow - Strengthens problem identification accuracy ## Usage Guidelines ### When to Use This Ruleset - Code reviews and architectural decisions - Bug investigation and debugging - Performance optimization - Feature implementation planning - Testing strategy development ### When to Combine with Others - **base_context + software_development**: General development tasks - **research_diagnostic + software_development**: Technical investigations - **All three**: Complex architectural decisions or major refactoring ## Self-Check (model, before responding) - [ ] Code path traced and documented - [ ] Evidence cited with specific file:line references - [ ] Assumptions clearly flagged as proven vs. inferred - [ ] Solution complexity justified by evidence - [ ] Simpler alternatives considered and documented - [ ] Impact on existing systems assessed