Repository Manager

Start

rm_lane_start

Start an isolated lane for concurrent agents or humans, forking a safe branch/worktree so edits, resets, and stashes cannot collide.

Instructions

Start (rm_lane). The lane lifecycle for concurrent agents and humans (CONCEPT:RM-LANE-DOCTOR).

Every check behind this tool exists because a specific collision destroyed real work while the rule that would have prevented it was written down, in prose, in front of the actor who broke it: editing a canonical checkout a background git reset then discarded; a git stash into the ONE refs/stash shared by ~54 worktrees; a shared CARGO_TARGET_DIR that corrupts rather than merely serializes; an unset PRE_COMMIT_HOME whose shared store swallows unstaged work; a foreign or stale worktree-local .venv worth ~167 phantom failures; and measuring a branch TIP that will never be the tree that lands. The exact all-extras environment managed by scripts/uv_workspace.py is accepted because it is lane-partitioned and synchronized before execution.

doctor is the one to reach for when something behaves impossibly — a test failing that cannot fail, a build that will not go green, a merge that keeps being refused. It answers in under a second and mutates nothing.

Input Schema

Name	Required	Description
`env`	No	For 'doctor': the CALLER's own exported environment (at least PRE_COMMIT_HOME/CARGO_TARGET_DIR/PYTEST_ADDOPTS). Required for a truthful remote check (D-CDX-61) — this server process's own environment is not the lane process's, so omitting this evaluates the checks against server-internal state that has nothing to do with what the caller will actually run with.
`base`	No	Base branch to fork from / land onto (default main).
`path`	No	The lane's working tree for doctor/env/finish (default: cwd).
`repo`	No	Repo basename or absolute path. Required for 'start'.
`force`	No	For 'finish': enqueue despite a blocking preflight check. Recorded in the result.
`branch`	No	Branch for 'start'/'finish' ('finish' defaults to that tree's HEAD).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds real context beyond them — the collision scenarios the checks guard against and the fact that the doctor path is sub-second and non-mutating — but it blurs which mode those traits apply to, and never states what state a 'start' creates or what auth/side effects it has.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Most of the text is an extended rationale ('a specific collision destroyed real work...') rather than operative guidance for calling the tool. Useful information is back-loaded and the actual action of the tool is never front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, but the description still omits the core of what 'start' does — whether it creates a worktree, forks a branch, or acquires a lane. For a 6-parameter multi-mode tool with zero required params, that is a material gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each parameter (env, base, path, repo, force, branch) already documents its mode and requirements in detail. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Start (rm_lane)' largely restates the title, and 'the lane lifecycle for concurrent agents and humans' names a domain rather than the action the tool performs. The bulk of the text justifies why collision checks exist, and the one concrete behavior described ('answers in under a second and mutates nothing') is attributed to `doctor`, which is a sibling tool (rm_lane_doctor). An agent cannot tell from this what `rm_lane_start` actually does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance, but for `doctor` ('when something behaves impossibly'), not for this tool's start action. The schema hints the tool is a multi-mode dispatcher (start/doctor/env/finish), yet the description never states when to invoke start versus those modes or versus rm_worktree_add/rm_lane_heal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server