The 5 levels of Claude Code for customer insights — and how to climb to the next

I was in London this week running a Claude Code insights workshop at Circus Experimentation conference. A few people reached out to me afterward. One had five solid skills she’d been running for months. Two others had installed Claude Code for the first time just before our workshop. They asked me, in slightly different words, mostly the same thing:

“What would get me to the next level - what am I missing that would double the ROI I’m getting from Claude Code?” → That’s this edition.

I’ve been mapping where teams I work with sit on the Claude Code learning curve, because I keep watching smart people stall in the same places for a painfully long time.

I put together a self-diagnostic plus one specific next move from each level. Most teams stuck at levels 1 to 3 think they need to develop more Claude Code skills. They don’t. They often need different infrastructure.

The jump to L3 is where work gets noticeably faster. The jump to L5 is where it gets so trustworthy, you can actually ship what agents delivered without triple-checking every line of every output.

Most people aren’t ready for Level 5 yet, but I want you to see where you are now, where this all goes, and how you might get from here to there.

Let’s get into it —

• 📍 New from me — June course cohort enrolling

• 🏕️ The 5-level ladder — diagnose where you are, with the smallest next move at each rung

• 🌰 Trail mix — adjacent reads worth your week

Let’s get into it —

• Okay, why should you even care? Because the last cohort shipped 16+ workflows together: usability coders, contradiction-flagging interview analyzers, hybrid-codebook theme coders, GDPR PII redactors, most importantly - multi-agent discovery pipelines that run reliably 95% on their own.

  → Next round: June 8–19. Sign up here

🏕️ BASE CAMP

The level you’re stuck at is the one whose stuck-here signal sounds embarrassingly like you. 🫣 Under each level I’ve added what’s still missing between you and the next rung. Based on what, you ask? Based on working with 200+ individuals learning to use Claude Code since the beginning of this year.

Most people overshoot by one rung when they self-diagnose. If you’re hovering between two, pick the lower one. I’m not judging! ✌️ I always overshoot, too, but mastering basics does matter for moving faster later.

Now the details —

You’ve written a few skill files. They seem to produce decent output. You’d recommend Claude Code to a friend for the shiny skill-to-fast-documentation use cases.

But switch the dataset, change the research question, or scale up, and something breaks.

The signal you’re stuck here: every new project still gives you a feeling you’re starting from scratch. The skills you created before work, but only with edits to fit your latest project.

What’s missing between L1 and L2:

• A useful hierarchy of not-excessively-long CLAUDE.md files across global, project, and subfolder — and a clear sense of which information lives at which layer

• The difference between memory (cross-session) and context (this session), and when to use each

• A project setup so Claude orients itself before you type the first message

• Understanding of how to build skills for use across projects without rewriting them every time

🪜 The smallest next move:

Start with the hierarchy of CLAUDE.md files on different levels of your folder structure. It’s half a day of work for many. But after that, every session starts properly oriented and you’ll never paste context into prompts again.

〰️

You’ve built CLAUDE.md files at every level - and they’re pretty darn good! You “cd” into a project folder and Claude already knows the product, the customer segments, the decision on the table. There was zero copy-pasting context this week.

This is where Claude Code stops feeling like a tool and starts feeling like a colleague who knows its stuff.

The signal you’re here:

you have skills, but you run them one at a time. You’re the orchestrator of a bunch of on-demand agents but you still have to tell each next step to run.

What’s missing between L2 and L3:

• Slash commands or agents as orchestrators — one command running multiple skills in sequence

• Sub-agents — when to launch them, where parallel work most earns its place

• Output files at the right steps so you can audit a pipeline and iterate faster

• Passing context between steps without losing the threads that matter

• What a workflow worth packaging looks like

🪜 The smallest next move:

Wrap your most-repeated workflow in a slash command that orchestrates multiple skills to run in the right order (without you triggering them). After that, one command replaces an hour or more of manual coordination.👇

〰️

You’re not running skills manually. You type one command and a full pipeline runs: multiple skills, some sequential, some parallel via sub-agents. Output files at every step so you can audit what happened. Verification built in and an agentic process that knows when to stop to get your input.

