session-reset-handler

Session Reset Handler

Steps

1. Quick scan the conversation for any NEW information not already in memory: - User corrections or preferences - Environment changes - New workflows discovered - Problems solved with lessons learned

2. Save to memory only if genuinely new and durable (skip if already captured)

3. Save to skill if you discovered a reusable workflow or solved a complex problem (5+ tool calls)

4. Stop responding - the system handles the reset automatically

Key Points

Key Points

• Session resets are automatic - no user action needed
• Memory persists across resets
• Don't save temporary task progress
• Don't overwrite existing memory entries unless conversation reveals superseding information
• If conversation was just chit-chat with no substance, skip saving anything
• Never respond to the user after a reset notification - just use tools and stop

User-Initiated Session Resume

When the user asks to "get back into" or "pull up" a prior session: 1. Search previous session/context using distinctive project names, domains, paths, and issue phrasing. 2. Reconcile retrieved history with current injected memory and any compacted handoff summary. 3. Reply with concrete status evidence: working directory, live service/domain, process/port, tests/build/deploy/commit status, changed files, and screenshots/artifacts if available. 4. Avoid vague "we're up to date" claims unless backed by retrieved context or fresh verification. 5. Do not save completed task progress to memory; use memory only for durable user preferences or stable project facts.

Pitfalls

• Don't duplicate info already in memory (check current memory state provided in notification)
• Don't save transient task progress
• Don't respond to user after reset notification
• Don't remove/overwrite existing memory entries unless truly superseded