forked from jsnbuchanan/crowd-funder-for-time-pwa
refactor(cursor-rules): restructure rules architecture with meta-rule system
- Reorganize cursor rules into logical domain-based directories - Implement meta-rule system for workflow-specific rule bundling - Move core rules to dedicated /core directory - Consolidate development rules under /development namespace - Add architectural patterns and implementation examples - Create workflow-specific meta-rules for common development tasks - Remove deprecated standalone rule files - Update package dependencies for new rule structure BREAKING CHANGE: Cursor rules file structure has been reorganized Files moved from root rules directory to domain-specific subdirectories
This commit is contained in:
Matthew Raymer
165
.cursor/rules/meta_feature_planning.mdc
Normal file
165
.cursor/rules/meta_feature_planning.mdc
Normal file
@@ -0,0 +1,165 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user