trent_larson/crowd-funder-for-time-pwa
4
1
Fork 2
Code Issues Pull Requests 22 Releases 5 Wiki Activity

feat(harbor-pilot): add no time estimates rule and integrate with main directive

Browse Source 
Add new Harbor Pilot rule that prohibits time estimates and instead
focuses on phases, milestones, and complexity-based planning. Integrate
the rule into main Harbor Pilot directive for automatic application.

- Replace time estimation with phase-based planning framework
- Focus on complexity categories and dependencies instead of deadlines
- Integrate rule into main Harbor Pilot system for consistency
This commit is contained in:
Matthew Raymer
2025-08-21 04:41:43 +00:00
parent 9122974fc9
commit 3eecef6d32
2 changed files with 350 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.cursor/rules/harbor_pilot_universal.mdc
View File

@@ -202,4 +202,5 @@ Follow this exact order **after** the Base Contract’s **Objective → Result
**Notes for Implementers:**
- Respect Base *Do-Not* (no filler, no invented facts, no censorship).
- Prefer clarity over completeness when timeboxed; capture unknowns explicitly.
- Apply historical comment management rules (see `.cursor/rules/historical-comment-management.mdc`)
- Apply historical comment management rules (see `.cursor/rules/historical_comment_management.mdc`)
- Apply realistic time estimation rules (see `.cursor/rules/realistic_time_estimation.mdc`)

348
.cursor/rules/realistic_time_estimation.mdc Normal file
View File

