You can not select more than 25 topics
			Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
		
		
		
		
		
			
		
			
				
					
					
						
							203 lines
						
					
					
						
							7.1 KiB
						
					
					
				
			
		
		
		
			
			
			
				
					
				
				
					
				
			
		
		
	
	
							203 lines
						
					
					
						
							7.1 KiB
						
					
					
				
								# Meta-Rule: Feature Planning
							 | 
						|
								
							 | 
						|
								**Author**: Matthew Raymer
							 | 
						|
								**Date**: 2025-08-21
							 | 
						|
								**Status**: 🎯 **ACTIVE** - Feature planning workflow bundling
							 | 
						|
								
							 | 
						|
								## Purpose
							 | 
						|
								
							 | 
						|
								This meta-rule bundles all the rules needed for comprehensive feature planning
							 | 
						|
								across all platforms. Use this when starting any new feature development,
							 | 
						|
								planning sprints, or estimating work effort.
							 | 
						|
								
							 | 
						|
								## Workflow Constraints
							 | 
						|
								
							 | 
						|
								**This meta-rule enforces PLANNING MODE for all bundled sub-rules:**
							 | 
						|
								
							 | 
						|
								```json
							 | 
						|
								{
							 | 
						|
								  "workflowMode": "planning",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "design_only",
							 | 
						|
								    "allowed": ["analyze", "plan", "design", "estimate", "document"],
							 | 
						|
								    "forbidden": ["implement", "code", "build", "test", "deploy"]
							 | 
						|
								  }
							 | 
						|
								}
							 | 
						|
								```
							 | 
						|
								
							 | 
						|
								**All bundled sub-rules automatically inherit these constraints.**
							 | 
						|
								
							 | 
						|
								## Workflow State Update
							 | 
						|
								
							 | 
						|
								**When this meta-rule is invoked, update the workflow state file:**
							 | 
						|
								
							 | 
						|
								```json
							 | 
						|
								{
							 | 
						|
								  "currentMode": "planning",
							 | 
						|
								  "lastInvoked": "meta_feature_planning.mdc",
							 | 
						|
								  "timestamp": "2025-01-27T15:30:00Z",
							 | 
						|
								  "constraints": {
							 | 
						|
								    "mode": "design_only",
							 | 
						|
								    "allowed": ["analyze", "plan", "design", "estimate", "document"],
							 | 
						|
								    "forbidden": ["implement", "code", "build", "test", "deploy"]
							 | 
						|
								  }
							 | 
						|
								}
							 | 
						|
								```
							 | 
						|
								
							 | 
						|
								**State File Location**: `.cursor/rules/.workflow_state.json`
							 | 
						|
								
							 | 
						|
								**This enables the core always-on rule to enforce planning mode constraints.**
							 | 
						|
								
							 | 
						|
								## When to Use
							 | 
						|
								
							 | 
						|
								- **New Feature Development**: Planning features from concept to implementation
							 | 
						|
								- **Sprint Planning**: Estimating effort and breaking down work
							 | 
						|
								- **Architecture Decisions**: Planning major architectural changes
							 | 
						|
								- **Platform Expansion**: Adding features to new platforms
							 | 
						|
								- **Refactoring Planning**: Planning significant code restructuring
							 | 
						|
								
							 | 
						|
								## Bundled Rules
							 | 
						|
								
							 | 
						|
								### **Core Planning Foundation**
							 | 
						|
								
							 | 
						|
								- **`development/planning_examples.mdc`** - Planning templates, examples, and
							 | 
						|
								  best practices for structured planning
							 | 
						|
								- **`development/realistic_time_estimation.mdc`** - Time estimation framework
							 | 
						|
								  with complexity-based phases and milestones
							 | 
						|
								- **`development/complexity_assessment.mdc`** - Technical and business
							 | 
						|
								  complexity evaluation with risk assessment
							 | 
						|
								
							 | 
						|
								### **Platform & Architecture**
							 | 
						|
								
							 | 
						|
								- **`app/timesafari_platforms.mdc`** - Platform-specific requirements,
							 | 
						|
								  constraints, and capabilities across web/mobile/desktop
							 | 
						|
								- **`app/architectural_decision_record.mdc`** - ADR process for documenting
							 | 
						|
								  major architectural decisions and trade-offs
							 | 
						|
								
							 | 
						|
								### **Development Context**
							 | 
						|
								
							 | 
						|
								- **`app/timesafari.mdc`** - Core application context, principles, and
							 | 
						|
								  development focus areas
							 | 
						|
								- **`app/timesafari_development.mdc`** - TimeSafari-specific development
							 | 
						|
								  workflow and quality standards
							 | 
						|
								
							 | 
						|
								## Workflow Sequence
							 | 
						|
								
							 | 
						|
								### **Phase 1: Foundation (Start Here)**
							 | 
						|
								
							 | 
						|
								1. **Complexity Assessment** - Use `complexity_assessment.mdc` to evaluate
							 | 
						|
								   technical and business complexity
							 | 
						|
								2. **Time Estimation** - Apply `realistic_time_estimation.mdc` framework
							 | 
						|
								   based on complexity results
							 | 
						|
								3. **Core Planning** - Use `planning_examples.mdc` for structured planning
							 | 
						|
								   approach
							 | 
						|
								
							 | 
						|
								### **Phase 2: Platform & Architecture**
							 | 
						|
								
							 | 
						|
								1. **Platform Analysis** - Review `timesafari_platforms.mdc` for
							 | 
						|
								   platform-specific requirements
							 | 
						|
								2. **Architecture Planning** - Use `architectural_decision_record.mdc` if
							 | 
						|
								   major architectural changes are needed
							 | 
						|
								
							 | 
						|
								### **Phase 3: Implementation Planning**
							 | 
						|
								
							 | 
						|
								1. **Development Workflow** - Reference `timesafari_development.mdc` for
							 | 
						|
								   development standards and testing strategy
							 | 
						|
								2. **Final Planning** - Consolidate all inputs into comprehensive plan
							 | 
						|
								
							 | 
						|
								## Success Criteria
							 | 
						|
								
							 | 
						|
								- [ ] **Complexity assessed** and documented with risk factors
							 | 
						|
								- [ ] **Time estimate created** with clear phases and milestones
							 | 
						|
								- [ ] **Platform requirements identified** for all target platforms
							 | 
						|
								- [ ] **Architecture decisions documented** (if major changes needed)
							 | 
						|
								- [ ] **Testing strategy planned** with platform-specific considerations
							 | 
						|
								- [ ] **Dependencies mapped** between tasks and phases
							 | 
						|
								- [ ] **Stakeholder input gathered** and incorporated
							 | 
						|
								
							 | 
						|
								## Common Pitfalls
							 | 
						|
								
							 | 
						|
								- **Don't skip complexity assessment** - leads to unrealistic estimates
							 | 
						|
								- **Don't estimate without platform analysis** - misses platform-specific work
							 | 
						|
								- **Don't plan without stakeholder input** - creates misaligned expectations
							 | 
						|
								- **Don't ignore testing strategy** - leads to incomplete planning
							 | 
						|
								- **Don't skip architecture decisions** - creates technical debt
							 | 
						|
								
							 | 
						|
								## Integration Points
							 | 
						|
								
							 | 
						|
								### **With Other Meta-Rules**
							 | 
						|
								
							 | 
						|
								- **Bug Diagnosis**: Use complexity assessment for bug investigation planning
							 | 
						|
								- **Feature Implementation**: This planning feeds directly into implementation
							 | 
						|
								- **Code Review**: Planning standards inform review requirements
							 | 
						|
								
							 | 
						|
								### **With Development Workflow**
							 | 
						|
								
							 | 
						|
								- Planning outputs become inputs for sprint planning
							 | 
						|
								- Complexity assessment informs testing strategy
							 | 
						|
								- Platform requirements drive architecture decisions
							 | 
						|
								
							 | 
						|
								## Feedback & Improvement
							 | 
						|
								
							 | 
						|
								### **Sub-Rule Ratings (1-5 scale)**
							 | 
						|
								
							 | 
						|
								- **Complexity Assessment**: ___/5 - Comments: _______________
							 | 
						|
								- **Time Estimation**: ___/5 - Comments: _______________
							 | 
						|
								- **Planning Examples**: ___/5 - Comments: _______________
							 | 
						|
								- **Platform Analysis**: ___/5 - Comments: _______________
							 | 
						|
								- **Architecture Decisions**: ___/5 - Comments: _______________
							 | 
						|
								
							 | 
						|
								### **Workflow Feedback**
							 | 
						|
								
							 | 
						|
								- **Sequence Effectiveness**: Did the recommended order work for you?
							 | 
						|
								- **Missing Guidance**: What additional information would have helped?
							 | 
						|
								- **Process Gaps**: Where did the workflow break down?
							 | 
						|
								
							 | 
						|
								### **Sub-Rule Improvements**
							 | 
						|
								
							 | 
						|
								- **Clarity Issues**: Which rules were unclear or confusing?
							 | 
						|
								- **Missing Examples**: What examples would make rules more useful?
							 | 
						|
								- **Integration Problems**: Do any rules conflict or overlap?
							 | 
						|
								
							 | 
						|
								### **Overall Experience**
							 | 
						|
								
							 | 
						|
								- **Time Saved**: How much time did this meta-rule save you?
							 | 
						|
								- **Quality Improvement**: Did following these rules improve your planning?
							 | 
						|
								- **Recommendation**: Would you recommend this meta-rule to others?
							 | 
						|
								
							 | 
						|
								## Model Implementation Checklist
							 | 
						|
								
							 | 
						|
								### Before Feature Planning
							 | 
						|
								
							 | 
						|
								- [ ] **Scope Definition**: Clearly define the feature scope and boundaries
							 | 
						|
								- [ ] **Stakeholder Identification**: Identify all stakeholders and decision makers
							 | 
						|
								- [ ] **Platform Requirements**: Understand target platforms and constraints
							 | 
						|
								- [ ] **Complexity Assessment**: Plan complexity evaluation approach
							 | 
						|
								
							 | 
						|
								### During Feature Planning
							 | 
						|
								
							 | 
						|
								- [ ] **Rule Application**: Apply bundled rules in recommended sequence
							 | 
						|
								- [ ] **Documentation**: Document all planning decisions and rationale
							 | 
						|
								- [ ] **Stakeholder Input**: Gather and incorporate stakeholder feedback
							 | 
						|
								- [ ] **Validation**: Validate planning against success criteria
							 | 
						|
								
							 | 
						|
								### After Feature Planning
							 | 
						|
								
							 | 
						|
								- [ ] **Plan Review**: Review plan with stakeholders and team
							 | 
						|
								- [ ] **Feedback Collection**: Collect feedback on meta-rule effectiveness
							 | 
						|
								- [ ] **Documentation Update**: Update relevant documentation
							 | 
						|
								- [ ] **Process Improvement**: Identify improvements for future planning
							 | 
						|
								
							 | 
						|
								---
							 | 
						|
								
							 | 
						|
								**See also**:
							 | 
						|
								
							 | 
						|
								- `.cursor/rules/meta_bug_diagnosis.mdc` for investigation planning
							 | 
						|
								- `.cursor/rules/meta_feature_implementation.mdc` for implementation workflow
							 | 
						|
								- `.cursor/rules/meta_bug_fixing.mdc` for fix implementation
							 | 
						|
								
							 | 
						|
								**Status**: Active meta-rule for feature planning
							 | 
						|
								**Priority**: High
							 | 
						|
								**Estimated Effort**: Ongoing reference
							 | 
						|
								**Dependencies**: All bundled sub-rules
							 | 
						|
								**Stakeholders**: Development team, Product team, Architecture team
							 | 
						|
								
							 |