RonanCodes/skills/stay-in-your-lane

Stay In Your Lane

When several people or agents (all on Claude) work one repo at once, the failure mode is two of them editing the same area and clobbering each other. This skill draws lanes: a committed LANES.md that says who owns which files, directories, and tasks. Before an agent touches a file, it checks the lanes and either steps around someone else's area or asks first.

It's the soft, human-readable counterpart to git worktrees. Worktrees isolate the working copy; lanes isolate the intent, so even agents sharing one checkout know where the edges are.

When to use it

• Multi-dev hackathon on one repo: Nicolas owns cart + matching, you own everything else.
• A multi-agent swarm (/ro:planner-worker, /ro:night-shift) where workers may overlap on file areas and you want an explicit ownership map on top of the conflict detector.
• Any shared repo where "who's touching the checkout layer this week" keeps biting.

Auto-apply rule

When a repo has a LANES.md at its root, this skill is in effect for the session without being asked. At the start of work in such a repo:

1. Read LANES.md.
2. Establish which lane is yours (the --mine <name> arg, the ME marker in LANES.md, or ask once and remember for the session).
3. Treat every other lane's paths as off-limits unless the task explicitly spans them.

Before editing any file, resolve it against the lanes (see "Checking a path" below). If the file falls in another active lane, do not edit it silently - step around it, or surface the overlap to the user and ask.

A marker comment near the top of the target repo's CLAUDE.md / AGENTS.md makes this discoverable: <!-- uses ronan-skills:stay-in-your-lane - see LANES.md -->. Treat LANES.md itself as the real signal; the marker is a hint for humans skimming the repo.

Syncing lanes from the source of truth

--sync (or first run with no LANES.md) builds or refreshes the lane map. Resolve the source in this order, or honour --source:

• Linear - read assignees on in-progress / current-cycle issues; group each person's issues, pull the file areas they touch from issue scope or linked PRs.
• GitHub issues - read assignees + labels on open issues; group by assignee.
• Jira / Trello - read the assignee / card-owner field on the active board.
• ask - no tracker, or the user prefers to declare it: use AskUserQuestion to capture who is on what (name, the areas they own, the tasks). Loop until every active contributor has a lane.

Map each owner to concrete paths (globs) plus a short task description, then write LANES.md. Re-run --sync at the start of each sprint, or whenever someone changes focus, so the map tracks reality rather than going stale.

LANES.md schema

A committed Markdown file at the repo root. Human-readable first, machine-parseable second. One section per lane.

# Lanes

> Ownership map for parallel work on this repo. Synced from Linear on 2026-06-28.
> Before editing a file, check it's in your lane. If it's in someone else's, ask first.
> Maintained by ronan-skills:stay-in-your-lane. Re-run `--sync` each sprint.

## Nicolas  <!-- id: nicolas -->
- **Owns:** cart, product matching
- **Paths:**
  - `src/cart/**`
  - `src/matching/**`
  - `src/lib/pricing.ts`
- **Tasks:**
  - Cart persistence (LIN-204)
  - Matching algorithm v2 (LIN-211)
- **Source:** linear:LIN-204, linear:LIN-211

## Ronan  <!-- id: ronan, me -->
- **Owns:** everything else
- **Paths:**
  - `src/**` (except Nicolas's paths above)
  - `infra/**`
- **Tasks:**
  - Auth + onboarding (LIN-198)
- **Source:** linear:LIN-198

## Shared  <!-- id: shared -->
- **Owns:** files anyone may touch with care
- **Paths:**
  - `package.json`
  - `README.md`
  - `.github/**`
- **Note:** coordinate before structural changes; small additive edits are fine.

Field reference per lane:

| Field | Meaning | |---------|---------| | heading | The owner's display name. The HTML comment carries the stable id and the me marker for the current user's own lane. | | Owns | Plain-English summary of the area, for humans skimming. | | Paths | Glob patterns this owner is responsible for. The load-bearing part - this is what path checks resolve against. | | Tasks | Current tasks, ideally with tracker ids, so the map is auditable against the source of truth. | | Source | Where the lane came from (linear:ID, github:#N, jira:KEY, trello:card, or ask). |

Resolution rules:

• More specific paths win. src/lib/pricing.ts in Nicolas's lane overrides src/** in Ronan's.
• A (except ...) note on a glob is documentation; treat the explicit narrower lane as the real owner when paths overlap.
• The Shared lane is touchable by anyone, with the coordinate-first note honoured.
• A path in no lane is unowned: editing it is allowed, but consider adding it to a lane.

Checking a path

--check <path> resolves a single file against the current LANES.md and reports its owner and whether it's yours. Use this before any edit when working in a laned repo:

1. Match the path against every lane's globs, most specific first.
2. If it resolves to your lane or Shared or no lane: proceed (coordinate on Shared).
3. If it resolves to another lane: do not edit silently. Either find an approach that stays in your lane, or surface it: "X falls in <owner>'s lane (task <id>). Edit anyway, or route it to them?" and let the user decide.

For a swarm, each worker gets --mine <its-name> so it knows its own lane, and the planner keeps LANES.md as the shared contract on top of the file-area conflict detector.

Updating lanes mid-session

When focus shifts (someone finishes a lane, picks up a new area), update LANES.md and commit it so the next agent or dev sees the change. Keep the Synced from ... on <date> line current. The file is committed precisely so the ownership map travels with the repo and survives context resets.

Relationship to other skills

• /ro:worktree isolates the working copy per agent. Lanes isolate the intent. Use both for a swarm: each agent in its own worktree, all reading the same LANES.md.
• /ro:planner-worker / /ro:night-shift already do file-area conflict detection between parallel workers. LANES.md is the human-declared ownership layer that sits above it, so a dev who never reads the swarm internals can still see and edit who owns what.