# Session Handoff

> End-of-session knowledge capture — decisions, preferences, corrections, conventions, open questions

- Skill: `n24q02m/session-handoff` (Agent Skill)
- Install (CLI): `npx skillmds@latest add n24q02m/session-handoff`
- Raw SKILL.md: https://api.skillmd.com/api/skills/n24q02m/session-handoff/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: n24q02m (https://skillmd.com/u/n24q02m)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/n24q02m/session-handoff

---


# Session Handoff

Structured end-of-session capture that ensures the NEXT session starts with full context. Enforces "WHY not just WHAT" — every memory must include the reasoning, not just the fact.

## Checklist (go through ALL categories)

Before storing anything, review the conversation for each category:

1. **Decisions made**: Technical choices, architecture decisions, tool selections
   - BAD: "Using PostgreSQL"
   - GOOD: "Using PostgreSQL over SQLite because we need concurrent writes from multiple workers and the data exceeds 10GB"

2. **Preferences expressed**: User's workflow preferences, style choices, communication preferences
   - BAD: "Prefers short commits"
   - GOOD: "Prefers atomic commits (one logical change per commit) because they review PRs commit-by-commit and need clean bisect history"

3. **Corrections given**: Things the user corrected — these are HIGH PRIORITY (prevents repeat mistakes)
   - BAD: "Don't use fmt.Println"
   - GOOD: "Corrected: use log.Printf not fmt.Println in Go services because stdout is not captured by the log aggregator (Alloy)"

4. **Conventions established**: Naming patterns, file organization, coding standards
   - BAD: "Use snake_case"
   - GOOD: "Convention: snake_case for Python files and functions, but PascalCase for Pydantic models. Established because the codebase mixes both and this was the cleanup decision"

5. **Open questions**: Unresolved items that need future attention
   - Store these explicitly so the next session can address them
   - Include what was already tried or considered

## Storage Process

For each item identified above:

1. **Store with context** using `memory(action="add", ...)`:
   - Content MUST include WHY, not just WHAT
   - Tag with category: `decision`, `preference`, `correction`, `convention`, `open-question`
   - Tag with project name for scoped retrieval
   - Include date context if time-sensitive

2. **Verify retrieval** (mandatory — do NOT skip):
   - `memory(action="search", query="[natural terms someone would use to find this]")`
   - If the memory does not appear in top results, either:
     - Rewrite content with better keywords
     - Add more specific tags
   - A memory that cannot be found is worthless

3. **Produce handoff summary** for the user:
   ```
   ## Session Handoff — [date]

   ### Stored
   - [N] decisions, [N] preferences, [N] corrections, [N] conventions

   ### Open Questions (carried forward)
   - [list unresolved items]

   ### Key Context for Next Session
   - [1-3 sentence summary of where things stand]
   ```

## Quality Rules

- **WHY not WHAT**: Every memory must answer "why was this decided/preferred/corrected?"
- **Specific over generic**: "Use Polars for dataframes" is useless without "because pandas is banned per project rules and Polars handles our 50M row dataset in 2s vs 45s"
- **One insight per memory**: Do not cram multiple unrelated facts into one entry
- **Verify or discard**: If retrieval verification fails after 2 rewrites, the content is too vague to be useful
- **No ephemeral facts**: Do not store things that will be outdated next session (e.g., "currently on line 42 of file X")

## When to Use

- End of any productive session (before the conversation closes)
- When explicitly asked to "remember this" or "save for next time"
- After debugging sessions — capture root cause and fix
- After architecture or design discussions with decisions