A skill is your procedure in plain language. Attach it to a project and every agent is checked against it before it’s allowed to change anything.
Not because they are wrong. Because nothing in the working day forces anyone to open them. The document is written, filed, and quietly ignored, and the standard survives only in the head of whoever wrote it.
Plain markdown describing how a class of work is done well. It encodes behaviour rather than capability. Not “can you review this contract” but “when redlining, categorise every change and frame it for partner review”.
Vague guidance produces vague work. A good skill names the standard, the steps and the evidence required: a checking-engineer pass, a citation check, an evidence grading.
Nobody has to remember. Opening a project hands the agent the skills attached to it, and any change made without them is refused outright.
Edit a skill and every project, every teammate and every future agent run picks up the better version. No retraining, no reminder emails.
The method that makes your practice worth hiring usually lives in two or three people’s heads, and leaves when they do. Written down once as a skill, it becomes something the firm owns rather than borrows. Example procedures ship as starting points, but the ones worth having are the ones you write.
| A written procedure | A Drafted skill |
|---|---|
| Someone has to remember it exists | It’s loaded before work starts, or the work doesn’t start |
| You find out it was skipped at review, if at all | It can’t be skipped: the change is refused, not flagged later |
| Updating it means telling everyone again | Updating it lifts every project and every agent at the same moment |
A skill isn’t tied to one assistant. Write it once and it applies wherever your team works.
Start with one procedure you’re tired of repeating.