1
1 Comment

AI can now record how you work and turn it into a reusable file

In some AI tools now, you can record yourself doing a task. You click around, type, and talk through what you are doing, and when you finish, the AI turns that recording into a reusable Skill. Instead of explaining how you do the same piece of work over and over, you show it once and save the process for later.

Anthropic added exactly this to Claude. While you record, Claude can see your screen, your clicks and your typing, and you can narrate the decisions you are making as you go. When you stop, it proposes a Skill that you can review, edit and save. It feels a little like training a new member of staff, except that the training itself becomes a file. (Anthropic Help Center.)

That is a bigger change than it first appears, because we normally think of a file as the result of work: the presentation, the spreadsheet, the design, the report, the code. We are now starting to make files that contain how the work gets done.

Workflows are becoming portable

The interesting part is that this is not one company's feature. OpenAI describes Skills as reusable workflows that can be shared and reused across tools. Google calls them external, swappable procedural memory. Microsoft supports the same structure in its Agent Framework and describes the format as an open one. Four companies, arriving at roughly the same idea inside a year.

Most of these Skills come down to a surprisingly ordinary file called SKILL.md. It is a Markdown document that explains what the Skill does, when to use it, and how to carry out the task, with scripts or reference files added when they are needed. Because it is plain text in an open format, the workflow can be read, edited, versioned and moved between tools like anything else on your computer.

Which means the method itself has become portable.

Before: your experience, you do the task, and a file holds the result.
Now: your experience, you show it once, a file holds the method, and an agent reuses it.

The result was always portable. What is new is that the method is too.

Four things we bundle together

Once you start thinking about work this way, it helps to separate four things that usually travel together when we say somebody is good at their job.

  • Knowledge. What you know
  • Context. What matters in this particular situation
  • Procedure. The usual way you do the work
  • Judgment. Knowing when the usual way no longer fits

AI has been getting better at the first three for a while. It can retrieve knowledge, hold far more context than it used to, and now carry a procedure around as a file that any agent can pick up. That makes the fourth one much easier to see.

Knowing when to intervene

There is already some evidence of this in the way experienced people work with AI agents.

Anthropic studied around 400,000 Claude Code sessions from roughly 235,000 people. In a typical session, humans made about 70% of the planning decisions, such as what should be built and what counts as finished, while Claude made about 80% of the execution decisions, such as which files to change and what to write in them. The more domain expertise somebody brought to the task, the more work they handed over per instruction. (Anthropic, How Claude Code is used in practice.)

A second study found something less obvious. As people grow more experienced with Claude Code they stop approving each individual step, roughly 20% of sessions run fully auto-approved among new users against over 40% among experienced ones. Yet those same experienced people interrupt it more often, not less: around 9% of turns against 5% for newer users. (Anthropic, Measuring AI agent autonomy in practice.)

Both studies are about coding, so I would not claim they describe every kind of work. But the pattern is worth noticing. Expertise did not disappear when the agent could do more, it moved. Experienced people handed over more of the execution precisely because they had a clearer idea of what they wanted, what finished looked like, and what it looked like when something was going wrong.

I have started thinking of that as exception judgment: noticing when the situation in front of you no longer matches the procedure closely enough for the procedure to be trusted.

Every job has these moments. The brief says one thing, but new evidence changes the problem. The usual approval process is fine until the risk is unusually high. The template is technically correct and clearly wrong for this particular customer. They are small decisions, and they are often exactly where experience shows up.

How to get better at it

  • Write down the normal way first. Pick something you do regularly: reviewing a design, preparing a report, answering customer feedback, publishing a post. You need to know what normal looks like before you can notice yourself leaving it, and this is also the part that turns cleanly into a Skill.
  • Keep track of the times you break it. The interesting part is not the steps you follow, it is the moments you decide not to. You skip an approval because the change is tiny, or you stop a launch because one piece of feedback changed your mind. Note down why. Over time those exceptions show you where your judgment actually lives.
  • Give the agent reasons to stop, not just instructions to continue. When you hand a process over, do not only describe what to do next. Describe what should make it pause: conflicting information, an unexpected result, a number that moved further than it should have, an action that cannot easily be undone.
  • Get better at checking work you did not do. The more you hand over, the more your day shifts from making things to reviewing them, and those are different skills. OpenAI ran an experiment where agents wrote all of the code, and what ended up holding the team back was not the agents. It was how quickly people could check what the agents had produced. (OpenAI, Harness engineering.) Reviewing well is mostly about comparing what came back against what you actually asked for.

Where Tansei fits

Capturing the demonstration is the part I have been building into Tansei. You can record your screen with your voice on, so you can talk through the decisions while you work, or just leave a voice memo when the screen is not the point and saying it out loud is enough. Either way it lands on your shelf as a file, with a transcript alongside it, kept separate from the audio, so you can read back exactly what you said and tidy it up before it goes anywhere.

  • Record the task, and talk through it. Do the work the way you normally would, saying out loud why you are doing it that way. The narration is the part worth having, because it is usually the only place your reasoning exists at all.
  • Stop, and it is on the shelf. The recording saves to your machine and sits beside everything else you are working with, ready to use rather than filed away somewhere you will not look again.
  • Attach it wherever you are working. It is an ordinary file, so it goes where files go. Drag the recording into an assistant, or paste the transcript if you would rather hand over text, and ask for the procedure written down. That is the first draft of a Skill. Send it to whoever is picking the task up after you instead, and you have done roughly the same job for a person.
  • Edit what comes back. A first draft of a procedure is never quite right. The parts you correct are the ones worth noticing, because they are usually judgment that did not survive being written down.

The strange part is not the agents. It is being made to explain work we have done on autopilot for years. What part of your own work would you struggle to explain?

I'm the founder of Tansei, a simple shelf for Mac and Windows. I built it after noticing how much useful context disappears as we move between apps, tabs, files, and AI tools.

If you want to try capturing a workflow this way, it's at tansei.io. One-time purchase, and everything you record stays on your machine.

on September 7, 2026
  1. 1

    The corrections after recording may be more valuable than the recording itself. The happy path captures procedure, but every moment where you say "not in this case" reveals judgment and a boundary. A good generated skill should preserve those exceptions as tests, not smooth them into confident prose.