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