The Problem

Claude doesn’t remember previous sessions. Every conversation starts fresh. When you solve a tricky problem - a non-obvious flag, a gotcha behavior, a workaround for a tool limitation - that knowledge evaporates.

Claude Code does store session history locally (the path is configurable), so you could go back and review old sessions. But the history grows fast, and batch-processing weeks of conversations is slow and expensive. By the time you get around to it, you’ve forgotten which sessions were actually useful.

The better approach: capture learnings at the end of each session that matters, while the context is still loaded. Make Claude do it.

The Approach

Claude Code has a skill system. Skills are markdown files with instructions that Claude follows when invoked. You can trigger them with slash commands.

The idea: create a /summarize-session skill that reviews the current session, extracts what’s worth remembering, and appends it to a daily journal file.

The key constraint: keep it brief. You want breadcrumbs for pattern recognition, not an encyclopedia. One-liners that help you recognize similar problems later.

What Counts as Notable

Not everything deserves logging. The skill needs criteria:

  • A fix that took more than one attempt to figure out
  • A non-obvious flag, config, or parameter that solved the issue
  • A decision between alternatives with a clear winner (include why)
  • A gotcha or surprise behavior that wasn’t expected
  • A workaround for a tool/library limitation
  • A pattern you’d want to reuse

And what to skip:

  • Typos, syntax errors, missing imports
  • Standard workflow (ran tests, committed, created PR)
  • General tool knowledge (google-able stuff)
  • Back-and-forth before reaching the answer

The Skill

Create ~/.config/claude/skills/summarize-session/SKILL.md:

---
name: summarize-session
description: Log brief session learnings to journal
disable-model-invocation: true
allowed-tools: Read, Write, Edit
---

Review this session. Extract only what's worth remembering later.

## What counts as notable

Log if it matches ANY of these:
- A fix that took more than one attempt to figure out
- A non-obvious flag, config, or parameter that solved the issue
- A decision between alternatives with a clear winner (include why)
- A gotcha or surprise behavior that wasn't expected
- A workaround for a tool/library limitation
- A pattern you'd want to reuse
- A heuristic or rule of thumb derived from data analysis

## Output

Write to today's journal file at /path/to/your/journal/YYYYMMDD.md

If the file does not exist, create it with:

# YYYY-MM-DD

## Learned

- [problem/context]: [solution or key insight]

If the file exists but has no ## Learned section, add it at the end.
If ## Learned section exists, append new items to it.

## Examples to LOG

- fluentbit chunks stuck: delete .meta files in /var/log/fluentbit/chunks
- clickhouse slow query: was missing index on timestamp column
- chose X over Y: Y had memory leak issues in long-running processes
- estimation from time logs: infra tasks take 3-5x longer than feature work

## Examples to SKIP

- Typos, syntax errors, missing imports
- Standard workflow (ran tests, committed, created PR)
- General tool knowledge (google-able)
- Back-and-forth before reaching the answer
- Explanations of why something works

If nothing notable happened, say so and don't write anything.

## Additional Instructions

$ARGUMENTS

The disable-model-invocation: true is important - you don’t want Claude automatically triggering this. It should only run when you explicitly invoke /summarize-session.

Usage

At the end of a session where you solved something non-trivial:

/summarize-session

Claude reviews the conversation, extracts learnings, and appends them to your journal. Over time, you build a searchable log of problems solved and patterns discovered.

Why This Works

The value isn’t in the individual entries. It’s in the accumulation. After a few months, you have a corpus of solved problems. When you hit something similar, grep your journal. The breadcrumb might be enough to jog your memory or point you in the right direction.

It’s also a feedback loop for your own workflow. Patterns emerge: “infra tasks take 3-5x longer” is the kind of insight you only notice when you have data.

The key is keeping entries short. One line per learning. If you can’t summarize it in one line, it’s probably too complex to be useful as a breadcrumb anyway.