Case study
July 2026
Shipped and taught
Teaching a company to use Claude.
A ten-page internal curriculum and a live workshop that moved an organization from writing emails in Claude to building skills, projects, and scheduled tasks. Written for sales and ops, no technical background assumed.
- Pages in the guide
- 10
- Companion PDFs
- 8
- Revisions
- 65
- Rollout
- Company-wide
Context
The company had Claude. People were using it to write emails and summarize threads, which is roughly a tenth of what it does and none of the part that compounds.
Nobody was going to close that gap by reading vendor documentation. Not because the docs are bad, but because they answer a different question.
The problem
Feature documentation explains what a feature is. It does not tell you which of four overlapping things to reach for, and that is the only question a new user actually has. Skill, project, or just a prompt? Project, or upload a file? Schedule it, or trigger it?
Vendor docs also cannot afford to be honest about limits, and an internal guide has to be. If someone builds a rollout plan on a capability that does not exist yet, the whole programme loses credibility, and it loses it in a leadership meeting.
What I built
A curriculum rather than a reference. Ten pages in the internal knowledge base, around 7,400 words, plus eight companion PDFs and a deck I delivered live in the company's internal learning series. The written guide is the thing you return to; the session is where people built their first skill.
Everything hangs off one mental model, stated in the introduction and restated as the final line of the final page: connect your tools, give Claude the context in a project, teach it the way we work with a skill, put the recurring work on a schedule. Chat when you are in the flow, delegate when you want it handled.
The three core how-to pages use the same four beats in the same order: what it is, how to tell it apart from the alternatives, build your first one, then three ready-to-use examples drawn from our actual business. Page two teaches you how to read pages three and four.
What made it land
- Decision tests, not feature lists
- Every overlapping concept gets an explicit disambiguation section. The reader leaves knowing which tool to pick, which is the thing feature documentation never tells them.
- Ten gotchas, all real
- Custom skills are per-user with no org-wide push. Project knowledge is retrieval-based, so a tidy project beats a dumping ground. Scheduling is cadence-based, not event-triggered, and I said to keep that distinction honest in any leadership pitch.
- Configs you can paste
- A complete working skill file with its scoring rubric, project instructions written as role, always, and never, and a full scheduled prompt. Nine starting configurations in total, all specific to our business rather than generic.
- A prompt that interviews you
- The single most reused thing in the guide: a meta-prompt that makes Claude ask you questions three at a time before it drafts your skill, so the skill ends up encoding what you actually do.
- A rollout you can finish
- One shared project, one shared skill, one schedule per rep. That is a complete loop of shared context, shared method, and personal rhythm, and it is half a day of setup rather than a project plan.
Read it
All ten pages, running here. Use the sidebar to move between them, and the Download links to open any of the eight companion PDFs. Colleague names, one customer account, and an internal service URL are blacked out; those redactions are flattened into the page rather than laid over it, so nothing is recoverable underneath. The screenshots that lived on the design pages were stripped from this export.
Loading the live artifact…
Detail
The set, top to bottom. Ten pages that read in about forty-five minutes end to end, sequenced so the concepts arrive before the how-tos that depend on them.
The four-beat template in use. What a skill is, the decision test against the alternatives, then a complete working skill file you can copy.
Outcome
Presented to the whole company, and people are using it to get better at Claude. The guide is maintained rather than published and abandoned: sixty-five revisions across the ten pages so far.
The compounding effect is the point. Everything else I have built here, the Command Center, the scheduled briefs, the design system work, depends on colleagues knowing what a skill or a project is. Enablement was not a side project alongside the building. It was the thing that made the building useful to anyone but me.