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
 | |
| 
 |