Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- # Enhanced Intelligent Session Handoff Command
- You are concluding work on the current project and need to create a **comprehensive cognitive handoff** for the next AI session. This command performs deep analysis of your session to capture not just what was done, but the complete mental state, reasoning, and context needed for seamless continuation.
- ## Auto-Loaded Project Context:
- @docs/ai-context/HANDOFF.md (if exists)
- @/CLAUDE.md
- @/README.md (if exists)
- @/package.json or requirements.txt or similar (if exists)
- ## Philosophy of Perfect Handoff
- A perfect handoff enables the next session to:
- - **Resume instantly** without re-learning context
- - **Avoid repeating failed approaches** by understanding what didn't work
- - **Continue the exact train of thought** from where it stopped
- - **Make informed decisions** based on the full context of choices made
- ## Step 1: Deep Session Analysis - Evidence Collection
- Perform exhaustive analysis of the current session to identify ALL significant work and context:
- ### 1.1 File Operations Analysis
- Examine ALL file operations from this session:
- - **Files Created**: New files and their purpose in the system
- - **Files Modified**: What changed and why (not just that they changed)
- - **Files Deleted**: What was removed and the reasoning
- - **Files Read/Analyzed**: Even files examined but not modified (shows investigation paths)
- For each significant file operation, capture:
- - The specific changes made (function added, logic modified, configuration changed)
- - The reason for the change (bug fix, feature addition, refactoring, performance)
- - Any alternative approaches considered but rejected
- - Related files that might need future changes
- ### 1.2 Command Execution Analysis
- Review all bash/shell commands executed:
- - **Installation commands**: Dependencies added or removed
- - **Build/compilation commands**: What was built and results
- - **Test commands**: What was tested and outcomes
- - **Database commands**: Schema changes, queries, migrations
- - **Git operations**: Commits, branches, merges attempted
- - **Debug commands**: Inspection tools used (grep, find, logs examined)
- For each significant command, document:
- - The command itself (exact syntax for reproduction)
- - Why it was run (the problem it addressed)
- - The output/result obtained
- - Whether it succeeded or failed and why
- ### 1.3 Problem-Solving Journey
- Reconstruct the cognitive path of this session:
- - **Initial Problem Statement**: What was the starting goal or issue?
- - **Hypotheses Formed**: What did you think might be causing the issue?
- - **Approaches Attempted**: What solutions were tried in order?
- - Approach 1: [Description] โ [Outcome] โ [Why it failed/succeeded]
- - Approach 2: [Description] โ [Outcome] โ [Why it failed/succeeded]
- - Continue for all attempts...
- - **Key Insights Discovered**: "Aha!" moments that changed understanding
- - **Current Working Theory**: What you now believe is the truth about the system
- ### 1.4 Code Patterns and Conventions Observed
- Document patterns discovered in this project:
- - **Naming Conventions**: How variables, functions, files are named
- - **Architecture Patterns**: MVC, microservices, component structure used
- - **Error Handling Approach**: Try-catch patterns, error propagation style
- - **Testing Conventions**: Test file locations, naming, structure
- - **Configuration Patterns**: How config is loaded, environment variables used
- - **Import/Dependency Patterns**: How modules are imported and organized
- ### 1.5 Dependencies and Relationships Mapped
- Create a mental map of interconnections:
- - **File Dependencies**: Which files import/require which others
- - **Function Call Chains**: Key execution flows through the codebase
- - **Data Flow**: How data moves through the system
- - **Configuration Dependencies**: What config affects what behavior
- - **External Dependencies**: Third-party libraries and their roles
- ### 1.6 Testing State Snapshot
- Capture the complete testing situation:
- - **Tests That Pass**: What functionality is verified working
- - **Tests That Fail**: What's broken and error messages
- - **Tests Not Yet Written**: Functionality lacking test coverage
- - **Manual Testing Performed**: User actions tested and results
- - **Edge Cases Discovered**: Unusual scenarios found during testing
- ### 1.7 User-Provided Context Integration
- Process the user's description: "$ARGUMENTS"
- Interpret this context and integrate it with auto-detected evidence:
- - Does user context reveal intent not obvious from file changes?
- - Does it explain why certain approaches were taken?
- - Does it highlight priorities for next steps?
- - Does it mention blockers or concerns not visible in code?
- ## Step 2: Extract Decision Rationale
- For every significant decision made in this session, document:
- ### 2.1 Technical Decisions
- - **What was decided**: The specific technical choice made
- - **Alternatives considered**: Other options that were evaluated
- - **Reasoning**: Why this choice over alternatives (performance, maintainability, simplicity, standards-compliance)
- - **Trade-offs accepted**: What was sacrificed for this decision
- - **Future implications**: How this decision constrains or enables future work
- ### 2.2 Architectural Decisions
- - **Structure chosen**: How code/components are organized
- - **Rationale**: Why this structure serves the project goals
- - **Constraints respected**: Existing patterns that influenced this choice
- - **Extensibility considerations**: How future features can fit in
- ### 2.3 Priority Decisions
- - **What was prioritized**: Which work was done first and why
- - **What was deferred**: Work postponed and the reason
- - **Trade-offs**: Why some things were left incomplete
- ## Step 3: Identify Knowledge Gaps and Uncertainties
- Capture what is NOT yet known or understood:
- ### 3.1 Unresolved Questions
- - Technical questions that remain unanswered
- - Behavior that's unclear or needs verification
- - Documentation that's ambiguous or contradictory
- ### 3.2 Assumptions Made
- - What was assumed to be true (but not verified)
- - Why these assumptions were necessary
- - How to validate them later
- ### 3.3 Areas Needing Investigation
- - Code areas that haven't been fully understood
- - Dependencies whose behavior is uncertain
- - Performance characteristics that haven't been measured
- ## Step 4: Compile Failed Attempts Database
- Document what DIDN'T work (crucial to avoid repetition):
- ### 4.1 Failed Approaches
- For each approach that failed:
- - **What was tried**: Exact description of the attempt
- - **Why it seemed promising**: The logic that made it worth trying
- - **How it failed**: Specific error or incorrect behavior
- - **Root cause**: Why it didn't work (if understood)
- - **Lesson learned**: Insight gained from the failure
- ### 4.2 Dead Ends Explored
- - Investigation paths that led nowhere
- - Code sections examined that turned out to be irrelevant
- - Documentation that was misleading
- ### 4.3 Gotchas Discovered
- - Surprising behavior of libraries or frameworks
- - Subtle bugs or edge cases found
- - Configuration pitfalls encountered
- ## Step 5: Generate Actionable Next Steps
- Create ultra-specific next steps with maximal context:
- ### 5.1 Immediate Next Actions
- For each next action, provide:
- - **Clear objective**: What should be accomplished
- - **Exact steps**: Numbered procedure to follow
- 1. Open file `[exact/path/to/file.ext]`
- 2. Locate function/section `[specific identifier]`
- 3. Modify by `[precise description]`
- 4. Test by running `[exact command]`
- 5. Expected result: `[what should happen]`
- - **Required context**: What needs to be understood first
- - **Success criteria**: How to know it's complete
- - **Estimated complexity**: Time/effort expectation
- ### 5.2 Dependency Chain
- Order actions by dependencies:
- - **Prerequisites**: What must be done first
- - **Parallel work**: What can be done simultaneously
- - **Sequential requirements**: What must follow what
- ### 5.3 Validation Strategy
- - How to verify each step worked
- - Tests to run and expected outputs
- - Manual checks to perform
- ## Step 6: Analyze and Update HANDOFF.md
- Load and analyze the existing `docs/ai-context/HANDOFF.md`:
- ### 6.1 Understand Current Structure
- - Identify all existing sections and their status
- - Note any ongoing work that relates to this session
- - Observe formatting and organization patterns
- - Find any TODOs or open items
- ### 6.2 Determine Update Strategy
- **If work relates to existing section:**
- - Update progress in "What Was Accomplished"
- - Add new insights to "Key Insights and Decisions"
- - Update "Current Status" with new state
- - Modify "Failed Approaches" if new failures occurred
- - Revise "Next Steps" based on new progress
- - Update "Testing State" with new results
- **If work is new/unrelated:**
- - Create new section with current timestamp
- - Use enhanced structure (see Step 7)
- - Maintain consistency with existing document style
- **If work completed existing task:**
- - Mark task as [COMPLETED] with completion date
- - Summarize final outcome and learnings
- - Move to "Completed Work" archive section if it exists
- - Update any dependent tasks that can now proceed
- ## Step 7: Write Enhanced HANDOFF.md Structure
- Use this comprehensive structure for new sections or major updates:
- ```markdown
- ## [Descriptive Task Title] - [Status: IN_PROGRESS/BLOCKED/TESTING/COMPLETED]
- **Session Date**: [Current date and time]
- **Time Spent**: [Approximate duration of work]
- ---
- ### ๐ Current Status
- [2-3 sentence summary of where things stand right now]
- **Completion**: [X]% estimated complete
- **Confidence**: [HIGH/MEDIUM/LOW] - [Brief reason]
- ---
- ### โ What Was Accomplished
- **Major Achievements:**
- - [Achievement 1 with file path if relevant: `path/to/file.ext`]
- - [Achievement 2 with specific technical detail]
- - [Achievement 3 with measurable outcome]
- **Files Modified:**
- - `path/to/file1.ext` - [What changed and why]
- - `path/to/file2.ext` - [What changed and why]
- - `path/to/file3.ext` - [What changed and why]
- **Commands Executed:**
- ```bash
- # [Purpose of command]
- exact-command --with --flags
- # Result: [What happened]
- ```
- ---
- ### ๐ง Key Insights and Decisions
- **Technical Decisions:**
- 1. **Decision**: [What was decided]
- - **Reasoning**: [Why this approach]
- - **Alternatives Considered**: [What else was evaluated]
- - **Trade-offs**: [What was sacrificed]
- **Patterns Discovered:**
- - [Pattern 1]: [Description and where it applies]
- - [Pattern 2]: [Description and implications]
- **Critical Understanding:**
- [Important insight that changes how we think about the problem]
- ---
- ### โ Failed Approaches (DO NOT RETRY)
- **Attempt 1: [Description]**
- - **Why tried**: [The reasoning]
- - **How it failed**: [Specific error or problem]
- - **Root cause**: [Why it didn't work]
- - **Lesson**: [What we learned]
- **Attempt 2: [Description]**
- [Same structure as Attempt 1]
- ---
- ### ๐งช Testing State
- **Tests Passing:**
- - โ [Test name/description] - Verifies [what functionality]
- **Tests Failing:**
- - โ [Test name/description] - Error: [specific message]
- - Expected: [what should happen]
- - Actual: [what actually happens]
- - Investigation: [findings so far]
- **Untested Areas:**
- - [ ] [Functionality that needs testing]
- - [ ] [Edge case to verify]
- **Manual Testing Performed:**
- - Tested: [scenario] โ Result: [outcome]
- - Verified: [behavior] โ Status: [working/broken]
- ---
- ### ๐ง Current Issue / Blocker
- [Detailed description of any blocking problem]
- **Error Message:**
- ```
- [Exact error if applicable]
- ```
- **Context:**
- - When it occurs: [triggering conditions]
- - What's been tried: [debugging attempts]
- - Current theory: [hypothesis about cause]
- - Related files: [`path/to/relevant/file.ext`]
- ---
- ### ๐ฏ Next Steps to [Specific Objective]
- **Immediate Priority (Do First):**
- 1. **Action**: [Specific task]
- - **How**:
- a. [Precise step 1]
- b. [Precise step 2]
- c. [Precise step 3]
- - **File**: `exact/path/to/file.ext`
- - **Verify by**: [How to check it worked]
- - **Why**: [Reasoning for this approach]
- 2. **Action**: [Next specific task]
- [Same detailed structure]
- **Then Complete (Sequential Order):**
- 3. [Task 3 with dependencies noted]
- 4. [Task 4 with estimated complexity]
- **Future Considerations (After Above):**
- - [Longer-term improvement or refactor]
- - [Performance optimization to consider]
- - [Tech debt to address]
- ---
- ### ๐ Key Files and Their Roles
- **Primary Files:**
- - `path/to/main/file.ext` - [Core responsibility and importance]
- - `path/to/config.ext` - [Configuration role and key settings]
- **Supporting Files:**
- - `path/to/helper.ext` - [What it helps with]
- - `path/to/test.ext` - [What it tests]
- **Dependencies:**
- - `external/library` - [Why used and key APIs leveraged]
- **File Relationships:**
- ```
- main.ext
- โโ> imports helper.ext (provides [functionality])
- โโ> uses config.ext (reads [settings])
- โโ> tested by test.ext (verifies [behavior])
- ```
- ---
- ### ๐ Code Patterns to Follow
- **Naming Conventions:**
- - Functions: [pattern, e.g., camelCase, verb-noun structure]
- - Variables: [pattern, e.g., descriptive, type-hinted]
- - Files: [pattern, e.g., kebab-case, feature-based]
- **Architecture:**
- - [Pattern used, e.g., "Repository pattern for data access"]
- - [Separation principle, e.g., "Business logic in services, not controllers"]
- **Error Handling:**
- - [Project standard, e.g., "Custom exceptions extending BaseException"]
- - [Propagation style, e.g., "Catch at boundary, log, return error response"]
- ---
- ### โ ๏ธ Gotchas and Pitfalls
- **Be Aware:**
- - โ ๏ธ [Specific pitfall 1 and how to avoid it]
- - โ ๏ธ [Surprising behavior 2 that could cause confusion]
- - โ ๏ธ [Configuration detail 3 that's easy to miss]
- **Don't Do:**
- - โ [Anti-pattern observed and why it's wrong]
- - โ [Common mistake and its consequences]
- ---
- ### ๐ Context for Next Session
- **Mental State:**
- [Describe the current "flow" of work - what was the thought process, what's the momentum toward, what's the overall strategy being pursued]
- **Assumptions to Validate:**
- - [Assumption 1 that hasn't been verified]
- - [Assumption 2 that needs testing]
- **Questions to Answer:**
- - [Question 1 about the system]
- - [Question 2 about implementation]
- **When Resuming:**
- 1. Read this entire section first
- 2. Review [specific file] to refresh on [context]
- 3. Run [specific command] to see current state
- 4. Continue with Next Steps priority #1
- ---
- ### ๐ Related Work and Dependencies
- **Depends On:**
- - [Other task/section] must be [state] before this can [action]
- **Blocks:**
- - [Other task/section] is waiting on this to [milestone]
- **Related To:**
- - [Other task/section] shares [commonality]
- ---
- ### ๐ References and Resources
- **Documentation:**
- - [Library/API docs] - [Relevant section]: [URL]
- - [Internal docs] - [`path/to/doc.md`] - [What it explains]
- **External Resources:**
- - [Article/tutorial] - [Key insight]: [URL]
- - [Stack Overflow] - [Relevant answer]: [URL]
- **Code Examples:**
- - [Example 1] - [Where it is]: `path/to/example.ext`
- ```
- ---
- ## Step 8: Quality Assurance Checklist
- Before finalizing, verify the handoff meets these criteria:
- ### 8.1 Completeness Check
- - โ All significant file changes documented with reasoning
- - โ All important commands captured with context
- - โ All decisions explained with alternatives considered
- - โ All failures documented to prevent repetition
- - โ All insights and patterns recorded
- - โ Testing state fully captured
- - โ Next steps are actionable and specific
- - โ Current blockers clearly described
- - โ Code patterns and conventions noted
- ### 8.2 Clarity Check
- - โ Someone new could understand the situation immediately
- - โ Technical terms are either defined or obviously clear
- - โ File paths are exact and complete
- - โ Commands can be copy-pasted and run
- - โ Reasoning is explicit, not assumed
- - โ Status is unambiguous
- ### 8.3 Continuity Check
- - โ Builds naturally on previous work (if any)
- - โ References to past context are clear
- - โ Connection to project goals is evident
- - โ Priority and urgency are communicated
- - โ Dependencies on other work are noted
- ### 8.4 Actionability Check
- - โ Next steps could be started immediately
- - โ No information gaps that would require research
- - โ Success criteria are measurable
- - โ Validation methods are specified
- - โ Estimated complexity helps planning
- ## Step 9: Meta-Reflection
- After updating HANDOFF.md, add a brief meta-reflection:
- ```markdown
- ---
- ## ๐ญ Session Meta-Reflection
- **Overall Assessment:**
- This session [achieved X / made progress on Y / uncovered Z]. The work is [on track / ahead of schedule / facing challenges / blocked].
- **Momentum:**
- [HIGH/MEDIUM/LOW] - [Explanation of current momentum and trajectory]
- **Confidence in Direction:**
- [HIGH/MEDIUM/LOW] - [How confident we are this is the right approach]
- **Recommended Next Focus:**
- [Where the next session should concentrate effort and why]
- **Estimated Time to Completion:**
- [Realistic estimate based on current progress and complexity]
- ---
- ```
- ## Step 10: Final Output
- Present your handoff update with:
- 1. **Summary of Changes**: Brief overview of what you updated in HANDOFF.md
- 2. **Key Takeaways**: 3-5 most important points for next session
- 3. **Immediate Priority**: The single most important next action
- 4. **Confidence Assessment**: Your confidence level in the current direction
- Then show the relevant updated sections from HANDOFF.md for user review.
- ---
- ## Advanced Tips for Perfect Handoff
- **Capture the "Why" not just the "What":**
- Every action has reasoning. Document it. Future you (or next AI) needs to understand the thought process, not just the result.
- **Failed approaches are valuable:**
- Don't hide failures. They're learning opportunities and prevent wasted effort repeating the same mistakes.
- **Be specific with file paths:**
- "Updated the config file" is useless. "`config/database.json` - Changed connection pool size from 10 to 50 to handle increased load" is gold.
- **Make next steps actionable:**
- "Fix the bug" is vague. "In `src/auth/login.ts` line 45, add null check before accessing user.email because registration flow can create users without email when using OAuth" is actionable.
- **Document your mental model:**
- Explain how you understand the system working. Your mental model is what enables quick decisions. Share it.
- **Preserve context for decisions:**
- When you choose approach A over B, explain why. Future work might change the constraints, and knowing why B was rejected helps re-evaluate.
- **Note code patterns explicitly:**
- Every codebase has unwritten conventions. Write them down. It speeds up all future work.
- **Include validation steps:**
- For every change, note how to verify it worked. This enables confident progress and quick debugging.
- Now execute this enhanced handoff process, integrating user context "$ARGUMENTS" with your deep session analysis.
Advertisement
Add Comment
Please, Sign In to add comment