A perfectly written skill that never fires is worthless. Whether it fires is decided by one thing — its description — and you can measure and tune that instead of guessing.
Most skills hand back text or a file — a mistake there is a bad paragraph. A skill that writes to a live database or content store is different: a mistake is duplicated, corrupted, or lost data. The build discipline has to change with it.
You spent an afternoon building a skill. By default it landed in a personal folder that no repo sees and no teammate has. That's real work sitting outside version control.
The system said the records were gone. They really were gone. But the same system routinely reports counts that are wrong by a factor of eight — so how do you know which kind of "gone" you are looking at, before you act on it?
You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.
You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.
The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.
You hardened a skill in the repo, shipped the PR, and the agent kept loading the old one. Or you fixed the live skill by hand, and the versioned copy quietly stayed behind. Same root cause: the copy you run and the copy you version are two different files.