I attended AirOps Next in New York on May 13, 2026, where Austin Lau from Anthropic discussed encoding workflows into company-level shared skills. There’s an editorial question inside that idea that I think deserves more attention: when an editor fixes an AI draft, what does the company actually keep?
It keeps the finished article, of course. It might also keep a comment thread, a prompt someone saved, and an earlier version with the bad paragraph still in it. But the useful part of an edit is often the decision behind it. Why was the claim too broad? What did the writer misunderstand about the reader? When would the original wording have been appropriate?
A shared skill gives that judgment somewhere to go. The harder work is deciding which judgments deserve to become instructions.
One edit, several possible lessons
Suppose an AI-assisted draft says, “Our onboarding platform cuts implementation time in half.” The editor deletes it because the source material doesn’t support it. This is a hypothetical example, but it makes the problem easy to see.
You could save “don’t say we cut implementation time in half.” That might prevent the same sentence from appearing again. It would do very little about the next draft claiming that the platform doubles productivity.
You could save “avoid numerical claims.” Now you’ve gone too far. If a customer has approved a case study with a well-supported result, the number may be the most useful part of the story.
The instruction I’d want is closer to this:
Before using a performance claim, identify the source and check what it supports. Keep customer results tied to that customer and the conditions described. If the source is missing, flag the claim for the editor instead of supplying a plausible number.
That instruction preserves the reason for the correction. It also gives the next writer an action to take. “Be accurate” asks for a virtue; checking a claim against its source describes work.
I’d keep the example beside the instruction, including a version that should pass. Otherwise it’s easy to teach the workflow that deleting evidence is the safest way to follow the rules. A useful skill needs to help the team publish stronger work, too.
Some corrections should stay local
The same approach gets trickier with editorial preferences. Imagine an editor removes the background section from an article because this particular reader already knows the subject. Turning that edit into “skip background sections” would quietly change every future article, including the ones meant for people encountering the subject for the first time.
Before adding a rule, I’d ask what the editor was responding to. Was the draft missing information about its audience? Did the assignment call for a quick update? Was the section redundant? Those are different problems, and a permanent style instruction may solve none of them.
If the brief never identified the reader, fix the brief. If the source material was weak, improve the source material. If this was a choice for one article, leave it with that article. Shared skills are useful precisely because they can affect many pieces of work. That reach makes a careless instruction expensive.
This also matters for voice. A team can accumulate enough rules about introductions, headings, sentence length, and endings to make every article sound like it came from the same outline. The writing becomes more consistent while the thinking becomes harder to see. I’d rather preserve the reason a section worked—perhaps it explained a confusing decision with a concrete example—than require every article to include that kind of section.
Try it on the next assignment
I’d start with one recurring correction in a workflow that already has a reviewer. There’s no need to document the entire editorial process before learning whether a shared instruction helps.
Save the original passage, the edited passage, and a short explanation of the decision. Write the smallest instruction that captures the lesson. Then give it a different assignment where that lesson should apply. Reusing the original draft only tells you whether it can repair something you’ve already shown it.
For the performance-claim example, I’d try a draft with an unsupported claim and another with a properly sourced customer result. The reviewer should check both sides: did the unsupported claim get flagged, and did the supported result survive with its scope intact? If the workflow removes both, the instruction needs work. If it invents a citation, the source-checking step needs attention before anyone relies on it.
I’d also put someone’s name on the instruction. When an editor sees a bad result, they need to know who can revise or remove the rule. Otherwise the team has created another document everyone is expected to follow and nobody is responsible for maintaining.
Austin’s discussion is part of my May 14 event recap. It’s one reason I’m interested in AI-assisted operations: there’s valuable work between producing a draft and approving it, and a finished page captures only part of that work.
The test I’d use is ordinary: can the next person understand why the correction was made, apply it where it belongs, and recognize when it doesn’t? That’s more useful to keep than a growing list of things the AI is never allowed to say.