Skip to content
Trevor J. Romack
Case studies

Case study

Claude Training Curriculum

Demonstrates

Turning vague tier names into testable competencies, then auditing a course catalogue against them.

Shipped
Lenses
  • Product & delivery (primary)
  • Applied AI
Stack
claude · claude-code · mcp · agent-skills
On this page

Overview

The organization had roughly 500 AI-tool licences across vendors and no learning path for any of them. A spreadsheet existed listing three desired Claude training levels — Intro, Advanced, and Claude Code. The cells under them were blank.

I volunteered to fill them. Not by picking courses first, but by writing down what a person has to be able to do to qualify at each level, getting those definitions approved, and only then auditing the course catalogue to find which courses actually delivered them. The curriculum was approved as proposed and is still the recommended path.

The method is the one I use on systems: write down what qualifies, then check the candidate against it and report the gap. Here the candidate was a course catalogue and the subject was people.

The problem

Licences were available to anyone who asked, with no training, onboarding, or basic guidance on how to use the tool or why. Access was never the constraint.

The constraint was that “Advanced user” is a label, not a specification. Nobody could say what an advanced user could do that an intro user couldn’t, which meant nobody could be taught toward it, and nobody could claim to have reached it. A level with blank cells under it cannot be qualified against — and a catalogue of twenty-odd courses is not a path, it is a list.

Constraints

The tiers were given, not chosen. Three levels came from the program director’s spreadsheet. The job was to define them and find the route through, not to redesign the ladder.

Nothing is mandatory. The path is self-selected, with no requirement attached to any role. So it had to be worth choosing on its own, and short enough that choosing it was cheap.

Everyone is in scope. Business operations, sales, developers, project managers. The same three tiers had to make sense to someone in sales and to an application developer.

Build on the existing catalogue. Twenty-plus official courses already existed. Authoring new material would have been slower, would have dated faster, and would have duplicated work already done well.

The subject moves. The tooling and the catalogue both change on someone else’s schedule, which the design had to survive.

The three tiers

Each tier lists required courses — required to qualify at that tier — and recommended ones, which are suggestions. The prerequisite chain runs Intro → Advanced → Claude Code.

Claude Intro. Audience: everyone. About two to three hours. Required: Claude 101, and AI Capabilities & Limitations. Recommended: AI Fluency: Framework & Foundations.

Claude Advanced. Audience: power users, business and technical. About three hours. Required: Introduction to Claude Cowork, and AI Fluency: Framework & Foundations. Optional developer track: Introduction to Agent Skills, Introduction to MCP.

Claude Code. Audience: technical roles — application development, SQA, architects, infrastructure. About three hours. Required in sequence: Claude Code 101, then Claude Code in Action. Optional depth: Introduction to Subagents, Introduction to Agent Skills.

The overlap between tiers is deliberate. A course can be a suggestion at one level and a requirement at the next — AI Fluency is recommended reading for an intro user and a qualification for an advanced one.

Key decisions

Chose to define qualification before looking at a single course. The definitions went to the program director for approval first, with three questions attached: do these match what you envision, is any tier too much or not enough, and what am I overlooking. Choosing courses first would have produced a reading list that nothing could be checked against. The cost is a slower start — no recommendation could be made until the definitions were agreed.

Chose observable capabilities over topic coverage. Every tier is written as “a user qualifies when they can…” and then a list of things a person does, rather than subjects a course covers. The intro definition reads:

Can get real work done with Claude, prompt clearly, and knows when to trust vs. verify what it produces.

and qualifies a user who can “explain what an LLM is and isn’t, and where it’s unreliable,” “verify outputs and follow basic data/security hygiene for our environment,” and “judge when a task is worth delegating to AI.” The cost is longer lists and more to verify against, because each capability has to be found in a course or declared missing.

Chose to build on the catalogue rather than author material. Twenty-plus courses already existed and were maintained by the people who build the tools. The cost is a curriculum bound to someone else’s release schedule and coverage decisions.

Chose to leave most of the catalogue out. Each tier names only what its definition requires. The rest stays available for anyone going beyond the tier, but is not in the path. The cost is that a reader who wants more has to go looking for it, and the recommendation looks thinner than the catalogue it was drawn from.

Chose required and recommended as a real distinction. Required means required to qualify; recommended means a suggestion and nothing more. Keeping the line sharp is what makes a tier claimable at all. The cost is that the same course appears at two tiers with different force, which has to be explained rather than assumed.

How it’s verified

The definitions are the specification, and the audit is the check. With the three definitions approved, the next step was going through the catalogue course by course, asking of each listed competency whether a course actually delivered it, and flagging anything that no course covered.

That audit produced the finding worth keeping. Intro mapped cleanly — one course carries nearly the whole definition. Claude Code mapped to a designed sequence. Advanced did not map at all:

No single course covers all of “Advanced” by the current defined bullets. Will most likely have to be a curated bundle — potential for a short course we build ourselves that stitches these into one coherent path at some point.

So Advanced ships as a bundle rather than a course, and the gap is recorded rather than papered over with the closest available match. The internally-built course that would close it properly is named as the eventual fix, not claimed as done.

The curriculum was approved as proposed, without changes, and remains the recommended path for Claude users in the organization.

What I’d do differently

Define less, earlier. The first pass over-defined the tiers — more competencies per level than the level could carry, which made the audit harder and pushed a voluntary path toward looking like a certification. Trimming to what actually qualifies a person, rather than everything a person at that level might know, made both the definitions and the mapping usable.

Decide what completion would be measured by, at the start. Nothing about the programme’s effect was measured, and the moment to design that was while the definitions were being written, not afterwards. Even a self-reported completion field in the same spreadsheet would have turned “still the recommended path” into something with a number attached.

Limits

No learning outcomes were measured. No completion rates, no assessment, no before-and-after. The programme’s effect on how people work is unknown, and no adoption figure is attributable to it.

Qualification is self-reported. Nothing tests whether a person can do what their tier says. Someone completes the courses and says they have.

It is Claude-specific. Some of the intro material — what an LLM is and isn’t, where it fails, when a task is worth delegating — generalises to any assistant. Most of the rest does not.

It dates quickly. The catalogue and the tooling both move fast, and a curriculum built on someone else’s courses inherits their release schedule. A tier defined against today’s feature set needs re-auditing when the feature set changes.

Reach is unknown. Who the path did not get to, and why, was never established.

Notes

Internal work, so there is no public repository and nothing to run. Everything here is the design and the reasoning: the tier definitions, the audit method, and the recommendation. The organization is not named, and no internal system names, personal identifiers, or proprietary material are included. The courses named are Anthropic’s public catalogue.