done

name	done
description	Session wrap-up — save context, summarize, persist memory, growth suggestions. Use at the end of any coding or agent session. Triggers on "/done", "收工", "session done", "session cleanup", "結束", "清理", "wrap up", "存 session", "記錄這次 session".
allowed-tools	Bash, Read, Write, Edit, Glob, Grep
version	1.0.0
scope	public

/done — Session Closer

Do three things at the end of a session. Goal: finish in 2-3 minutes, not write a report.

---

Workflow

1. SESSION MD  → Save handoff doc (so the next session can pick up) + track follow-ups
2. FEEDBACK    → Record skill performance this session (skip stable skills, most sessions skip this)
3. MEMORY      → Write things worth remembering across sessions to auto memory (most sessions skip this)

Most sessions only need Step 1. Steps 2 and 3 are only done when there's something worth recording.

---

Step 1: Save Session MD

Save this conversation's context as .md so it can be searched and retrieved later.

Get meta

# git branch (only available inside a code project)
git branch --show-current 2>/dev/null || echo "no-git"

If not in a git repo, use the conversation topic as a slug (kebab-case, e.g. done-skill-build, rss-cron-debug).

Determine save path

Determine where to save the session MD based on the project:

Condition	Path
Inside obsidian-vault	docs/sessions/
Inside another git repo	docs/sessions/ under project root
Non-git context	<vault>/_openclaw/sessions/ (fallback)

# Detect path
if git rev-parse --show-toplevel &>/dev/null; then
  SESSION_DIR="$(git rev-parse --show-toplevel)/docs/sessions"
else
  SESSION_DIR="/Users/panda/site/knowledge/obsidian-vault/_openclaw/sessions"
fi
mkdir -p "$SESSION_DIR"

Compose frontmatter + content

---
date: YYYY-MM-DD
branch: <branch-or-topic>
project: <repo-or-context>
tags: [coding-session, <project>]
---

# <branch-or-topic> — <date>

## What happened
[3-5 sentence narrative: what was done, why, what problems came up, how they were solved, what approach was chosen.
Write it like a shift handoff note for a colleague taking over, not a form.]

## Current state
[Where things stopped. In-progress items, completion percentage, blockers.
If everything is done, write "Complete, nothing in progress."]

## Follow-ups
- [ ] [Things to do next or unresolved issues]

Writing guidelines:

• "What happened" should be narrative, not bullet list — like telling a friend "what I did today"
• "Current state" should be specific: not "implementing dark mode" but "dark mode CSS variables done, toggle hook not yet written"
• If there are no follow-ups, omit this section
• No Notes section needed — important things go in the narrative, unimportant things don't need recording

Save (always write this):

cat > "$SESSION_DIR/YYYY-MM-DD-<slug>.md" << 'EOF'
<content>
EOF

Follow-ups Routing

Follow-ups are already recorded in the session doc (searchable via qmd), no longer appended to a central tracking file.

If there are clear dev follow-ups (bugs, features, tech debt), prompt the user:

These follow-ups are good candidates for GitHub Issues:

• gh issue create -t "..." -b "..." -R <repo> Want me to create them?

Only create if the user says yes, never automatically. Non-dev follow-ups don't need extra handling.

After saving, update the qmd index:

qmd update

---

Step 2: Skill Feedback（Learning Loop）

Record which skills were used this session and how they performed. This helps skills improve over time.

Stable Skill Evaluation

Skip skills already marked as stable. At the top of learnings.md there's a ## Stable Skills section listing skills with 3+ consecutive A grades. These skills are only re-recorded when they get a B or C.

If a stable skill gets a B or C this session:

1. Remove it from the stable block
2. Record it normally in the table
3. Clearly describe the regression reason

Process

1. List all skills triggered/used this session
2. Filter out stable skills (unless B/C this session)
3. Grade each skill that needs recording:
   • A = shipped as-is (used directly, no changes)
   • B = minor edits (small tweaks needed)
   • C = rewrote significantly (major rewrite or not used at all)
4. If B or C, write one line explaining why (specifically what went wrong)
5. Append to learnings file

Write location

# Append (never overwrite)
cat >> ~/.claude/skills/learnings.md << 'EOF'
| YYYY-MM-DD | skill-name | A/B/C | one-line note |
EOF

Learnings Aggregation (when > 80 entries)

Each time /done runs, check the learnings table line count:

TABLE_LINES=$(grep -c '^|' ~/.claude/skills/learnings.md)

If > 80 lines:

1. Scan for skills with 3+ consecutive A grades → add to ## Stable Skills section
2. Delete all old A records for stable skills (keep only the most recent 1 entry as a timestamp)
3. Keep all B/C records (these have learning value)
4. Write aggregated results back to learnings.md

Post-aggregation learnings.md format:

# Skill Learnings

> Append-only log. Written by `/done` skill after each session.
> Format: `| date | skill | grade | note |`
> Grades: A = shipped as-is, B = minor edits, C = rewrote significantly

## Stable Skills (3+ consecutive A, skip logging unless B/C)

gh-commit, gh-push, openspec, opsx-team-apply, rust-tauri-practices, done, opsx:bulk-archive, ...

Last aggregated: YYYY-MM-DD

| Date | Skill | Grade | Note |
|------|-------|-------|------|
| ... only B/C records + last A of each stable skill ... |

When to skip feedback

• No skills were triggered this session
• Pure conversation with no implementation
• Session was very short (< 5 minutes)

---

Step 3: Save to Memory (most sessions skip this)

Only save things worth remembering across sessions.

Write location

~/.claude/projects/<project>/memory/MEMORY.md   ← Index (always loaded in system prompt, keep it lean)
~/.claude/projects/<project>/memory/<topic>.md  ← Topic files (store details)

Routing logic (route first, then write)

Before writing, read MEMORY.md and check the Topic Files table:

1. Matching topic file exists → Write directly to that topic file (Edit append), leave MEMORY.md untouched
2. No match but it's a new topic → Create new memory/<topic>.md, add a row to MEMORY.md Topic Files table
3. Cross-topic preferences/decisions → Write to MEMORY.md's User Preferences or Key Decisions section

MEMORY.md is an index, not a journal. Don't append large blocks of content to MEMORY.md.

Overflow check

MEMORY_FILE="<project-memory-dir>/MEMORY.md"
LINES=$(wc -l < "$MEMORY_FILE" 2>/dev/null || echo 0)

Lines	Action
< 80	Normal (should stay in this range in index mode)
80-150	Check if content should be moved to topic files
> 150	Must slim down: move detailed content to topic files, keep only the index in MEMORY.md

Should save

• Stable patterns/conventions (confirmed multiple times)
• Important architectural decisions, file path changes
• User preferences (workflows, tools, communication style)
• Recurring problems and their solutions

Should not save

• Specific task details from this session
• Unverified speculation
• Things already in CLAUDE.md

If nothing is worth saving, skip this step.

---

---

Safety

Situation	Action
No git repo	Use conversation topic as slug, save to fallback path
Nothing worth saving to memory	Skip Step 3 (this is the norm)
MEMORY.md > 190 lines	Slim down first before writing, don't exceed 200 lines
learnings > 80 entries	Trigger aggregation, compress stable skills