- Remove legacy rule files (documentation.mdc, general_development.mdc, etc.) - Implement new meta-rule system with core, app, and feature categories - Add meta-rule files for different workflows (bug diagnosis, feature planning, etc.) - Create organized directory structure: core/, app/, features/, database/, etc. - Add comprehensive README.md for rules documentation - Establish new rule architecture with always-on and workflow-specific rules This restructuring improves rule organization, enables better workflow management, and provides clearer separation of concerns for different development tasks.
204 lines
7.1 KiB
Plaintext
204 lines
7.1 KiB
Plaintext
# 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
|