Skip to main content

End session — memory + handoff wrap-up

This skill closes the loop between session work and durable memory. By the time a session ends, the memory store should reflect what actually happened — not what was true when the session started.

When to invoke​

Manual: /end-session. The developer types it when they're wrapping up.

Auto-invoke (after explicit confirmation): when the developer signals closure in their language — "סיימנו", "תודה, די", "done for today", "let's stop here", "thanks, bye" — and the session did substantive work (opened/merged PRs, made significant decisions, shifted scope). Don't auto-invoke for trivial chat-only turns. Confirm before running: "לפני שאסיים, רוצה שאעבור על memory + PRs?"

What "substantive work" means​

A session is substantive if any of the following happened:

  • A PR was opened (gh pr create) or merged.
  • A branch was pushed.
  • A methodology decision was made (something that should be a memory entry or an ADR).
  • Scope shifted from what memory said at session start.
  • More than ~10 tool calls produced state-changing edits.

Trivial sessions (research-only, conversational, single read of a file) don't need a wrap-up.

Steps​

1. Inventory the session​

Collect facts before judging anything:

# PRs touched (opened or merged) this session
unset GITHUB_TOKEN
gh pr list --state all --search "author:@me updated:>=$(date -u -v-1d +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%SZ)" --json number,title,state,updatedAt --limit 20

# Branches you created or pushed this session
git branch --sort=-committerdate | head -10

# Files modified in the current branch
git diff --name-only origin/master..HEAD 2>/dev/null

# Capabilities this session used — agents, skills, artifacts, files
# (deterministic, from the capability-trace.sh trace; empty if the indicator is
#  off or the trace hook was not active when this session started)
bash scripts/capability-view.sh --summary 2>/dev/null

List the results to the developer. Don't filter yet — show everything you found, let them confirm what counts. Include the capability summary in the hand-off message (step 6) so the developer sees which experts/artifacts this session actually drew on.

2. Scan memory for stale references​

Walk MEMORY.md and look for entries that name checkable artifacts:

# Where memory lives — adjust to the user's path. Typical locations:
MEMORY_DIR="$HOME/.claude/projects/-Users-${USER}-workspace-bewith-docs/memory"
# (or wherever the originating session wrote, given the project hash)

grep -rE 'PR #[0-9]+|feature/[a-z]|fix/[a-z]|docs/|chore/' "$MEMORY_DIR/" 2>/dev/null | head -30

For each match, run the appropriate cheap freshness check (see docs/methodology/session-safety.md — read-side freshness). Surface any drift in one line per finding.

3. Decide what to write​

For each significant thing the session did, decide whether it earns:

Memory typeWhen
project entryNew PR opened, scope shift, decision recorded, open item discovered
feedback entryThe developer told you a preference or correction you didn't already have
reference entryA new external system or URL was introduced
user entryA new fact about who the developer is or their role

Don't write a generic "we worked on X today" summary — that's narrative, not durable knowledge. Memory captures what changed and what's still load-bearing for next session.

Format per the auto-memory instructions in the user's global memory store (MEMORY.md index + per-entry frontmatter). Update existing entries before creating new ones — prefer fewer, denser entries.

4. Update the roadmap heartbeat​

project_roadmap.md has a header block ("Last updated", "Current branch", "Master HEAD", "Recent merges", "Open PRs"). Verify those reflect reality:

git log --oneline origin/master -3
gh pr list --state open --json number,title --jq '.[] | "#\(.number) \(.title)"'

If the roadmap header is stale, refresh it. This is the one entry the next session reads first — keeping it fresh saves the next session from drift detection.

5. Consider proposing a team rule​

If you noticed any generic insight that would help any bewith-dev developer (not user-specific), pause and invoke propose-team-rule. Don't auto-propose — ask the developer per its discrimination guidance.

6. Hand off cleanly​

After memory writes, summarise in one short message:

  • Memory updated: <N> entries written/edited.
  • Open loops for next session: <list, ≤3 items>
  • PRs awaiting your review: <list>

Then stop. Don't suggest more work unless the developer asks.

Anti-patterns​

  • Writing a daily-summary entry. Memory is for durable knowledge, not journal. "We had a productive session today" gets garbage-collected mentally and provides zero value next session.
  • Updating memory inside the skill but skipping the roadmap heartbeat. Stale roadmap is the #1 source of next-session drift — see [[situational-awareness]].
  • Running /end-session after every short turn. It's an end-of-session wrap, not an after-action review. Skip for trivial work.
  • Auto-invoking without explicit confirmation. Even when the developer says "סיימנו", confirm — they may have one more thing.
  • Editing memory entries from a parallel session's perspective. The session running /end-session writes what its work shows. Other concurrent sessions may have written their own entries; don't overwrite.

Cross-references​