@@ -0,0 +1,348 @@
---
description: when generating text that has project task work estimates
alwaysApply: false
---
# No Time Estimates — Harbor Pilot Directive
> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases, milestones, and complexity levels. Time estimates are consistently wrong and create unrealistic expectations.
## 🎯 Purpose
Development time estimates are consistently wrong and create unrealistic expectations. This rule ensures we focus on phases, milestones, and complexity rather than trying to predict specific timeframes.
## 🚨 Critical Rule
**DO NOT MAKE TIME ESTIMATES**
- **Never provide specific time estimates** - they are always wrong
- **Use phases and milestones** instead of days/weeks
- **Focus on complexity and dependencies** rather than time
- **Set expectations based on progress, not deadlines**
## 📊 Planning Framework (Not Time Estimates)
### **Complexity Categories**
- **Simple**: Text changes, styling updates, minor bug fixes
- **Medium**: New features, refactoring, component updates
- **Complex**: Architecture changes, integrations, cross-platform work
- **Unknown**: New technologies, APIs, or approaches
### **Platform Complexity**
- **Single platform**: Web-only or mobile-only changes
- **Two platforms**: Web + mobile or web + desktop
- **Three platforms**: Web + mobile + desktop
- **Cross-platform consistency**: Ensuring behavior matches across all platforms
### **Testing Complexity**
- **Basic**: Unit tests for new functionality
- **Comprehensive**: Integration tests, cross-platform testing
- **User acceptance**: User testing, feedback integration
## 🔍 Planning Process (No Time Estimates)
### **Step 1: Break Down the Work**
- Identify all subtasks and dependencies
- Group related work into logical phases
- Identify critical path and blockers
### **Step 2: Define Phases and Milestones**
- **Phase 1**: Foundation work (basic fixes, core functionality)
- **Phase 2**: Enhancement work (new features, integrations)
- **Phase 3**: Polish work (testing, user experience, edge cases)
### **Step 3: Identify Dependencies**
- **Technical dependencies**: What must be built first
- **Platform dependencies**: What works on which platforms
- **Testing dependencies**: What can be tested when
### **Step 4: Set Progress Milestones**
- **Milestone 1**: Basic functionality working
- **Milestone 2**: All platforms supported
- **Milestone 3**: Fully tested and polished
## 📋 Planning Checklist (No Time Estimates)
- [ ] Work broken down into logical phases
- [ ] Dependencies identified and mapped
- [ ] Milestones defined with clear criteria
- [ ] Complexity levels assigned to each phase
- [ ] Platform requirements identified
- [ ] Testing strategy planned
- [ ] Risk factors identified
- [ ] Success criteria defined
## 🎯 Example Planning (No Time Estimates)
### **Example 1: Simple Feature**
```
Phase 1: Core implementation
- Basic functionality
- Single platform support
- Unit tests
Phase 2: Platform expansion
- Multi-platform support
- Integration tests
Phase 3: Polish
- User testing
- Edge case handling
```
### **Example 2: Complex Cross-Platform Feature**
```
Phase 1: Foundation
- Architecture design
- Core service implementation
- Basic web platform support
Phase 2: Platform Integration
- Mobile platform support
- Desktop platform support
- Cross-platform consistency
Phase 3: Testing & Polish
- Comprehensive testing
- Error handling
- User experience refinement
```
## 🚫 Anti-Patterns to Avoid
- **"This should take X days"** - Red flag for time estimation
- **"Just a few hours"** - Ignores complexity and testing
- **"Similar to X"** - Without considering differences
- **"Quick fix"** - Nothing is ever quick in software
- **"No testing needed"** - Testing always takes effort
## ✅ Best Practices
### **When Planning:**
1. **Break down everything** - no work is too small to plan
2. **Consider all platforms** - web, mobile, desktop differences
3. **Include testing strategy** - unit, integration, and user testing
4. **Account for unknowns** - there are always surprises
5. **Focus on dependencies** - what blocks what
### **When Presenting Plans:**
1. **Show the phases** - explain the logical progression
2. **Highlight dependencies** - what could block progress
3. **Define milestones** - clear success criteria
4. **Identify risks** - what could go wrong
5. **Suggest alternatives** - ways to reduce scope or complexity
## 🔄 Continuous Improvement
### **Track Progress**
- Record planned vs. actual phases completed
- Identify what took longer than expected
- Learn from complexity misjudgments
- Adjust planning process based on experience
### **Learn from Experience**
- **Underestimated complexity**: Increase complexity categories
- **Missed dependencies**: Improve dependency mapping
- **Platform surprises**: Better platform research upfront
## 🎯 Integration with Harbor Pilot
This rule works in conjunction with:
- **Project Planning**: Focuses on phases and milestones
- **Resource Allocation**: Based on complexity, not time
- **Risk Management**: Identifies blockers and dependencies
- **Stakeholder Communication**: Sets progress-based expectations
## 📝 Version History
### v2.0.0 (2025-08-21)
- **Major Change**: Completely removed time estimation approach
- **New Focus**: Phases, milestones, and complexity-based planning
- **Eliminated**: All time multipliers, estimates, and calculations
- **Added**: Dependency mapping and progress milestone framework
### v1.0.0 (2025-08-21)
- Initial creation based on user feedback about estimation accuracy
- ~~Established realistic estimation multipliers and process~~
- ~~Added comprehensive estimation checklist and examples~~
- Integrated with Harbor Pilot planning and risk management
---
## 🚨 Remember
**DO NOT MAKE TIME ESTIMATES. Use phases, milestones, and complexity instead. Focus on progress, not deadlines.**
## 🚨 Remember
**Your first estimate is wrong. Your second estimate is probably still wrong. Focus on progress, not deadlines.**
# No Time Estimates — Harbor Pilot Directive
> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases, milestones, and complexity levels. Time estimates are consistently wrong and create unrealistic expectations.
## 🎯 Purpose
Development time estimates are consistently wrong and create unrealistic expectations. This rule ensures we focus on phases, milestones, and complexity rather than trying to predict specific timeframes.
## 🚨 Critical Rule
**DO NOT MAKE TIME ESTIMATES**
- **Never provide specific time estimates** - they are always wrong
- **Use phases and milestones** instead of days/weeks
- **Focus on complexity and dependencies** rather than time
- **Set expectations based on progress, not deadlines**
## 📊 Planning Framework (Not Time Estimates)
### **Complexity Categories**
- **Simple**: Text changes, styling updates, minor bug fixes
- **Medium**: New features, refactoring, component updates
- **Complex**: Architecture changes, integrations, cross-platform work
- **Unknown**: New technologies, APIs, or approaches
### **Platform Complexity**
- **Single platform**: Web-only or mobile-only changes
- **Two platforms**: Web + mobile or web + desktop
- **Three platforms**: Web + mobile + desktop
- **Cross-platform consistency**: Ensuring behavior matches across all platforms
### **Testing Complexity**
- **Basic**: Unit tests for new functionality
- **Comprehensive**: Integration tests, cross-platform testing
- **User acceptance**: User testing, feedback integration
## 🔍 Planning Process (No Time Estimates)
### **Step 1: Break Down the Work**
- Identify all subtasks and dependencies
- Group related work into logical phases
- Identify critical path and blockers
### **Step 2: Define Phases and Milestones**
- **Phase 1**: Foundation work (basic fixes, core functionality)
- **Phase 2**: Enhancement work (new features, integrations)
- **Phase 3**: Polish work (testing, user experience, edge cases)
### **Step 3: Identify Dependencies**
- **Technical dependencies**: What must be built first
- **Platform dependencies**: What works on which platforms
- **Testing dependencies**: What can be tested when
### **Step 4: Set Progress Milestones**
- **Milestone 1**: Basic functionality working
- **Milestone 2**: All platforms supported
- **Milestone 3**: Fully tested and polished
## 📋 Planning Checklist (No Time Estimates)
- [ ] Work broken down into logical phases
- [ ] Dependencies identified and mapped
- [ ] Milestones defined with clear criteria
- [ ] Complexity levels assigned to each phase
- [ ] Platform requirements identified
- [ ] Testing strategy planned
- [ ] Risk factors identified
- [ ] Success criteria defined
## 🎯 Example Planning (No Time Estimates)
### **Example 1: Simple Feature**
```
Phase 1: Core implementation
- Basic functionality
- Single platform support
- Unit tests
Phase 2: Platform expansion
- Multi-platform support
- Integration tests
Phase 3: Polish
- User testing
- Edge case handling
```
### **Example 2: Complex Cross-Platform Feature**
```
Phase 1: Foundation
- Architecture design
- Core service implementation
- Basic web platform support
Phase 2: Platform Integration
- Mobile platform support
- Desktop platform support
- Cross-platform consistency
Phase 3: Testing & Polish
- Comprehensive testing
- Error handling
- User experience refinement
```
## 🚫 Anti-Patterns to Avoid
- **"This should take X days"** - Red flag for time estimation
- **"Just a few hours"** - Ignores complexity and testing
- **"Similar to X"** - Without considering differences
- **"Quick fix"** - Nothing is ever quick in software
- **"No testing needed"** - Testing always takes effort
## ✅ Best Practices
### **When Planning:**
1. **Break down everything** - no work is too small to plan
2. **Consider all platforms** - web, mobile, desktop differences
3. **Include testing strategy** - unit, integration, and user testing
4. **Account for unknowns** - there are always surprises
5. **Focus on dependencies** - what blocks what
### **When Presenting Plans:**
1. **Show the phases** - explain the logical progression
2. **Highlight dependencies** - what could block progress
3. **Define milestones** - clear success criteria
4. **Identify risks** - what could go wrong
5. **Suggest alternatives** - ways to reduce scope or complexity
## 🔄 Continuous Improvement
### **Track Progress**
- Record planned vs. actual phases completed
- Identify what took longer than expected
- Learn from complexity misjudgments
- Adjust planning process based on experience
### **Learn from Experience**
- **Underestimated complexity**: Increase complexity categories
- **Missed dependencies**: Improve dependency mapping
- **Platform surprises**: Better platform research upfront
## 🎯 Integration with Harbor Pilot
This rule works in conjunction with:
- **Project Planning**: Focuses on phases and milestones
- **Resource Allocation**: Based on complexity, not time
- **Risk Management**: Identifies blockers and dependencies
- **Stakeholder Communication**: Sets progress-based expectations
## 📝 Version History
### v2.0.0 (2025-08-21)
- **Major Change**: Completely removed time estimation approach
- **New Focus**: Phases, milestones, and complexity-based planning
- **Eliminated**: All time multipliers, estimates, and calculations
- **Added**: Dependency mapping and progress milestone framework
### v1.0.0 (2025-08-21)
- Initial creation based on user feedback about estimation accuracy
- ~~Established realistic estimation multipliers and process~~
- ~~Added comprehensive estimation checklist and examples~~
- Integrated with Harbor Pilot planning and risk management
---
## 🚨 Remember
**DO NOT MAKE TIME ESTIMATES. Use phases, milestones, and complexity instead. Focus on progress, not deadlines.**
## 🚨 Remember
**Your first estimate is wrong. Your second estimate is probably still wrong. Focus on progress, not deadlines.**