parallel-session-lanelisted

<!-- GENERATED from skills/parallel-session-lane/SKILL.md by scripts/build_maintainer_skills.py — do not edit. The shipped skill is the source of truth; this copy exists because this repository's own sessions do not load `rails-stack`, so the doctrine would otherwise reach every consumer except its maintainers. Edit the source and re-run the script. --> # Parallel session lane Several agent sessions may run against one repository at the same time. Every step below exists to keep their HEADs, indexes, and diffs from colliding. Each rule was written after the collision it prevents actually happened. ## 0. Getting into this mode Until #661 a human opened N terminals and assigned lanes by hand — this skill described a mode nothing could put you in. `rails-flow` now ships an assigner: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/scripts/assign_lanes.py" app/models app/controllers --budget-usd 6 ``` It prints the `git worktree add` per lane and the session command with `RAILS_FLOW_LANE` set. It **refuses** overlapping lanes, a single lane, a dirty tree, and a missing lane guard. **It prepares; it does not spawn.** Creating a worktree is mechanical and deciding when an agent starts is not, so it prints the commands rather than running them. **No tmux and no daemon** — but "no message passing" was too strong, and four sessions disproved it in a day. Git is the right medium for a **handoff of work**: a work order is a committed file, `compose_state.py` derives the dri