One command. Multiple agents. And a real audit trail neither you nor Claude can ignore.

The signal you’re stuck here:

Workflows run, but Claude burns tokens wandering through your connected sources, or your team can’t reproduce your results.

What’s missing between L3 and L4:

• MCP scoping — writing tool instructions before you connect a source, not after

• The distinction between your personal Claude Code setup and a teammate-shareable skill

• Packaging conventions — naming, versioning, what belongs in settings vs. settings.local

• Knowing how to systematically and rapidly test and iterate every workflow you create - with Claude - to get to reliable workflows you’d let run on their own

🪜 The smallest next move:

Connect sources via MCP, scoped with tool instructions that prevent them from running wild through your data and target retrieval of the right data fast. (Cuts the token burn fast, too).

〰️

MCPs are connected and scoped. Claude isn’t wandering aimlessly through your sources. Your best workflows are packaged so your team can run and test the same skills, the same orchestrators. The same standards are applied every time.

The signal you’re stuck here:

You create skills and multi-skill workflows, but it feels like it takes forever to make improvements to them yourself. Workflows look good when YOU run them, but break for teammates, and you don’t know why until they tell you.

What’s missing between L4 and L5:

• Eval design — choosing what to measure (quote fidelity, finding stability, drift across data shifts)

• Multi-run testing on the same input to surface where Claude actually varies

• LLM-as-judge patterns, and the places they break

• Cross-input consistency — does the same skill behave on a new dataset the way it did on your seed?

• Knowing when output is good enough to ship vs. needs another pass

The smallest next move:

Run your most-used skill 5 times on the same input, then look at what shifts between runs. It takes a couple of hours at most (use a small amount of data, not the whole lot). The goal: stop guessing if your workflows are reliable and figure it out systematically. Like this 👇

〰️

You don’t just build workflows. You test them rigorously here. You know which skills produce stable findings and which lean in the wrong direction as soon as the data changes. You’re not handing a workflow to your team because it looked good when I ran it. You’re handing it off because you have evidence it works repeatedly.

L5 is where the workflow goes out the door without a 2am voice in your head wondering if a something got fabricated or dangerously skewed three runs back.

The leap from L1 to L5 isn’t one giant project. It’s a bunch of key steps, but each can be small enough to do in a few weeks if you target the right improvements. The reason most people stall isn’t intellectual capability, or even “terminal allergy” (yes, I realize you might be allergic to hanging out in a black chat box all day!). The biggest blocker to getting this right is this: most people are overcomplicating things.

Getting from L3/4 to L5 requires:

• Focusing on the basics of experiment design to test consistently

• Building basic evals - rubric-based measurement of what comes out of your workflows over time

• Having consistent test data sets and ideally a golden set that has the “correct” answers you can compare Claude’s answers to

• Having the key pieces from L1→L4 in place before you start running evals (CLAUDE.md files, rules files and other context files, skills with a reasonable chance of delivering good work, etc).

Getting from L1→L3 can be done in 2 weeks. Going L3→L5 depends entirely on how committed you are to thinking clearly and testing systematically.

A few of the coolest things I have found and used obsessively:

• Feynman — open-source AI research agent — a CLI that ships something like research skills as a standalone product. Useful reference at L4 when you’re thinking about how to package your own workflows for others to run. But it runs outside of Claude as it’s own CLI. Pretty incredible if you want to do a deep review of all academic papers on a topic and get a summary back that’s legitimate.

• Karpathy’s LLM Wiki — If you’re someone asking “how to build a repository or continuous knowledge system” in Claude Code, this might be your answer. It’s a setup for AI-maintained, compounding knowledge bases. Imagine: Your insights-person curates, then the LLM keeps the wiki current and flags contradictions along the way.

• tropes.fyi — AI writing tropes to avoid — ~40 AI-writing patterns in a markdown file, formatted to drop straight into a CLAUDE.md or reference when creating your next writing skill. Catches problematic defaults before they get sent out and make clear you’re letting AI write everything for you. 🙃

Keep moving,

— Caitlin