claude-plugins/plugins/save-doc/commands/session.md

description	allowed-tools
Save a session summary capturing work done, decisions made, and follow-ups	Read,Write,Edit,Glob,Grep,Bash

Save a session summary documenting what was accomplished in a working session. Captures decisions, changes, and follow-up items for future context.

Defaults

• type: context
• filename: YYYY-MM-DD.md (use the current date)
• tags: always include the repo name if work was repo-specific
• save path: /mnt/NV2/Development/claude-home/{domain}/

Gathering Context

Before writing, collect what you can automatically:

1. Git log — commits made during this session (today's commits, or commits on the current branch)
2. Branch name — the working branch
3. Changed files — git diff --stat for a summary
4. Issues/PRs — any created or referenced during the session
5. Ask the user for domain if not obvious, and for any decisions or context not captured in commits

Document Structure

---
title: "{Ticket/Topic}: {Brief description of work}"
description: "One-line summary of the session — what was done and in which repo."
type: context
domain: {domain}
tags: [{repo-name}, ...]
---

# {Ticket/Topic}: {Brief description}

**Date:** YYYY-MM-DD
**Branch:** `{branch-name}`
**Repo:** {repo-name}

## What Was Done

Narrative summary of the work, followed by a numbered list of specific changes:

1. **{Change title}** — description of what and why
2. ...

## Decisions

Key decisions made during the session and their rationale. Use this format:

### {Decision title}
{What was decided and why. Include alternatives considered if relevant.}

## Follow-Up

| # | Title | Priority |
|---|-------|----------|
| [#{n}](url) | {description} | {High/Medium/Low} |

Or as a bullet list if issues weren't created:
- {thing that still needs to be done}

## Files Changed

- `path/to/file.py` — brief note on what changed

Rules

• Omit empty sections — skip Decisions or Follow-Up if there's nothing to capture
• The title should reference a ticket number or topic, not just a date
• Focus on decisions and "why" — the git log already records "what"
• If multiple repos were touched, note which changes belong to which repo
• Only include file-level change notes when they add context beyond what git shows