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