I run several agents on one checkout. The naive arrangement fails in a specific and expensive way: each agent edits happily, two of them touch the same file, and by the end of the day the merge conflict has become the design review — a review of two changes that never met, written by an agent that no longer has the context of either.
I have also watched the opposite failure, which is more embarrassing because it looks like discipline. An agent sees an uncommitted file, decides a colleague must be working on it, and waits. The colleague stopped typing on Tuesday. The plan halts for two hours over a file that has been idle since the previous week, and the halt is reported as coordination.
This skill exists to prevent both.
The idea
An agent claims its work before writing to it, and the claim is recorded where other agents look first: a small board beside the plan, not a chat message that scrolls away.
Everything else follows from one distinction most advice gets wrong: in flight versus merely uncommitted.
Uncommitted work nobody is touching is simply the current state of the file. It survives reboots, weekends and cold starts, and it says nothing about anyone typing now. You read it carefully, edit on top, and commit when your own step is verified.
Work that somebody is writing at this moment is different, and only that is off limits. A step that needs it is marked blocked, the plan reroutes to the next ready step, and the agent circles back. The plan stops only when no step is ready, and then it has to name whose claim is holding it up.
Why it is shaped like this
Because worktrees solve a different problem. They are good for exploring two designs in parallel; they are bad for coordination, since isolation plus a late merge is exactly how drift turns into a batch job with three-way conflicts and a lost afternoon.
And because a claim, unlike a lock, goes stale. A claim older than fifteen minutes with no matching write is treated as released and deleted by whoever notices. That is the mechanism that keeps the board honest without an administrator.
What it is not
Not a framework, not a tool, and not a promise that agents never conflict. It is a way of keeping conflicts small enough to resolve in a minute, and of keeping the plan moving when one path is busy.
It assumes git, and it assumes you would rather ship a small verified step than a large unverified batch. Available on request; the skill text is not published here.