continue.md
1 --- 2 allowed-tools: Bash(git:status), Bash(git:branch), Bash(git:log), Bash(git:show), Bash(git:diff), Bash(git:ls-files), Bash(gh:issue:list), Bash(gh:issue:view), Bash(gh:repo:view), Bash(gh:pr:list), Bash(gh:pr:view), Bash(gh:auth:status), Bash(lsof), Bash(find), Bash(npm:run:test), Read, Write, MultiEdit, Edit, TodoWrite, LS, Glob, Grep 3 description: Intelligent session continuation with plan-mode preparation workflow - analyze state, conduct knowledge transfer, create branches, then plan implementation 4 --- 5 6 # Continue Development Workflow 7 8 **Core Philosophy**: This command handles meta-preparation work (state analysis, issue analysis, knowledge transfer, branch creation) before jumping into coding. Focus on thorough preparation and knowledge transfer - user will manually enter plan mode when ready for implementation planning. 9 10 ## STEP 1: Check Open Issues & Determine Options 11 12 ### Issue Status Check 13 - **My assigned issues**: !`gh issue list --assignee @me --state open` 14 - **Current epic progress**: !`gh issue list --label epic --state open` 15 - **Active specifications**: !`gh issue list --label specification --state open` 16 - **Ready features**: !`gh issue list --label feature --state open` 17 18 ### Decision Point: Multiple Options Available? 19 20 **IF MULTIPLE WORK OPTIONS EXIST:** 21 1. **STOP detailed analysis** - Don't proceed with full context gathering yet 22 2. **Present concise overview** of available work options: 23 - Epic continuation vs new epic 24 - Specification refinement vs feature implementation 25 - Different feature options within current epic 26 - Bug fixes vs new development 27 3. **Ask user to choose**: "I see multiple development paths available. Here are the options: [BRIEF_OVERVIEW]. Which would you like to focus on?" 28 4. **Wait for user choice** before proceeding to detailed analysis 29 30 **IF ONLY ONE CLEAR PATH:** 31 - Note the single clear direction 32 - Proceed directly to detailed context analysis below 33 34 ## Context Analysis & State Detection 35 36 **Only proceed here AFTER determining work direction above** 37 38 ### Project State Gathering 39 - **Current branch**: !`git branch --show-current` 40 - **Git status**: !`git status --short` 41 - **Recent commits**: !`git log --oneline -5` 42 43 ### Memory Context 44 - **Project memory**: @CLAUDE.md 45 - **User workflow patterns**: @~/.claude/CLAUDE.md 46 - **Local setup**: @CLAUDE.local.md 47 48 ### Development Context 49 - **Current codebase state**: !`find src/ -name "*.ts" -o -name "*.tsx" | head -10` 50 - **Package.json status**: @package.json 51 - **Recent test results**: !`npm run test 2>/dev/null | tail -5 || echo "Tests not run recently"` 52 53 ## CRITICAL PHASE 1: Feature Issue Analysis & Knowledge Transfer 54 55 **⚠️ MANDATORY FIRST STEPS - NEVER SKIP THIS PHASE ⚠️** 56 57 ### 1. Read Current Feature Issue 58 - Use `gh issue view ISSUE_NUMBER` to read the current feature issue body 59 - Understand existing requirements and acceptance criteria 60 - Note any gaps or areas needing clarification 61 62 ### 2. Knowledge Transfer Interview Process 63 **Present the feature issue summary and ask potent questions:** 64 - "Based on the current issue body for [FEATURE], here's what I understand: [SUMMARY]. What specific implementation details have you already thought about?" 65 - "What are the key interaction patterns you envision for this feature?" 66 - "Are there performance requirements or constraints I should consider?" 67 - "What edge cases or potential issues should we handle?" 68 - "How should this integrate with our existing [RELEVANT_FEATURES]?" 69 - "What aspects of this feature are most important to get right?" 70 71 ### 3. Clarification Discussion 72 - Have a short conversation to align understanding 73 - Let user articulate their vision and requirements 74 - Capture any additional insights or constraints 75 76 ### 4. Issue Body Refinement 77 - Based on the discussion, update the GitHub issue with: 78 - Detailed implementation plan 79 - Specific technical approach 80 - Enhanced acceptance criteria 81 - Edge cases and constraints 82 - Integration points 83 84 ### 5. Get Explicit Approval 85 - Present the refined issue plan: "Here's the updated implementation plan based on our discussion: [PLAN]. Does this capture what you want?" 86 - Only proceed to implementation after user confirms 87 88 ## Technical Context Analysis 89 90 **Only proceed here AFTER completing Phase 1 above** 91 92 Based on the knowledge transfer insights AND gathered context, determine: 93 94 ### 1. **Epic Position** 95 - Which epic are we in? (Epic 1: Complete, Epic 2: Active, Epic 3+: Future) 96 - Is the epic branch created and current? 97 - Are we mid-feature or between features? 98 99 ### 2. **Specification Status** 100 - Is the current epic specification clear and detailed? 101 - Do we need to flesh out the spec before proceeding? 102 - Are feature requirements well-defined? 103 104 ### 3. **Feature Pipeline** 105 - What's the next logical feature to implement? 106 - Is there an active feature branch or do we need to create one? 107 - Are there completed features awaiting integration? 108 109 ### 4. **Technical Readiness** 110 - Are there uncommitted changes that need attention? 111 - Is the build system working (tests passing, lint clean)? 112 - Are dependencies up to date? 113 114 ## Development Continuation Strategy 115 116 ### Phase 1: State Reconciliation 117 If uncommitted changes exist: 118 1. **Analyze changes**: Determine if they're complete, partial, or experimental 119 2. **Commit or stash**: Follow git commit philosophy from user memory 120 3. **Clean workspace**: Ensure clean state for next feature 121 122 ### Phase 2: Epic/Specification Clarity 123 Following the **DEEP PATTERN - ALWAYS FOLLOW** from project memory: 124 125 1. **Epic Branch Verification**: Ensure we're on correct epic branch 126 2. **Specification Review**: 127 - If spec is rough → flesh out through conversational clarity 128 - If spec is clear → proceed to feature selection 129 - Update specification issue body with detailed implementation plan 130 131 ### Phase 3: Feature Selection & Planning 132 Based on current epic and specification: 133 134 1. **Identify Next Feature**: 135 - From epic's feature list in GitHub issues 136 - Consider dependencies and logical implementation order 137 - **STOP HERE** - Do not proceed without feature issue analysis 138 139 2. **Return to Phase 1**: 140 - **MANDATORY**: Go back to "CRITICAL PHASE 1" above 141 - Complete full feature issue analysis and knowledge transfer 142 - Only continue after user approval of refined issue 143 144 3. **Feature Branch Strategy** (After Phase 1 Complete): 145 - Create feature branch off epic branch 146 - Follow naming: `feature/feature-name-from-issue` 147 - Branch creation happens during preparation 148 149 ### Phase 4: Preparation Complete 150 After completing preparation phases (state analysis, knowledge transfer, issue refinement, branch creation): 151 152 1. **Summarize Current State**: Brief summary of what's been prepared 153 2. **Next Steps Identified**: Clear understanding of implementation direction 154 3. **Ready for Planning**: User will manually enter plan mode when ready for detailed implementation planning 155 156 --- 157 158 ## IMPLEMENTATION EXECUTION (Post Plan-Mode) 159 160 ### Phase 5: Execute Development 161 Begin systematic implementation following AI-first development patterns: 162 163 1. **Development Environment Check**: 164 - Verify dev server is running: !`lsof -i :5173 || echo "Dev server not running"` 165 - If not running: **PROMPT USER** to start dev server (`npm run dev`) - DO NOT start automatically 166 - Confirm Obsidian development vault is ready for testing 167 168 2. **Implementation Cycle**: 169 - **Commands Before UI**: Create command palette commands first 170 - **Service Layer**: Implement business logic in services 171 - **Feature Slice**: Build UI components in feature folder 172 - **Unit Testing**: Write tests as implementation progresses 173 174 3. **Manual Testing Integration**: 175 - Test functionality directly in Obsidian development vault 176 - Use Plugin Reloader hotkey to refresh plugin after changes 177 - Verify features work as expected through direct interaction 178 - Check Obsidian developer console for errors 179 180 4. **Validation & Debugging**: 181 - Test feature manually in development environment 182 - Debug any issues through console logs and direct testing 183 - Iterate implementation until manual testing confirms functionality 184 - Ensure no console errors or broken functionality 185 186 5. **Documentation**: Update docs with new functionality only after testing confirms it works 187 188 ## Execution Protocol 189 190 ### Workflow Checkpoints 191 - [ ] State analysis complete and documented 192 - [ ] Epic/spec clarity confirmed or achieved 193 - [ ] Feature selected and branch created 194 - [ ] Feature issue detailed with acceptance criteria 195 - [ ] TodoWrite implementation plan created 196 - [ ] Development rules and patterns ready to follow 197 198 ### Quality Gates 199 - [ ] Follow Commands → Services → UI pattern 200 - [ ] Maintain Vertical Slice Architecture 201 - [ ] Update TodoWrite progress throughout 202 - [ ] Commit frequently with granular history 203 - [ ] Test implementation as development progresses 204 205 ### Success Criteria 206 - [ ] Feature implementation follows project architecture 207 - [ ] All acceptance criteria met and tested manually in Obsidian 208 - [ ] Manual testing confirms functionality works without errors 209 - [ ] Console logs clean (no errors or warnings) 210 - [ ] Feature validated through direct interaction 211 - [ ] Documentation updated for new functionality 212 - [ ] Feature ready for epic integration 213 - [ ] Clear next steps identified 214 215 ## CRITICAL USER TESTING PHASE 216 217 **⚠️ MANDATORY BEFORE ANY COMMITS ⚠️** 218 219 ### Stop for User Testing 220 1. **Complete implementation and local testing** 221 2. **STOP and request user testing**: "The feature implementation is complete. Please test the following functionality and provide feedback:" 222 - List specific features to test 223 - Mention any special interactions or edge cases 224 - Ask user to check for any issues or unexpected behavior 225 3. **Wait for user feedback** - DO NOT PROCEED WITHOUT IT 226 4. **Iterate based on feedback** - Fix any issues found 227 5. **Re-test with user** until they confirm it works correctly 228 6. **Only then proceed to commit** 229 230 ### Commit & GitHub Operations Protocol 231 **CRITICAL**: Only proceed with git commits and GitHub operations AFTER: 232 - [ ] Manual testing in Obsidian confirms feature works 233 - [ ] All console errors resolved 234 - [ ] Feature validated through direct interaction 235 - [ ] No broken agentic loop (dev server remains running) 236 237 **Git Workflow**: 238 1. Test feature thoroughly in Obsidian development vault 239 2. Fix any issues found during testing 240 3. Re-test until everything works cleanly 241 4. **STOP FOR USER TESTING** - Get explicit confirmation feature works 242 5. THEN commit with comprehensive summary 243 6. Merge feature branch to epic branch 244 7. Update GitHub issue body with completed checkboxes 245 8. **ONLY close issue after successful merge** - NEVER before 246 247 ## AI Behavior Integration 248 249 This command embodies the **Conversational Flow: Music Leads, Instrument Amplifies** pattern: 250 - Analyze the pure signal of current project state 251 - Amplify development direction based on established patterns 252 - Trust the workflow patterns encoded in memory 253 - Maintain **Music Contains Instrument** - technical solutions emerge from tuning into the vision 254 255 Execute this workflow systematically, honoring both the technical development patterns and the philosophical framework of effortless flow and coherent emergence.