Anthropic shipped Record a Skill into Claude Cowork on 21 July 2026. You hit record, do your job while talking through it, and Claude turns the walkthrough into a Skill it can run again. No prompt engineering, no specification document, no developer sitting in a requirements workshop trying to infer what you meant.
OpenAI shipped a comparable Record and Replay in the Codex desktop app five weeks earlier, on 18 June. Two labs converging on demonstration-based capture inside a single product cycle is the signal worth paying attention to. The interface for teaching software is shifting from writing instructions to showing the work.
That shift is real and it matters. It is also being oversold, and the gap between what a recording captures and what a production system needs is where the interesting problems live.
What the feature actually does
Strip away the coverage and the mechanics are specific.
| Detail | |
|---|---|
| Shipped | 21 July 2026, announced 22 July |
| Where | Claude desktop app, in Cowork. Anthropic’s help documentation specifies Mac for recording |
| Plans | Pro, Max, and Team, with admin provisioning on Team and Enterprise |
| Recording length | Around 10 minutes |
| Captures | Screen activity, mouse clicks, typing, and voice narration together |
| Produces | A Skill: a SKILL.md file with YAML frontmatter (name, description) and a markdown body, optionally bundling scripts and resources |
| Retention | Video and audio are not retained. Screenshots persist inside the Cowork task and are deleted when the task is |
The output format is the part most coverage skips, and it is the part that determines everything downstream.
A Skill is a folder containing a markdown file. Claude loads it by progressive disclosure: the name and description sit in context at startup so Claude knows when the skill is relevant, the full body loads when it looks applicable, and any linked files load only as needed. Skills can also bundle executable scripts that Claude runs as tools, which is how you get deterministic behaviour for the parts that should never be improvised.
So the artefact is human-readable, diffable, and reviewable. You can open it, correct it, put it in version control, and require a second pair of eyes before anyone runs it. That is genuinely good news for governance, and it is a better foundation than the opaque recorded macros that RPA vendors shipped for a decade.
The idea is fifty years old, and that is the point
Programming by demonstration is not new. Systems that generalised from user demonstrations date back to 1975. Allen Cypher’s Watch What I Do (MIT Press, 1993) documented eighteen implementations. Henry Lieberman’s Your Wish Is My Command followed in 2001. A generation of researchers tried to let end users build programs by showing rather than coding.
Almost none of it reached the mainstream, and they all broke on the same rock: generalisation. A demonstration shows one path through a task. Turning that single trace into a procedure that handles the case you did not demonstrate was the unsolved problem.
What changed in 2026 is not the concept. It is that a language model can listen to you say “I export as CSV because our importer rejects Excel files” and encode the rule, not just the click. Narration carries the intent that mouse coordinates never did.
That is a real advance. It is also not a solution to generalisation. It is a much better starting point for a problem that remains open.
Where recordings stop being enough
A recording captures the run you performed. The normal transaction, the expected document format, the usual decision path, the standard output. Call it the common 80%, though one practitioner maintaining 252 procedure files puts the figure closer to half, and argues the missing half is the half that matters.
What a single take leaves out:
- Decision rules behind the actions, unless you narrate them explicitly
- Exception handling for missing data, conflicting records, and malformed input
- Activation boundaries, meaning the cases where the skill should refuse to run
- Data validation and reconciliation against a source of truth
- Retries and recovery when a system is down mid-process
- Sample-specific detail that will not generalise, like the folder name and record ID from your demonstration
There is a further reason the remaining portion is hard, and it is structural rather than a matter of coverage.
A recorded skill is an instruction package, not a script. Claude interprets it. The same skill, given the same input, can take a different path on a different run. That is categorically different from robotic process automation, where the failure mode is brittleness (the button moved, the bot broke, you find out immediately). Here the failure mode is drift, and drift is quiet. A skill that handles 97% of invoices correctly looks like a working skill right up until the 3% turns into a reconciliation problem three weeks later.
Everything on the standard production checklist follows from that one property. API integration and secure authentication, complex business rules, exception and escalation handling, validation and reconciliation, reliable retries, logging and monitoring, auditability, and human approval at the decision points that carry consequence. None of that is pessimism about the feature. It is the cost of putting a probabilistic component into a deterministic business process.
Demonstration does not replace software engineering. It gives software engineering a far better brief. Instead of reconstructing a workflow through meetings, stale process documents, and assumptions, a developer starts from a recording of how the work is actually performed and where human judgement enters. Anyone who has run a requirements workshop knows how much that is worth.
The security problem nobody has priced in
Here is what makes this different from every other AI feature your organisation has evaluated: it asks employees to record their screens while doing real work.
A screen recording captures everything visible, not just the steps Claude needs. Open email threads. Customer records. Internal dashboards. A password manager someone forgot to close. A colleague’s name in a Slack notification. Commercially sensitive pricing in a spreadsheet on the second monitor.
Anthropic’s own help documentation tells users to avoid displaying passwords or private conversations during a recording. That guidance is correct and it is also entirely manual. There is no automated credential masking. The control is a human remembering to close windows.
Three more specifics belong in any assessment.
Skills are a software supply chain. Because skills can bundle executable code and are distributed as ZIP files, a skill shared between colleagues is an executable artefact of unknown provenance. Anthropic’s guidance is explicit: install skills only from trusted sources, and audit anything else for malicious instructions, data exfiltration paths, and unexpected network access. If your organisation starts trading skills over chat, you have created an unmanaged package ecosystem inside the business.
Computer Use sits outside the permission model. Security researchers analysing Cowork report that Computer Use controls the desktop directly and does not pass through the same permission checks that gate other Cowork tool calls. A prompt injection reaching that path can interact with any application on the machine. Cowork does have real defences (VM sandboxing, permission prompts, configurable network egress controls, per-application permission for computer use), but the desktop control path is the one that deserves specific attention.
The tier problem is the one I would raise first. Record a Skill ships on Pro and Max. Those tiers have essentially no organisational security controls. Team provides basic admin controls but arrives with permissive defaults, Chrome enabled and connectors open, that need remediation on day one. Enterprise is the only tier offering SSO enforcement, SCIM provisioning, custom role-based access control, tenant restrictions, and group-based policy.
Read that in sequence. The capability that captures your most sensitive process knowledge is most freely available exactly where your governance is weakest. An employee with a personal Pro subscription can record a production finance process this afternoon, and nothing in your stack would know. This is shadow AI with a screen recorder attached, and it is the reason a policy needs to exist before the pilot does.
Controls to put in place before anyone records
Nine questions, answered in writing, before the first recording:
- What information may be recorded, and what is prohibited outright
- Which applications and environments may appear on screen, with a preference for test environments over production data
- How credentials and sensitive fields are masked, given that no automated masking exists
- Where screenshots and generated skills are stored, who can retrieve them, and what the disposal path is (deleting the Cowork task removes its screenshots)
- Who can create, edit, approve, and execute a skill, as four separate permissions rather than one
- Whether a skill acts or only recommends. A skill that drafts a journal entry for review is a fundamentally different risk object from one that posts it
- How changes are versioned, tested, and reviewed. The
SKILL.mdformat makes this tractable, so use it - How execution history is logged for audit, including which skill version ran against which transaction
- Where human approval remains mandatory, defined by consequence rather than by convenience
Add one more that is easy to miss, because every item above governs the recording or the execution while this one governs the asset over time:
Every skill needs a named owner and a review date. Applications change. Policies change. Business rules evolve. Exceptions surface that nobody demonstrated. A skill recorded once and never revisited is a process document that keeps executing after it stopped being true, which is a worse failure than a process document that merely goes stale in a drawer.
Test each skill against three cases before trusting it: a normal input, an imperfect input with missing or conflicting data, and an out-of-scope request it should refuse. Only the third one tells you whether the activation boundary holds.
A recorded skill is an organisational asset
The framing that matters most: this is not a personal productivity shortcut.
A recorded skill contains process knowledge, encoded business rules, and often genuine intellectual property. It represents how your organisation actually does the work, which is frequently different from and better than the documented procedure. That asset deserves the same treatment as any other: ownership, version control, review cycles, access control, and a retirement plan.
Anthropic has built for this. Team and Enterprise admins can provision skills to all users through administrative controls, which is the difference between a skill library and a folder of personal shortcuts. Use it.
The operating model this points to
Four capabilities, each doing work the others cannot:
| Layer | What it contributes |
|---|---|
| Demonstration | Captures how the work is actually performed, including where human judgement is applied |
| Software engineering | Makes it reliable, connected, and deterministic where determinism is required |
| Security engineering | Protects the systems and the data, from recording through execution |
| Governance | Keeps the capability controlled, accountable, versioned, and aligned to policy |
For organisations working to a formal framework, this maps onto the EC-Council Adopt, Defend, Govern structure directly, and the governance layer aligns to NIST AI RMF and ISO/IEC 42001 obligations you may already carry. The point is not the framework you choose. It is that demonstration sits inside a system of controls rather than replacing one.
What I would actually do
If you lead technology or risk at an Australian organisation, three moves this quarter:
Find out if it is already happening. Pro and Max are consumer subscriptions. Ask, do not assume. The answer is more often yes than leaders expect.
Write the recording policy before you run the pilot. Nine questions above. It is a short document and it is much cheaper than the incident.
Pick one genuinely boring process and run it end to end. Something repeated, fully visible on screen, checkable against a known-good output, bounded in its exceptions, and safe to demonstrate without exposing customer data. Record it, review the generated skill, engineer the exceptions, wire the approvals, then measure it against real transactions for a month before extending the pattern.
The opportunity here is real. Subject-matter experts can now hand their process knowledge to a system directly rather than through a translation layer of documents and meetings, and that removes a genuine bottleneck in enterprise automation. But the recording is the beginning of the engineering work, not the end of it. The organisations that get value from this will be the ones that can identify the right processes, demonstrate them clearly, engineer the difficult exceptions, and govern the resulting capability responsibly.
Prompts alone will not build it. Neither will recordings.