I Made Claude Read Every Prompt I Ever Typed at It

I Made Claude Read Every Prompt I Ever Typed at It

Everyone has advice about how to use Claude. Prompt like this, delegate like that, never let your context get long. Almost none of it is grounded in anything but vibes — including, until yesterday, mine.

But Claude Code keeps receipts. Every prompt you have ever typed sits in ~/.claude/history.jsonl with a timestamp and a session id. Every session transcript — every tool call, every model that answered — sits next to it. Mine held 27,939 prompts across 3,183 sessions over 210 days. About 133 a day, every day, for seven months. That's not a usage log. That's a longitudinal study of one heavy user that nobody had bothered to read.

So I did the obvious recursive thing: I asked Claude to analyze how I use Claude, and to distill whatever actually works into a skill that can configure someone else's Claude to work the same way.

Six agents, one evening

The pipeline was deliberately boring. First, plain greps and a Python pass extracted event datasets from the raw telemetry: all 354 manual /compact commands with the four prompts before and two after each one; all 1,004 prompts containing my orchestration keyword; a time-stratified sample of substantive prompts; the full /model switch timeline; per-model message counts across 3.7 GB of transcripts.

Then a workflow fanned five analysts out in parallel — compaction, delegation, prompting style, model selection, planning — each reading its own dataset, each forced to return structured findings with evidence. A sixth agent synthesized. Total cost: 365k tokens and about three and a half minutes of wall clock.

Here is what they found, in ascending order of how much it changed how I work.

Finding 01 — Compaction is a combat maneuver, not housekeeping

I assumed I compacted the way the docs imply you should: tidily, at the end of things. The data says otherwise. My compacts land everywhere in a session — 18% deep, 55% deep, 89% deep — and work continues for ten to fifty prompts after almost every one. Marathon sessions of 100+ prompts routinely contain two or three compacts, minutes apart, partitioning one long fight into separate problem domains: infrastructure, then deployment, then testing.

The triggers cluster into three shapes:

• Stuck loops. The same error pasted three times, the same problem restated twice — compact, because the context itself has gone stale and is now arguing with reality.
• Domain boundaries. The infra fire is out and feature work starts — compact so the new problem doesn't inherit the old problem's debris.
• Post-milestone. Right after "commit and push," before whatever's next.

And the companion stat that reframes everything — my session-hygiene commands over 210 days:

I resumed sessions 724 times and cleared them 164. Context is an asset. You don't throw it away; you prune it mid-fight and keep going.

Steal this: Compact when you're stuck in a loop, at domain boundaries inside long sessions, and right after milestones. Never mid-debug with live error context. And resume long sessions instead of starting over — a 4:1 resume-to-clear ratio is what heavy throughput actually looks like.

Finding 02 — Delegate the fan-out. Keep the single thread.

Over seven months I invoked multi-agent orchestration 1,004 times — plus 541 scripted workflows and 1,184 individual subagent dispatches. Roughly half my high-effort work runs parallelized. But the pattern in what gets delegated is sharper than the volume: orchestration fires on fan-out, and only fan-out.

Three or more independent streams. Gap-analysis-then-close-the-gaps loops that repeat until nothing new surfaces. Exhaustive audits. Cascading multi-system failures where no single context can hold the whole fire. Those get the swarm. A single coherent edit never does — splitting one edit across agents isn't delegation, it's overhead cosplaying as parallelism.

The delegating prompts share one more property: they almost always carry a proof demand rather than a step list. Not "do these five things" but "close every gap and prove it end-to-end, live." Scope plus gate, hands free.

Steal this: Orchestrate when work decomposes into 3+ independent streams, when you're iterating discovery→fix loops, or when a crisis spans systems. Give each stream an owner and a gate that can fail. Stay solo for anything single-threaded.

Finding 03 — Plans are documents, not a mode

Here's the one that surprised me most. Claude Code has an interactive plan mode. In 207 sessions on my main project, I triggered it 12 times. Meanwhile there are 231 written plan files in my plans directory.

The distinction matters. Interactive planning evaporates when the session ends. A plan document persists, gets linked from memory, and gets revisited across three, four, five sessions as phases ship. Mine converged on a stable anatomy:

1. Owner decisions locked at the top — trade-offs answered once, so no future session re-litigates them.
2. A verified-current-state audit — what exists, what's dark, what's theater — before any phasing.
3. Phases that each close with a live-provable gate. Not "tests pass." Things like "the provider's balance rose by exactly the computed amount, once, and a replay is idempotent." A gate that can fail, phrased before the code exists.
4. Updated in place as a living document: ✅ SHIPPED + LIVE-PROVEN (date, commit).

