There is a predictable gap between what an employee produces and what you would have sent. You close it by hand the first few times, giving the same notes each round. Those notes are the asset. Written down once, they become the standard every future run is held to, and the work arrives closer to finished instead of closer to started.
Steps
Give the feedback properly, once
Take a real piece of work and correct it thoroughly. Not "make it punchier" — say what was wrong and what the rule is. You are writing the review standard without realising it, and the quality of that conversation decides everything downstream.
Turn that conversation into a skill
A skill is written procedure: the steps, the decision rules, the output shape, the boundaries. It is markdown, so you can read it and edit it later, which matters because you will.
Then read what it wrote. This is the moment to catch a rule you did not mean to make permanent, because from here on it applies to everything.
Put the skill in front of the work, not after it
Attach it as a review step in the workflow that produces the thing, so nothing reaches you unreviewed. A skill that exists but runs only when someone remembers is not a standard.
Use more than one reviewer when it matters
One reviewer finds one class of problem. For anything that goes outside the company, run several passes with a different lens each, rather than the same review repeated.
Different lenses catch different failures. The customer pass finds tone problems the editor pass never will, and the factual pass is the one that stops an invented number reaching a client.
Reviewing against a written standard is a fundamentally easier task than producing against an implied one. That is why this works: you are not asking for better writing, you are giving it something concrete to check against.
Keep the standard alive
Every time you correct something the review should have caught, add that rule to the skill. Do it immediately, while you know exactly what was wrong. A standard you stop updating quietly stops matching what you want.
Share it, or keep it private
A skill is a file. Other employees can use it, so your support desk and your newsletter can hold the same voice. If it encodes something genuinely yours, that is a reason to keep it in house rather than publish it.
A review pass is not an approval gate. It raises the quality of what reaches you; it does not decide whether it goes out. Keep the send gated, particularly once the drafts start looking good enough to wave through.
Verify
- Run an old, bad piece of work through the review and confirm it catches what you caught
- Confirm it flags judgment calls rather than quietly deciding them
- Have a second employee use the skill and confirm the standard is the same
- Count how much you still edit after review; that number is the honest score
When it goes wrong
Review approves everything
The skill describes taste rather than tests. Rewrite each rule as something checkable: a length, a required element, a banned phrase.
Review rewrites instead of flagging
Say which class of problem it may fix and which it must only raise. Mechanical, yes; anything involving a claim or a commitment, no.
The three passes all say the same thing
They are running as one review with three headings. Ask for them separately and unmerged, and be specific about what each lens is responsible for.