Guest User

Untitled

a guest
Oct 30th, 2025
1,149
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 18.97 KB | None | 0 0
  1. # Enhanced Intelligent Session Handoff Command
  2.  
  3. 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.
  4.  
  5. ## Auto-Loaded Project Context:
  6. @docs/ai-context/HANDOFF.md (if exists)
  7. @/CLAUDE.md
  8. @/README.md (if exists)
  9. @/package.json or requirements.txt or similar (if exists)
  10.  
  11. ## Philosophy of Perfect Handoff
  12.  
  13. A perfect handoff enables the next session to:
  14. - **Resume instantly** without re-learning context
  15. - **Avoid repeating failed approaches** by understanding what didn't work
  16. - **Continue the exact train of thought** from where it stopped
  17. - **Make informed decisions** based on the full context of choices made
  18.  
  19. ## Step 1: Deep Session Analysis - Evidence Collection
  20.  
  21. Perform exhaustive analysis of the current session to identify ALL significant work and context:
  22.  
  23. ### 1.1 File Operations Analysis
  24. Examine ALL file operations from this session:
  25. - **Files Created**: New files and their purpose in the system
  26. - **Files Modified**: What changed and why (not just that they changed)
  27. - **Files Deleted**: What was removed and the reasoning
  28. - **Files Read/Analyzed**: Even files examined but not modified (shows investigation paths)
  29.  
  30. For each significant file operation, capture:
  31. - The specific changes made (function added, logic modified, configuration changed)
  32. - The reason for the change (bug fix, feature addition, refactoring, performance)
  33. - Any alternative approaches considered but rejected
  34. - Related files that might need future changes
  35.  
  36. ### 1.2 Command Execution Analysis
  37. Review all bash/shell commands executed:
  38. - **Installation commands**: Dependencies added or removed
  39. - **Build/compilation commands**: What was built and results
  40. - **Test commands**: What was tested and outcomes
  41. - **Database commands**: Schema changes, queries, migrations
  42. - **Git operations**: Commits, branches, merges attempted
  43. - **Debug commands**: Inspection tools used (grep, find, logs examined)
  44.  
  45. For each significant command, document:
  46. - The command itself (exact syntax for reproduction)
  47. - Why it was run (the problem it addressed)
  48. - The output/result obtained
  49. - Whether it succeeded or failed and why
  50.  
  51. ### 1.3 Problem-Solving Journey
  52. Reconstruct the cognitive path of this session:
  53. - **Initial Problem Statement**: What was the starting goal or issue?
  54. - **Hypotheses Formed**: What did you think might be causing the issue?
  55. - **Approaches Attempted**: What solutions were tried in order?
  56. - Approach 1: [Description] โ†’ [Outcome] โ†’ [Why it failed/succeeded]
  57. - Approach 2: [Description] โ†’ [Outcome] โ†’ [Why it failed/succeeded]
  58. - Continue for all attempts...
  59. - **Key Insights Discovered**: "Aha!" moments that changed understanding
  60. - **Current Working Theory**: What you now believe is the truth about the system
  61.  
  62. ### 1.4 Code Patterns and Conventions Observed
  63. Document patterns discovered in this project:
  64. - **Naming Conventions**: How variables, functions, files are named
  65. - **Architecture Patterns**: MVC, microservices, component structure used
  66. - **Error Handling Approach**: Try-catch patterns, error propagation style
  67. - **Testing Conventions**: Test file locations, naming, structure
  68. - **Configuration Patterns**: How config is loaded, environment variables used
  69. - **Import/Dependency Patterns**: How modules are imported and organized
  70.  
  71. ### 1.5 Dependencies and Relationships Mapped
  72. Create a mental map of interconnections:
  73. - **File Dependencies**: Which files import/require which others
  74. - **Function Call Chains**: Key execution flows through the codebase
  75. - **Data Flow**: How data moves through the system
  76. - **Configuration Dependencies**: What config affects what behavior
  77. - **External Dependencies**: Third-party libraries and their roles
  78.  
  79. ### 1.6 Testing State Snapshot
  80. Capture the complete testing situation:
  81. - **Tests That Pass**: What functionality is verified working
  82. - **Tests That Fail**: What's broken and error messages
  83. - **Tests Not Yet Written**: Functionality lacking test coverage
  84. - **Manual Testing Performed**: User actions tested and results
  85. - **Edge Cases Discovered**: Unusual scenarios found during testing
  86.  
  87. ### 1.7 User-Provided Context Integration
  88. Process the user's description: "$ARGUMENTS"
  89.  
  90. Interpret this context and integrate it with auto-detected evidence:
  91. - Does user context reveal intent not obvious from file changes?
  92. - Does it explain why certain approaches were taken?
  93. - Does it highlight priorities for next steps?
  94. - Does it mention blockers or concerns not visible in code?
  95.  
  96. ## Step 2: Extract Decision Rationale
  97.  
  98. For every significant decision made in this session, document:
  99.  
  100. ### 2.1 Technical Decisions
  101. - **What was decided**: The specific technical choice made
  102. - **Alternatives considered**: Other options that were evaluated
  103. - **Reasoning**: Why this choice over alternatives (performance, maintainability, simplicity, standards-compliance)
  104. - **Trade-offs accepted**: What was sacrificed for this decision
  105. - **Future implications**: How this decision constrains or enables future work
  106.  
  107. ### 2.2 Architectural Decisions
  108. - **Structure chosen**: How code/components are organized
  109. - **Rationale**: Why this structure serves the project goals
  110. - **Constraints respected**: Existing patterns that influenced this choice
  111. - **Extensibility considerations**: How future features can fit in
  112.  
  113. ### 2.3 Priority Decisions
  114. - **What was prioritized**: Which work was done first and why
  115. - **What was deferred**: Work postponed and the reason
  116. - **Trade-offs**: Why some things were left incomplete
  117.  
  118. ## Step 3: Identify Knowledge Gaps and Uncertainties
  119.  
  120. Capture what is NOT yet known or understood:
  121.  
  122. ### 3.1 Unresolved Questions
  123. - Technical questions that remain unanswered
  124. - Behavior that's unclear or needs verification
  125. - Documentation that's ambiguous or contradictory
  126.  
  127. ### 3.2 Assumptions Made
  128. - What was assumed to be true (but not verified)
  129. - Why these assumptions were necessary
  130. - How to validate them later
  131.  
  132. ### 3.3 Areas Needing Investigation
  133. - Code areas that haven't been fully understood
  134. - Dependencies whose behavior is uncertain
  135. - Performance characteristics that haven't been measured
  136.  
  137. ## Step 4: Compile Failed Attempts Database
  138.  
  139. Document what DIDN'T work (crucial to avoid repetition):
  140.  
  141. ### 4.1 Failed Approaches
  142. For each approach that failed:
  143. - **What was tried**: Exact description of the attempt
  144. - **Why it seemed promising**: The logic that made it worth trying
  145. - **How it failed**: Specific error or incorrect behavior
  146. - **Root cause**: Why it didn't work (if understood)
  147. - **Lesson learned**: Insight gained from the failure
  148.  
  149. ### 4.2 Dead Ends Explored
  150. - Investigation paths that led nowhere
  151. - Code sections examined that turned out to be irrelevant
  152. - Documentation that was misleading
  153.  
  154. ### 4.3 Gotchas Discovered
  155. - Surprising behavior of libraries or frameworks
  156. - Subtle bugs or edge cases found
  157. - Configuration pitfalls encountered
  158.  
  159. ## Step 5: Generate Actionable Next Steps
  160.  
  161. Create ultra-specific next steps with maximal context:
  162.  
  163. ### 5.1 Immediate Next Actions
  164. For each next action, provide:
  165. - **Clear objective**: What should be accomplished
  166. - **Exact steps**: Numbered procedure to follow
  167. 1. Open file `[exact/path/to/file.ext]`
  168. 2. Locate function/section `[specific identifier]`
  169. 3. Modify by `[precise description]`
  170. 4. Test by running `[exact command]`
  171. 5. Expected result: `[what should happen]`
  172. - **Required context**: What needs to be understood first
  173. - **Success criteria**: How to know it's complete
  174. - **Estimated complexity**: Time/effort expectation
  175.  
  176. ### 5.2 Dependency Chain
  177. Order actions by dependencies:
  178. - **Prerequisites**: What must be done first
  179. - **Parallel work**: What can be done simultaneously
  180. - **Sequential requirements**: What must follow what
  181.  
  182. ### 5.3 Validation Strategy
  183. - How to verify each step worked
  184. - Tests to run and expected outputs
  185. - Manual checks to perform
  186.  
  187. ## Step 6: Analyze and Update HANDOFF.md
  188.  
  189. Load and analyze the existing `docs/ai-context/HANDOFF.md`:
  190.  
  191. ### 6.1 Understand Current Structure
  192. - Identify all existing sections and their status
  193. - Note any ongoing work that relates to this session
  194. - Observe formatting and organization patterns
  195. - Find any TODOs or open items
  196.  
  197. ### 6.2 Determine Update Strategy
  198.  
  199. **If work relates to existing section:**
  200. - Update progress in "What Was Accomplished"
  201. - Add new insights to "Key Insights and Decisions"
  202. - Update "Current Status" with new state
  203. - Modify "Failed Approaches" if new failures occurred
  204. - Revise "Next Steps" based on new progress
  205. - Update "Testing State" with new results
  206.  
  207. **If work is new/unrelated:**
  208. - Create new section with current timestamp
  209. - Use enhanced structure (see Step 7)
  210. - Maintain consistency with existing document style
  211.  
  212. **If work completed existing task:**
  213. - Mark task as [COMPLETED] with completion date
  214. - Summarize final outcome and learnings
  215. - Move to "Completed Work" archive section if it exists
  216. - Update any dependent tasks that can now proceed
  217.  
  218. ## Step 7: Write Enhanced HANDOFF.md Structure
  219.  
  220. Use this comprehensive structure for new sections or major updates:
  221.  
  222. ```markdown
  223. ## [Descriptive Task Title] - [Status: IN_PROGRESS/BLOCKED/TESTING/COMPLETED]
  224.  
  225. **Session Date**: [Current date and time]
  226. **Time Spent**: [Approximate duration of work]
  227.  
  228. ---
  229.  
  230. ### ๐Ÿ“‹ Current Status
  231.  
  232. [2-3 sentence summary of where things stand right now]
  233.  
  234. **Completion**: [X]% estimated complete
  235. **Confidence**: [HIGH/MEDIUM/LOW] - [Brief reason]
  236.  
  237. ---
  238.  
  239. ### โœ… What Was Accomplished
  240.  
  241. **Major Achievements:**
  242. - [Achievement 1 with file path if relevant: `path/to/file.ext`]
  243. - [Achievement 2 with specific technical detail]
  244. - [Achievement 3 with measurable outcome]
  245.  
  246. **Files Modified:**
  247. - `path/to/file1.ext` - [What changed and why]
  248. - `path/to/file2.ext` - [What changed and why]
  249. - `path/to/file3.ext` - [What changed and why]
  250.  
  251. **Commands Executed:**
  252. ```bash
  253. # [Purpose of command]
  254. exact-command --with --flags
  255. # Result: [What happened]
  256. ```
  257.  
  258. ---
  259.  
  260. ### ๐Ÿง  Key Insights and Decisions
  261.  
  262. **Technical Decisions:**
  263. 1. **Decision**: [What was decided]
  264. - **Reasoning**: [Why this approach]
  265. - **Alternatives Considered**: [What else was evaluated]
  266. - **Trade-offs**: [What was sacrificed]
  267.  
  268. **Patterns Discovered:**
  269. - [Pattern 1]: [Description and where it applies]
  270. - [Pattern 2]: [Description and implications]
  271.  
  272. **Critical Understanding:**
  273. [Important insight that changes how we think about the problem]
  274.  
  275. ---
  276.  
  277. ### โŒ Failed Approaches (DO NOT RETRY)
  278.  
  279. **Attempt 1: [Description]**
  280. - **Why tried**: [The reasoning]
  281. - **How it failed**: [Specific error or problem]
  282. - **Root cause**: [Why it didn't work]
  283. - **Lesson**: [What we learned]
  284.  
  285. **Attempt 2: [Description]**
  286. [Same structure as Attempt 1]
  287.  
  288. ---
  289.  
  290. ### ๐Ÿงช Testing State
  291.  
  292. **Tests Passing:**
  293. - โœ… [Test name/description] - Verifies [what functionality]
  294.  
  295. **Tests Failing:**
  296. - โŒ [Test name/description] - Error: [specific message]
  297. - Expected: [what should happen]
  298. - Actual: [what actually happens]
  299. - Investigation: [findings so far]
  300.  
  301. **Untested Areas:**
  302. - [ ] [Functionality that needs testing]
  303. - [ ] [Edge case to verify]
  304.  
  305. **Manual Testing Performed:**
  306. - Tested: [scenario] โ†’ Result: [outcome]
  307. - Verified: [behavior] โ†’ Status: [working/broken]
  308.  
  309. ---
  310.  
  311. ### ๐Ÿšง Current Issue / Blocker
  312.  
  313. [Detailed description of any blocking problem]
  314.  
  315. **Error Message:**
  316. ```
  317. [Exact error if applicable]
  318. ```
  319.  
  320. **Context:**
  321. - When it occurs: [triggering conditions]
  322. - What's been tried: [debugging attempts]
  323. - Current theory: [hypothesis about cause]
  324. - Related files: [`path/to/relevant/file.ext`]
  325.  
  326. ---
  327.  
  328. ### ๐ŸŽฏ Next Steps to [Specific Objective]
  329.  
  330. **Immediate Priority (Do First):**
  331. 1. **Action**: [Specific task]
  332. - **How**:
  333. a. [Precise step 1]
  334. b. [Precise step 2]
  335. c. [Precise step 3]
  336. - **File**: `exact/path/to/file.ext`
  337. - **Verify by**: [How to check it worked]
  338. - **Why**: [Reasoning for this approach]
  339.  
  340. 2. **Action**: [Next specific task]
  341. [Same detailed structure]
  342.  
  343. **Then Complete (Sequential Order):**
  344. 3. [Task 3 with dependencies noted]
  345. 4. [Task 4 with estimated complexity]
  346.  
  347. **Future Considerations (After Above):**
  348. - [Longer-term improvement or refactor]
  349. - [Performance optimization to consider]
  350. - [Tech debt to address]
  351.  
  352. ---
  353.  
  354. ### ๐Ÿ“ Key Files and Their Roles
  355.  
  356. **Primary Files:**
  357. - `path/to/main/file.ext` - [Core responsibility and importance]
  358. - `path/to/config.ext` - [Configuration role and key settings]
  359.  
  360. **Supporting Files:**
  361. - `path/to/helper.ext` - [What it helps with]
  362. - `path/to/test.ext` - [What it tests]
  363.  
  364. **Dependencies:**
  365. - `external/library` - [Why used and key APIs leveraged]
  366.  
  367. **File Relationships:**
  368. ```
  369. main.ext
  370. โ”œโ”€> imports helper.ext (provides [functionality])
  371. โ”œโ”€> uses config.ext (reads [settings])
  372. โ””โ”€> tested by test.ext (verifies [behavior])
  373. ```
  374.  
  375. ---
  376.  
  377. ### ๐Ÿ” Code Patterns to Follow
  378.  
  379. **Naming Conventions:**
  380. - Functions: [pattern, e.g., camelCase, verb-noun structure]
  381. - Variables: [pattern, e.g., descriptive, type-hinted]
  382. - Files: [pattern, e.g., kebab-case, feature-based]
  383.  
  384. **Architecture:**
  385. - [Pattern used, e.g., "Repository pattern for data access"]
  386. - [Separation principle, e.g., "Business logic in services, not controllers"]
  387.  
  388. **Error Handling:**
  389. - [Project standard, e.g., "Custom exceptions extending BaseException"]
  390. - [Propagation style, e.g., "Catch at boundary, log, return error response"]
  391.  
  392. ---
  393.  
  394. ### โš ๏ธ Gotchas and Pitfalls
  395.  
  396. **Be Aware:**
  397. - โš ๏ธ [Specific pitfall 1 and how to avoid it]
  398. - โš ๏ธ [Surprising behavior 2 that could cause confusion]
  399. - โš ๏ธ [Configuration detail 3 that's easy to miss]
  400.  
  401. **Don't Do:**
  402. - โŒ [Anti-pattern observed and why it's wrong]
  403. - โŒ [Common mistake and its consequences]
  404.  
  405. ---
  406.  
  407. ### ๐Ÿ“ Context for Next Session
  408.  
  409. **Mental State:**
  410. [Describe the current "flow" of work - what was the thought process, what's the momentum toward, what's the overall strategy being pursued]
  411.  
  412. **Assumptions to Validate:**
  413. - [Assumption 1 that hasn't been verified]
  414. - [Assumption 2 that needs testing]
  415.  
  416. **Questions to Answer:**
  417. - [Question 1 about the system]
  418. - [Question 2 about implementation]
  419.  
  420. **When Resuming:**
  421. 1. Read this entire section first
  422. 2. Review [specific file] to refresh on [context]
  423. 3. Run [specific command] to see current state
  424. 4. Continue with Next Steps priority #1
  425.  
  426. ---
  427.  
  428. ### ๐Ÿ”— Related Work and Dependencies
  429.  
  430. **Depends On:**
  431. - [Other task/section] must be [state] before this can [action]
  432.  
  433. **Blocks:**
  434. - [Other task/section] is waiting on this to [milestone]
  435.  
  436. **Related To:**
  437. - [Other task/section] shares [commonality]
  438.  
  439. ---
  440.  
  441. ### ๐Ÿ“š References and Resources
  442.  
  443. **Documentation:**
  444. - [Library/API docs] - [Relevant section]: [URL]
  445. - [Internal docs] - [`path/to/doc.md`] - [What it explains]
  446.  
  447. **External Resources:**
  448. - [Article/tutorial] - [Key insight]: [URL]
  449. - [Stack Overflow] - [Relevant answer]: [URL]
  450.  
  451. **Code Examples:**
  452. - [Example 1] - [Where it is]: `path/to/example.ext`
  453. ```
  454.  
  455. ---
  456.  
  457. ## Step 8: Quality Assurance Checklist
  458.  
  459. Before finalizing, verify the handoff meets these criteria:
  460.  
  461. ### 8.1 Completeness Check
  462. - โœ… All significant file changes documented with reasoning
  463. - โœ… All important commands captured with context
  464. - โœ… All decisions explained with alternatives considered
  465. - โœ… All failures documented to prevent repetition
  466. - โœ… All insights and patterns recorded
  467. - โœ… Testing state fully captured
  468. - โœ… Next steps are actionable and specific
  469. - โœ… Current blockers clearly described
  470. - โœ… Code patterns and conventions noted
  471.  
  472. ### 8.2 Clarity Check
  473. - โœ… Someone new could understand the situation immediately
  474. - โœ… Technical terms are either defined or obviously clear
  475. - โœ… File paths are exact and complete
  476. - โœ… Commands can be copy-pasted and run
  477. - โœ… Reasoning is explicit, not assumed
  478. - โœ… Status is unambiguous
  479.  
  480. ### 8.3 Continuity Check
  481. - โœ… Builds naturally on previous work (if any)
  482. - โœ… References to past context are clear
  483. - โœ… Connection to project goals is evident
  484. - โœ… Priority and urgency are communicated
  485. - โœ… Dependencies on other work are noted
  486.  
  487. ### 8.4 Actionability Check
  488. - โœ… Next steps could be started immediately
  489. - โœ… No information gaps that would require research
  490. - โœ… Success criteria are measurable
  491. - โœ… Validation methods are specified
  492. - โœ… Estimated complexity helps planning
  493.  
  494. ## Step 9: Meta-Reflection
  495.  
  496. After updating HANDOFF.md, add a brief meta-reflection:
  497.  
  498. ```markdown
  499. ---
  500.  
  501. ## ๐ŸŽญ Session Meta-Reflection
  502.  
  503. **Overall Assessment:**
  504. This session [achieved X / made progress on Y / uncovered Z]. The work is [on track / ahead of schedule / facing challenges / blocked].
  505.  
  506. **Momentum:**
  507. [HIGH/MEDIUM/LOW] - [Explanation of current momentum and trajectory]
  508.  
  509. **Confidence in Direction:**
  510. [HIGH/MEDIUM/LOW] - [How confident we are this is the right approach]
  511.  
  512. **Recommended Next Focus:**
  513. [Where the next session should concentrate effort and why]
  514.  
  515. **Estimated Time to Completion:**
  516. [Realistic estimate based on current progress and complexity]
  517.  
  518. ---
  519. ```
  520.  
  521. ## Step 10: Final Output
  522.  
  523. Present your handoff update with:
  524.  
  525. 1. **Summary of Changes**: Brief overview of what you updated in HANDOFF.md
  526. 2. **Key Takeaways**: 3-5 most important points for next session
  527. 3. **Immediate Priority**: The single most important next action
  528. 4. **Confidence Assessment**: Your confidence level in the current direction
  529.  
  530. Then show the relevant updated sections from HANDOFF.md for user review.
  531.  
  532. ---
  533.  
  534. ## Advanced Tips for Perfect Handoff
  535.  
  536. **Capture the "Why" not just the "What":**
  537. Every action has reasoning. Document it. Future you (or next AI) needs to understand the thought process, not just the result.
  538.  
  539. **Failed approaches are valuable:**
  540. Don't hide failures. They're learning opportunities and prevent wasted effort repeating the same mistakes.
  541.  
  542. **Be specific with file paths:**
  543. "Updated the config file" is useless. "`config/database.json` - Changed connection pool size from 10 to 50 to handle increased load" is gold.
  544.  
  545. **Make next steps actionable:**
  546. "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.
  547.  
  548. **Document your mental model:**
  549. Explain how you understand the system working. Your mental model is what enables quick decisions. Share it.
  550.  
  551. **Preserve context for decisions:**
  552. When you choose approach A over B, explain why. Future work might change the constraints, and knowing why B was rejected helps re-evaluate.
  553.  
  554. **Note code patterns explicitly:**
  555. Every codebase has unwritten conventions. Write them down. It speeds up all future work.
  556.  
  557. **Include validation steps:**
  558. For every change, note how to verify it worked. This enables confident progress and quick debugging.
  559.  
  560. Now execute this enhanced handoff process, integrating user context "$ARGUMENTS" with your deep session analysis.
Advertisement
Add Comment
Please, Sign In to add comment