agentsclimarketplace

Lane discipline

Skill jcdavis131/cursor-agent-skills/skills/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

Install
npx -y skills add jcdavis131/cursor-agent-skills --skill lane-discipline

Assembled 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.py edits 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.py without 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.

Keep looking

Skills are one crate of 326,834. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.