---
name: session-reset-handler
description: Handle automatic session resets - save important info before context clears
trigger: System notifies about impending session reset due to inactivity or daily schedule
---

# 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
- 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, any compacted handoff summary, and the live source of truth.
3. If the user says the work was “mid-flight,” “the session we were in,” or otherwise identifies an unfinished active task, resume that task from the recovered state. Do not answer with a generic “What would you like me to do next?” when the handoff already contains a concrete active investigation or release path. Inspect the original screenshot/URL/repository/live service first when accessible, then continue the next unresolved gate.
4. Reply with concrete status evidence: working directory, live service/domain, process/port, tests/build/deploy/commit status, changed files, and screenshots/artifacts if available.
5. Avoid vague “we're up to date” claims unless backed by retrieved context or fresh verification.
6. Do not save completed task progress to memory; use memory only for durable user preferences or stable project facts.

### Wrong-session recovery pitfall
If the user says something like "look at what you made" after a reset and the artifact/source is not visible in the current conversation, do **not** guess from the most recent session. Ask for or inspect the actual source first: screenshot path, URL, repo path, app name, or direct thread artifact. Session search is secondary context, not proof of the current target. Recency matches can be dangerously wrong when several projects share the same repo or app name (for example Astral Hermes rebuild vs a later rulership-lab session). When the user corrects the target session, immediately drop the stale session context and re-search with the user's exact anchors.

## 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