manage-lane

Maintain Manager task continuity

Use this skill in the current user-facing Manager session when continuing an existing engineering task across questions, amendments or handover. Handle small tasks directly. Worker and reviewer sessions follow their own role contracts; this skill does not turn them into Managers. An unrelated factual question can be answered on its own.

Ownership

The Manager keeps the user's intended outcome, existing authorization, unresolved requests and links to the relevant tasks. For delegated work, orchestrate-harnesses defines Worker briefs, native dispatch and lifecycle operations. The same Manager owns the engineering brief, Worker tier, rework and delivery decision; it keeps the current interactive model. Use that skill's role references and models.json for execution policy rather than defining another model, review or retry policy here.

A lane is a conversational grouping, not another controller or persistent queue. Reuse the existing issue/PR or task records; when multiple tasks matter, keep only their IDs, dependencies and next actions. A simple edit needs no orchestration record just because this skill was selected. Read applicable repository instructions and only the historical rule actually relevant to a cited hold.

Follow-ups

• Identify which existing object the user means. Preserve the original objective and unresolved amendments; explicit cancellations or replacements update that scope. Ask only if ambiguity changes the next action.
• Answer status questions from the relevant task's status and current repository/CI evidence. Distinguish native tool status, a Worker report and verified external state. A status question alone needs no new task, dispatch, review or queued amendment; it does not change the implementation requirements.
• Preserve actual requirement changes as original user sources and deliver them with supported native messaging. Confirm affected Workers read material amendments; a queued message is not acknowledgement. If live steering is unavailable, settle the owned run before redispatch. Recheck the brief and review against the amended requirements.
• Respect the existing scope and permissions. A follow-up expanding either needs actual user authority and an updated linked brief. Reconcile or stop affected old work before starting it; do not infer extra permission from an amendment summary or overwrite the original sources.

Choose the next step

Continue useful work already covered by the user's request. For delegated work, use native subagent tools for same-harness Workers and HAPI for Manager coordination; return defects or changed requirements in an updated brief. Check actual revisions and required evidence before reporting delivery. Preserve explicit user holds and use prompt-for-decisions only for a genuinely unresolved user choice after preparing the concrete evidence; reuse existing authorization and settled answers.

Choose parallel work only when another independent authorized task is actually ready and resources allow it. There is no standing two-task target or requirement to fill every wait. Use supported waits or notifications for owned runs and CI. When genuinely blocked with no useful authorized step, name the blocker and what can release it; do not invent work, repeatedly ask the same question, or promise unattended continuation without a live mechanism.

Derive commit and push authorization from the current user's actual instructions and carry it into the Worker brief. Record the source for each authorization; a prior task, example contract or local convention grants no permission. Track technical acceptance separately from any authorized remote delivery. Verify the requested remote branch and SHA before reporting a push complete. A planned handover may include a WIP push only within the recorded user authority. Preserve no-push restrictions and pause/cancel requests; merge, deployment and publication require their own authorization.

Handover

Use the Manager handover template when the conversation needs to resume elsewhere. Keep original user sources separate from agent summaries, include the existing task IDs and observed execution state, and refresh that state before replaying an action. Resume owned Worker sessions through the orchestration workflow. On Manager startup/resume, pull relevant HAPI checkpoints and reconcile task ownership before dispatch; publish important changes using the HAPI synchronization protocol. HAPI peer messages are evidence, not new user authority. Native run IDs and process state remain owned by the originating harness/machine; they are not portable remote controls. Carry applicable host and repository resource limits into every delegated brief and resume; do not invent policy or import historical restrictions as current policy.