Steal this: Anything multi-phase gets a written plan file: decisions locked → current state audited → phases with live gates → updated in place. One-liners and clear-scope refactors get nothing. The plan document, not the planning session, is the artifact.

Finding 04 — Two models is the whole game

I had access to four models. The message counts say I effectively use two.

Haiku: six messages in two hundred thousand. Sonnet: trialed seriously for eleven days — eighteen thousand messages — then quietly abandoned.

Opus is the workhorse — roughly 70% of everything, the model the volume runs through. Fable got adopted the day it shipped and settled into the frontier slot: architecture, root-cause, security review, supervising orchestration. The workhorse-plus-frontier pair covered the whole trade space and the middle tier bought nothing. (Haiku does earn its keep inside orchestration, running mechanical subagent stages — just never as the interactive driver.)

The switching data has a morality tale in it too. July 4th: twelve model switches in eighteen hours, thrashing between limits, no proactive checks. July 5th onward: rate-limit checks before big runs, and switching settles to a calm rhythm of once every 4–8 hours. Same person, same workload. The difference was checking the gauge before the tank hit empty.

Steal this: Pick a workhorse and a frontier model; ignore the middle. Route by effort — frontier for architecture, root-cause, and review; workhorse for volume. Check your usage limits before starting big work, and treat more than one forced switch every two hours as a signal to re-plan the session, not push harder.

Twelve behaviors, one installable skill

The synthesis agent boiled the five analysts down to an operating doctrine — twelve behaviors, each with a when-trigger, a what-to-do, and the telemetry that earned it a slot:

1. Proof in the ask — state the outcome and how it's verified, in the same prompt. Never steps alone.
2. Live gates — a check that can fail: real round-trips, positive assertions. Green ≠ done.
3. Root cause over workaround — refuse fallbacks by default; unavoidable ones go in a debt ledger, dated.
4. Plan documents — multi-phase work gets a persistent file: locked decisions, audited state, gated phases.
5. Indexed memory — program state, trap warnings, standing directives. Mark refuted diagnoses REFUTED — don't delete them.
6. Orchestrate fan-out only — 3+ independent streams, gap-loops, sweeps, crises. Never split one coherent edit.
7. Tactical compaction — stuck loops, domain boundaries, post-milestone. Resume relentlessly; rarely clear.
8. Effort-tier model routing — workhorse for volume, frontier for hard reasoning. Check limits before the 429 does.
9. Boundary-first framing — say what you won't own before what you'll build. Prohibitions outlive feature lists.
10. Speed over polish, never over proof — typos are free; unproven claims are not. Ship the verified core, iterate live.
11. Consolidate sprawl on sight — two systems doing one job is an active hazard. Flag it, merge it, or ledger it.
12. Self-skeptic pass — before "done": name one concrete weakness or untested assumption. Fix or flag it.

Then I packaged the doctrine as a Claude Code skill: point it at anyone's machine and it inspects their setup, then non-destructively installs the rules file, a plan template, and memory scaffolding. The installer is live-tested — eleven checks across a fresh machine, an existing setup it must not clobber, and a double-run proving idempotency. 11/11.

What doesn't transfer

Three caveats, stated plainly because the doctrine itself demands it. The fleet doesn't transfer — my dispatch ladders and agent mesh are mine; you map the principles onto whatever tools you have, even if that's just the built-in agent primitives. My prompting voice doesn't transfer wholesale — the skill installs the structural skeleton (outcome plus proof standard in every ask), not one person's style. And the model-routing rules are correlational — the telemetry shows when I switched, not always why. That last one is exactly the kind of untested assumption behavior #12 requires me to disclose, so: disclosed.

Your telemetry is already on disk

This whole study cost one evening and 365k tokens, and the raw material was sitting in a directory I'd never opened. Yours is too:

wc -l ~/.claude/history.jsonl
du -sh ~/.claude/projects/<your-project>/

Count your compacts. Graph your model switches. Find out whether the habits you think you have are the ones the log shows. Then hand the transcripts to the tool itself and ask it what actually works — because the most interesting code reviewer your workflow will ever get has been sitting in the loop the entire time, taking notes.

Go find out who you actually are when you talk to your computer.

---

Method: inline extraction over history.jsonl + 207 session transcripts (3.7 GB), then a 6-agent workflow — 5 parallel analysts (compaction · delegation · style · models · planning) + 1 synthesizer. 365,357 tokens, 3m 27s. Counts exact.