forked from trent_larson/crowd-funder-for-time-pwa
6afe1c4c13
Add two new Harbor Pilot directives to improve code quality and planning: 1. Historical Comment Management: Guidelines for transforming or removing obsolete comments into actionable architectural guidance 2. No Time Estimates: Rule prohibiting time estimates in favor of phase-based planning with complexity levels and milestones Both rules are integrated into main Harbor Pilot directive for automatic application across all operations.
349 lines
12 KiB
Plaintext
349 lines
12 KiB
Plaintext
---
|
|
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.**
|