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

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