---
name: bye
description: End-of-session reflection and knowledge extraction. Reviews the conversation to propose reusable skill creation, skill updates, and memory saves — then implements whichever the user approves.
user_invoked: true
---

# Session Wrap-Up

When the user signals they're done, review the full conversation and propose actionable extractions. The goal is to capture genuinely reusable knowledge — not to justify the skill's existence by proposing busywork.

## What to look for

Scan the conversation for these signals:

### New skill candidates
- A multi-step workflow that was performed and could be reused (not a one-off fix)
- A pattern that required research or trial-and-error that future sessions would repeat
- Something the user explicitly asked to turn into a reusable command

### Skill updates
- A skill was invoked but required manual correction afterward — the correction should be folded back in
- A skill's instructions turned out to be wrong or incomplete based on what happened
- A skill triggered when it shouldn't have, or didn't trigger when it should have (description needs tuning)
- **Exception**: if a skill was explicitly *created* during this session, don't suggest editing it — it's already fresh

### Memory saves
- The user shared context about their role, preferences, or workflow that would help future sessions (user memory)
- The user corrected your approach in a way that applies beyond this conversation (feedback memory)
- A project decision, deadline, or external reference was mentioned that isn't in code/git (project/reference memory)
- Don't suggest saving things that are already in code, git history, or existing CLAUDE.md files

## Output format

Present findings as a numbered table. Be specific in descriptions — vague entries waste the user's time reviewing them.

```
| #  | Type          | Location       | Description                                              |
|----|---------------|----------------|----------------------------------------------------------|
| 1  | new skill     | user           | /foo — one-line summary of what it automates             |
| 2  | update skill  | repo (repo name) | /bar — what specifically to change and why        |
| 3  | add memory    | user           | type: feedback — the specific insight to save            |
```

**Location** indicates where the change lives:
- **user** — personal preference stored in `~/.claude/` (memory, user-level skills). Only affects this user's sessions.
- **repo (name)** — shared with the team via the repo's `.claude/skills/` or `CLAUDE.md`. Use for universally useful knowledge (gotchas, CI patterns, workflow fixes). Don't push personal preferences to the repo.

When proposing items, consider the audience: if it's a personal workflow preference (e.g., "always babysit CI"), it belongs in user memory. If it's a factual improvement that helps anyone using the repo (e.g., a CI gotcha, a skill bug fix), it belongs in the repo.

If there's genuinely nothing worth extracting, say so plainly: "Nothing from this session jumps out as worth saving. See you next time!" Don't pad the table with marginal items. **Less is better than bloated many.**

**But be honest with yourself** — if the session discovered a concrete gotcha, workaround, or non-obvious behavior (e.g., a mock limitation, a float precision issue, an API quirk), that IS worth saving even if no skill was explicitly invoked. The bar is "would this save a future session from repeating the same discovery?" not "was a skill used?"

## After presenting the table

Wait for the user to confirm which items (by number) they want to proceed with. Then implement them:

- **New skill**: create the SKILL.md in `~/.claude/skills/<name>/`, following the standard frontmatter format
- **Update skill**: edit the existing SKILL.md with the specific improvement
- **Add memory**: write the memory file and update MEMORY.md index, following the memory system conventions (frontmatter with name/description/type, content with Why/How to apply for feedback/project types)

After implementing, commit the changes to the dotfiles bare repo:
```bash
git --git-dir=$HOME/.dotfiles --work-tree=$HOME add ~/.claude/skills/... ~/.claude/projects/.../memory/...
git --git-dir=$HOME/.dotfiles --work-tree=$HOME commit -m "bye: description of what was saved"
```

## Judgment calls

- Err on the side of fewer, higher-quality proposals
- A skill that would be used once a month isn't worth creating — the user can just describe it
- Memory that duplicates what's in code or CLAUDE.md is noise
- If a skill update is trivial (one-word fix), just mention it conversationally instead of making it a table row