Lane discipline
In a multi-agent fleet, verify a piece of work is in your designated lane before doing it, and state the check out loud. Defer to the owning agent when the work belongs to another lane. Use whenever the repo has documented agent/team role boundaries (AGENTS.md, .cursor/rules/, .claude/TEAM.md, fleet-team rules) and the task touches a shared area.From its SKILL.md
npx -y skills add jcdavis131/cursor-agent-skills --skill lane-disciplineAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.1 KB, 671 tokens by cl100k_base, as published. Nobody here has run it
Lane Discipline
In a fleet, two agents touching the same file = merge conflicts, duplicated work, and a muddy history. The check is cheap; the collision is expensive.
The move
- Know your lane. Read the fleet/team rules at session start (e.g.
AGENTS.md,.cursor/rules/00-fleet-team.mdc,.claude/TEAM.md). Know what you own and what each other agent owns. - Before starting a task, check the lane. Does this file / service / package belong to your lane?
- Yes → proceed, and say so: "instrumenting the training script — within my designated lane".
- Another agent's lane → defer. Surface the task to the owning agent or the user; don't do it yourself.
- Shared / ambiguous → coordinate. Post the intent, get a nod, then proceed. Mark the work as coordinated in your response.
- Make the check audible. State the lane check out loud when you start the task. This makes the boundary visible to the user and to any other agent reading the transcript, and it stops the work from being flagged as out-of-lane later.
- Keep changes non-invasive to other lanes. Prefer guarded, optional, additive changes ("guarded, optional") over rewrites of shared files. A change that another lane can ignore is a change that doesn't collide.
What "lane" means here
A lane is a documented ownership boundary — a set of files, services, or topics one agent is responsible for. Lanes are usually listed in the team rules. Examples from this fleet:
- Cursor: sites, api, scripts, UI, orchestrator patches.
- Claude (terminal):
training_loop.pyedits per the delegate doc. - Eve (worker): fleet ops, hill-climb, weakest-slice retrain.
- Operator: Neon, Railway, Vercel, disk, prod.
If a file touches two lanes (e.g. a shared client used by sites and by the trainer), the change is cross-lane — coordinate.
When to defer even though you "could do it faster"
- The owning agent is active and on the same task. Let them finish.
- The work is in another agent's designated lane, even if they're idle. Surface it; don't grab it.
- The work requires prod credentials or prod state you don't own.
Anti-patterns
- Silent cross-lane edit. You touch
training_loop.pywithout checking — Claude was mid-edit; merge conflict. - Grabbing idle-lane work "because it's easy". Easy work in someone else's lane is still their lane.
- Stating the lane check as a question. "I guess this is my lane?" — know your lane; state it.
- Big rewrite of a shared file. Shared files get small, additive, guarded changes; not rewrites.
Pair with
session-orient— recon reads the team rules so the lane map is loaded.background-failure-triage— a failed op in another lane is surfaced, not silently re-tried by you.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.