Record a Skill: teaching Claude a workflow by doing it once on screen

On July 21 Anthropic shipped Record a Skill in the Claude Cowork desktop app, available on Pro, Max and Team plans. The mechanic is simple: you record your screen while you do a task, you narrate why you are making each decision out loud, and Claude turns the demonstration into a reusable Skill that lands in your library and runs again on demand. No prompt engineering, no Markdown, no SKILL.md to hand-write. Dataconomy covered it on July 22 and the framing everywhere was learning by demonstration, which is the right frame, because the interesting part is not the recording. It is what the narration captures.

Why narration is the product

Every Skill I have written by hand, for Claude Code or otherwise, has the same weakness: I document the mechanical steps and I forget the judgment calls. Which of the three exports do you pick when the report is late? When do you skip the reconciliation step? That knowledge is tacit; the person who has it cannot easily write it down, and they will not sit through a specification interview. A recording with narration sidesteps that. The screen shows the mechanical sequence, the voice explains the branch points, and the model gets both. The July 23 brief calls this bypassing the specification bottleneck, and that is exactly what it is.

For anyone doing AI enablement inside companies this is the fastest route I have seen from a subject-matter expert to a working automation: record once, run repeatedly. The undocumented processes that live in one person's head, the ones that break when that person goes on holiday, are the target.

A Skill written from a spec captures what the process is supposed to be; a Skill recorded from a demonstration captures what it actually is.

Governance: the recording is a data export

Here is where the excitement should slow down. A screen recording of a real workflow contains everything on that screen: customer names in the CRM, ticket numbers, internal URLs, whatever was open in the next tab. The brief flags trust around screen recording, data boundaries and governance, as the adoption blocker, and I agree. Before a team records anything it needs answers to three questions. Where does the recording go and for how long? What does the generated Skill retain from the recording, literally, in its instructions? Who can run the Skill, and can it run against production data by default? I treat the recording as a data export and apply the same review I would apply to a database dump leaving the building.

The same logic that makes permission modes and MCP tool scoping worth thinking about applies here: a Skill is an executable artefact, and one produced from a demonstration is an artefact whose author did not review every line of it. Someone has to.

What makes a good recording

• Use a sandbox or demo account. Never record against production on the first pass.
• Narrate the why, not the what. The screen already shows the clicks.
• Say the exceptions out loud: if the total is over ten thousand, stop and ask.
• Keep it to one process. Long recordings produce vague Skills.
• Review the generated Skill before saving it; treat that review like a code review.
• Version it. When the process changes, re-record rather than patch the text.
• Start with the boring, low-risk workflows. Expense categorisation before customer refunds.

Where I would use it first

The best candidates are the recurring internal chores that nobody owns: monthly report assembly, ticket triage rules, the onboarding checklist that is really a person's memory. They are frequent enough to pay back the recording, low-stakes enough that a wrong branch is recoverable, and tacit enough that nobody has written them down. The worst candidates are anything touching money or customer data on a first pass, because that is where the governance questions above have no good answer yet.

The honest limitation

I have not measured how well generated Skills survive edge cases the recording did not cover; the launch coverage describes the mechanic, not a reliability study. And the feature lives in Cowork on paid plans, which means the workflows most in need of capture, the messy ones on shared accounts, are precisely the ones with the hardest data-boundary story. Record the boring ones first and measure before you trust the rest.