| name | nehir-delegate-lane |
| description | Set up one isolated implementation lane and hand it to a worker with the project's discipline fences attached. Invoke explicitly with /nehir-delegate-lane when a well-specified cluster of work should run in its own worktree. |
| argument-hint | <cluster description> |
| disable-model-invocation | true |
| allowed-tools | Read, Grep, Glob, Write, Agent, Bash(mise run:*), Bash(git status:*), Bash(git log:*), Bash(git diff:*), Skill |
Delegate one isolated implementation lane
CLUSTER: $ARGUMENTS
1. Define the lane before spawning anything
Establish and write down:
- the exact files or directories this lane owns;
- the do-not-touch fence, naming the files and clusters that sibling lanes own;
- the validation command for the fast gate (not the test suite);
- the completion criteria.
Never assign two lanes to the same cluster or to overlapping files. If the
clusters cannot be cut so that file ownership is disjoint, say so and stop
rather than spawning overlapping workers.
2. Choose the execution surface
lane-worker subagent (default). Use the Agent tool with
subagent_type: "lane-worker". It runs in its own git worktree and returns a
summary instead of flooding this session's context.- Watchable pane. When the user needs to observe and steer the work live,
launch it in the lane workspace's own pane instead. Never drive a lane's work
from a pane that belongs to another workspace.
3. Bootstrap before handoff
A fresh worktree must be able to run the project's checks before the worker
starts, or the worker burns its context diagnosing a broken toolchain. Trust the
environment, install or prepare dependencies, and run the non-test fast gate
once.
4. Write a self-contained task
The worker gets no conversation history. The task must carry the exact scope,
the owned files, the do-not-touch fence, the validation commands, and these
rules verbatim:
HARD RULES:
- Do not spawn subagents; do all work yourself in this session.
Then append both shared fences, read from:
${CLAUDE_PROJECT_DIR}/.agents/shared/fences/claim-and-test-discipline.md${CLAUDE_PROJECT_DIR}/.agents/shared/fences/git-mutation-permission.md
Read those files and inline their fenced blocks into the task. Do not paraphrase
them and do not maintain a second copy.
5. Verify the result yourself
The worker's success claim is not evidence.
- Read the diff.
- Re-run the non-test fast gate yourself.
- Falsify any subtle claim — concurrency, reactivity, guard semantics — with a
small runtime experiment before accepting it.
A justified deviation from the plan, with reasoning, can be correct. Judge it on
the merits rather than rejecting it for differing from the plan.
Run the test suite only after the test gate unlocks; when it does, run the full
suite once at the late validation stage.
