Your Claude Code transcripts know what your next skill should be — mine them
We extracted 1,451 of our own prompts from Claude Code's session logs and counted what we kept retyping. The repeats became three new skills and a pile of instructions the agent now reads automatically.
We spent today mining our own Claude Code history: 1,451 prompts we'd actually typed, across 26 projects, extracted from the session transcripts Claude Code keeps on disk. The question we asked was simple — what do we keep telling the agent over and over? — and the answers were embarrassing enough to act on. By the end of the session we'd shipped three new skills, upgraded five existing ones, and moved a pile of repeatedly-dictated context into files the agent reads automatically.
What we found in the scrollback
Every Claude Code session is logged as JSONL under ~/.claude/projects/, one directory per project. Extracting just the things you typed takes one pass with jq:
for f in ~/.claude/projects/*/*.jsonl; do
jq -r 'select(.type=="user") | .message.content |
if type=="string" then . else empty end' "$f"
done > prompts.txt
Deduplicated and counted, our corpus said:
- "commit and push" typed ~39 times as a bare command; "update the docs" ~40 times — usually together, as an end-of-session ritual we ran by hand every single day.
- "I've added the key to .env.local" narrated ~35 times, because the agent had no convention for discovering it.
- A ~200-word dependency-update boilerplate pasted 14 times, one per project, identical apart from the package list.
- The same business positioning re-dictated at length, three or more times, in the same project — the longest prompts in the entire corpus were us re-explaining things we'd already explained.
None of these is a prompt-engineering problem. They're all memory problems: instructions that belonged in a file the agent reads at session start, not in our fingers.
Why this beats guessing what to automate
If you'd asked us to list our repetitive instructions from memory, we'd have named two or three. The transcripts surfaced eighteen, ranked by actual frequency. The data also killed some assumptions — a "cross-session handoff" tool we'd have sworn we needed ranked well below fixing the doc rot that made every session start with "remind me what this project is".
The rule of thumb that fell out: anything you've typed three times is a candidate; anything you've typed ten times is a bug. The fix depends on the shape:
- A repeated sequence becomes a skill — ours were
/wrapup(sync docs → build → commit → gated push → offer an update email),/status(re-orient from docs + git, flag stale docs), and/depfix(discover dependency work itself and apply the house update policy, knowing which projects are live-deployed). - A repeated preference becomes a line in the project-level instructions file — locale, auth defaults, "send one test before any bulk run".
- Repeated context — who the stakeholders are, what the product actually is, the tone rules for client emails — becomes a section in the per-project doc, so corrections update the file once instead of the session every time.
Do it yourself — the prompt
You don't need to write the analysis pipeline; the agent can run the whole audit on its own logs. Paste this into Claude Code (it mirrors what we ran today):
My Claude Code session transcripts live in ~/.claude/projects/ (one folder
per project, JSONL files). Without changing anything, mine them:
1. Extract every prompt I actually typed (type=="user", string or text
content; ignore tool results and <command> messages) into one corpus,
tagged by project.
2. Deduplicate, then analyse it and report:
- What do I use Claude for most? (ranked categories, counts, examples)
- Which tasks do I repeat in near-identical form? (with frequency)
- Which instructions, preferences and bits of context do I keep retyping?
- Which of those should become skills, and which belong in CLAUDE.md or
per-project docs?
3. For each recommendation, show the evidence (verbatim quotes + counts)
and rank by frequency x effort saved.
Then propose a step-by-step plan to fix them one at a time, and wait for
my go-ahead before changing anything.
Two notes from running it for real. First, insist on the evidence — counts and verbatim quotes — or you'll get plausible-sounding categories instead of your actual habits. Second, do the fixes one at a time with explicit approval gates; several of them touch files that many future sessions will read, and you want to check each one before it becomes canon.
The transferable takeaway
Your transcripts are already sitting on disk, and they are a ranked backlog of what to automate next. Extract your prompts, count the repeats, and promote the top offenders: sequences into skills, preferences into instruction files, context into per-project docs. An hour of mining bought us back the ten minutes of re-teaching we were paying at the start and end of every session — and it compounds, because every correction now lands in a file instead of evaporating with the scrollback.
Enjoyed this? Get Hurricane Signal
Field notes on building real things with LLMs — occasional, practical, no hype.