In a previous post, I wrote about building a Docker Compose dev environment using Claude Code — and how it took 15 commits across 10+ sessions because the first session produced everything as one intertwined system instead of incrementally. That post told the story. This one is about the process — how I used Claude Code itself to analyze session logs, identify failure patterns, and turn them into targeted fixes.
The Session Logs Are There
Claude Code stores conversation transcripts as JSONL files in ~/.claude/projects/. Each session is a complete record — every user message, every tool call, every file read and edit. I had months of history across 8 repos, totaling hundreds of sessions.
I wouldn't want to read through all of that manually. But Claude Code can.
Step 1: Gather Evidence
I started a new session and pointed Claude at the session log directory. The prompt was roughly: "look at conversation history to see the many iterations it took to get the dev-environment right. Dive into what went wrong."
It launched parallel agents to:
- Walk the full git history (15 commits) and summarize what changed in each
- Extract all user messages from the largest session files
- Read CLAUDE.md files across all sibling repos to find related patterns
From the session logs, it found concrete evidence: 41 user messages in the main session, at least 7 redirections where I interrupted mid-execution, 5 explicit "stop and simplify" requests. It identified the specific things that were over-engineered (custom shell script, shared Dockerfile, env file layering, port offset arithmetic) and mapped them to the commits where they were eventually removed.
Step 2: Find Cross-Repo Patterns
A single bad session might look like an isolated mistake. So I asked Claude to look across other repos for the same pattern.
It found it. In a different repo, Claude had delivered a full-stack feature — backend schemas, validation endpoints, frontend wizard, form integration — all in one pass. My response in that session: "This is a very big feature. Perhaps we can iterate implementation a bit, leave parts blank or mock then fill them in? It's hard to plan all the details at once." Same problem, different project.
Step 3: Categorize the Failure Modes
Claude categorized the user messages it extracted — redirections, corrections, explicit rejections, "why does this exist?" questions. This turned vague dissatisfaction into a ranked list of specific, recurring failure modes. Not "Claude is too verbose" but things like "when asked to build X, Claude builds the most thorough version of X instead of the simplest."
Step 4: Turn Patterns into Rules
This is where the analysis becomes useful. Each failure mode maps to a specific, implementable fix. The key is to write rules that are concrete behavioral changes, not general principles. "Prefer simplicity" doesn't change behavior. "Propose a sequence of increments, implement the first one, check in before the next" does.
The rules went into my global CLAUDE.md — the config file that Claude Code loads into every conversation. They're untested — I don't know yet if they'll change behavior enough. But they're grounded in specific documented patterns, not vibes.
If You Want to Try This
The ingredients are simple: the session logs exist, Claude Code can read them, and you probably have enough history to surface patterns. The steps generalize:
- Point Claude at session logs for a project where you felt like you fought the tool
- Ask it to find cross-repo patterns, not just single-session issues
- Have it categorize user messages by type (redirections, corrections, rejections)
- For each failure mode, design a specific rule or workflow change — not a general principle
The output doesn't have to be CLAUDE.md rules. It could be hook scripts, skill definitions, per-repo instructions, or changes to how you prompt. The point is turning accumulated friction into targeted fixes.
In fact — I just started writing blog posts, and I'm writing them with Claude. These two posts took a fair amount of back-and-forth to get right. After a few more, I'll probably have enough session history to use this exact method to write myself a blog-writing skill.
Top comments (0)