---
name: owning-a-lane
description: Use when another session hands you ownership of a lane, a package, an issue, or a piece of work to run — a standup briefing, a split-the-plan package, or any message saying the work is yours through to done.
---

# Owning a lane

You own a lane. You are the **overseer** of it: accountable for it reaching done, and for the
judgment calls along the way.

**You do not write it.** Not the implementation, not the test, not the one-line fix.

## Why not, when you could just do it

The fan-out is not process overhead. It is the only thing making the writer and the reviewer
different contexts. A seat that edits its own lane reviews its own work, and a self-review reliably
finds the work correct — it reads its own intent into its own wording.

Measured: two fresh seats handed a one-line lane both implemented it directly, verified it, and
committed. Both produced correct code. Neither was reviewed by anyone, and both silently resolved an
open question in the issue that belonged to whoever owns that subsystem. Competence was never the
failure mode.

**Violating the letter of this is violating the spirit of it.** A one-character edit is an edit.

## Size the fan-out to the lane

| Lane | Shape |
|---|---|
| A one-liner, a rename, a config value | One subagent to write it, one to review it. Two dispatches, no plan file |
| A bug with an unclear cause | `systematic-debugging` first — the repro is the spec — then one implementer, one reviewer |
| A real feature or refactor | `writing-plans`, then `subagent-driven-development` |
| Too big for one seat — 3+ disjoint file regions, days of work | `/split-the-plan`. You cannot fire it; ask the human to |

Two dispatches is the floor, never zero. Choosing among these is yours; the briefing handed you a
lane, not a method.

**Isolation is yours too.** Worktrees for what you dispatch, outside the repo, provisioned one at a
time. The seat that briefed you provisions nothing.

## Escalate rather than decide

Send a message to the seat that briefed you — your overseer — the moment you hit any of these:

- The lane's scope is ambiguous, or done-ness is
- The issue or plan contains an open question (**this is the one that gets missed** — an open
  question in the text you were handed is not an invitation to resolve it)
- The work needs a file or region your lane does not own
- You are not confident in a result, or two readings of a requirement are both defensible

**Name the decision, not the discomfort.** State the fork and the option you would take absent an
answer, so the reply can be one line. "Should I…?" costs a round trip; "I'll do X unless you say
otherwise" costs none.

**If your lane is a decide lane, the escalation *is* the deliverable — and this is the one stated
exception to "you do not write it" at the top of this skill.** You own the question, not the
answer. Produce the package — named options, the cost of each, what is demonstrated and what is
reasoned, and the recommendation you would defend — and do not choose, and do not implement any
option. **If your reading makes the question moot, say so: that is a valid package and the strongest
one.**

**Escalate up, never sideways.** A question for another lane's owner is a peer message —
`coordinating-with-peer-sessions` governs that. If the seat that briefed you is gone, escalate to the
human. A dead address is not permission to guess.

**Your own subagents escalate to you, not past you.** The chain is one hop: they cannot reach the seat
that briefed you, and a role word is not an address — a subagent that tried got `No agent named
'general-purpose' is reachable`. Answer them yourself, or carry the question up on their behalf.

## Where your work is described, and where updates go

**Read the comments, not just the body.** An issue body is a snapshot from the day it was filed; the
thread is where it was corrected. Measured on one lane: the body pointed at tightening an assertion,
and a peer had already established in the thread that the assertion was fine and the real fix was a
different test entirely. Two seats working from the body alone implemented the wrong change, verified
it, and committed it as done.

Check what a comment claims against the code before you act on it. A thread is evidence, not
authority — but a thread you never opened is neither.

| | Where |
|---|---|
| What the lane is, what done means | The issue — body **and its full comment thread**. A plan file only if the lane needs one, linked from the issue |
| Progress | A comment on the issue. Durable, costs no one a turn, and the standup reads it without polling you |
| Done | **A durable artifact, never a message to your overseer.** A **remediate** lane: one or more PRs, each body carrying `closes #<issue>` — **the reference is part of the deliverable, not something the merge guarantees.** It is a convention: nothing warns when it is omitted, and the issue sits open reading as outstanding work while your fix ships. A **decide** lane: a decision package on the issue — the named options, what each costs, a recommendation. A **land** lane: a merged PR or a written obituary. Telling your overseer you are done is not done |
| Stuck, unsure, scope changed | `SendMessage` to your overseer. A comment nobody is watching is not an escalation |
| A plan-derived lane with no issue | Its `map.md` row and your standup reply. Do not file an issue just to have somewhere to post |

Answer the standup when polled. Do not stream status upward between standups — the daily pulse is a
pull.

## Rationalizations

Every one of these was produced by a real seat under real pressure. All of them mean: dispatch.

| Excuse | Reality |
|---|---|
| "It's one line — a subagent is overhead" | One line is where self-review is *most* convincing and *least* checked |
| "Standup is in 20 minutes" | Two dispatches take minutes. An unreviewed change outlives the deadline |
| "Don't burn budget on process for a lane this size" | The budget argument is how every review gate dies. Cheap lanes get cheap fan-outs, not none |
| "I can see the answer to the open question" | Seeing an answer is not owning the decision. Escalate it |
| "I verified it — full suite passed" | Green proves it runs, not that it was the right change |
| "I'll dispatch if it turns out to be complicated" | You cannot tell from inside. The floor is two dispatches |

## Red flags — stop

- You are about to call `Edit` or `Write` on a repo file
- You are reasoning through an open question the issue left open
- You are deciding what a requirement "obviously means"
- You have done zero dispatches and are near done
- You have read the issue body but not its comments
- You are about to extend a branch during a **land** lane
- You are about to overwrite a record whose staleness is itself the evidence

**All of these mean: stop, and dispatch or escalate.**