From loom
Drive delegated objectives through Loom owner layers. Use when advancement needs shaping, ticket tranches, execution, evidence, critique, and continuation.
npx claudepluginhub z3z1ma/agent-loom --plugin loomThis skill uses the workspace's default tool permissions.
`loom-drive` is the objective-driven parent-loop coordinator.
Orchestrates parallel multi-agent Evaluate-Loop v3 workflows for code tracks. Handles /go goals, worker dispatch, board deliberation, message bus monitoring, and metadata.json state tracking.
Orchestrates multi-day execution of complex tasks via milestone pipelines with plan-crafting, run-plan, review-work phases, checkpoints, and recovery.
Drives projects autonomously from commander's intent to completion via OODA loop: scopes tickets, implements via skills, refactors, reviews, debugs. User as product owner.
Share bugs, ideas, or general feedback.
loom-drive is the objective-driven parent-loop coordinator.
It gives the current agent a procedure for turning a broad user objective into owner records, bounded ticket tranches, Ralph or local execution, reconciliation, and continuation decisions.
The essence of loom-drive is sustained parent judgment.
The user should be able to say what outcome they want, not manually operate every Loom phase. The parent agent then keeps asking the same governing question:
What is the next owner-truth mutation or bounded execution step that most directly advances the objective without inventing authority?
loom-drive is successful when the agent can keep moving between shaping and
execution while the filesystem graph remains the recoverable source of truth. It
is a failure if the real plan lives in chat, if the agent keeps asking for
approval on every obvious next ticket, or if autonomy becomes an excuse to widen
scope without owner records.
When this skill activates, the parent accepts a drive contract:
The contract is suspended when the objective can no longer be advanced safely from the recorded truth.
The loop remains recoverable across sessions only when the current drive state is recorded in owner artifacts. Before executing downstream work, establish a drive checkpoint from existing layers:
# Delegated Authority / Autonomy Boundaries, and
# Objective-Level Stop Conditions for delegated drive workOBJ-001 when downstream tickets, evidence, or critique need to cite themhandoff_write_scope, stop conditions, and output contract without owning
canonical truthIf a fresh agent could not resume from those records, stop driving and repair the checkpoint before launching more work.
Use references/continuity-contract.md for the continuity convention: objective
status, current tranche, active tickets, blockers, evidence, critique, and journal
history live in existing owner-record sections instead of a new ledger.
Use references/checkpoint-resume-protocol.md before stopping, compacting,
launching child work, or handing control to another route. If the checkpoint
cannot be found or updated in owner records, stop driving. Before any child
launch, the checkpoint must already be current; "can update later" is not enough.
Workflow coordination is not truth ownership. When this skill creates or changes durable claims, route them into the layer that owns that kind of truth.
Direct owner reasoning wins over drive. If the safe action is already one bounded owner update or workflow pass, use that owner skill directly and let the ticket, record, or workflow that owns the truth carry the work.
Activate loom-drive for chat requests shaped like:
Before activating, route through loom-workspace if the workspace, owner chain,
or repository scope is not trustworthy enough to drive.
Do not activate merely because a task is large. Activate when the user is
delegating outcome advancement across phases. A large but already ticket-ready
implementation still belongs directly to loom-tickets or loom-ralph; a clear
local edit still belongs to local_edit; and one single-owner record mutation
still belongs to that owner skill.
Ask only enough focused questions to make the first durable objective safe to record. Prefer a small batch of questions over repeated approval gates.
Clarify these before downstream tickets depend on them:
Once those are clear enough, proceed through Loom records without asking for approval before every ticket. Stop and ask again only at explicit escalation boundaries.
references/tranche-decision-protocol.md when objective gaps or sequencing
ambiguity require an optional gap summary or fuller tranche detail before the
next bounded ticket or workflow pass is safe.ship packages or hands off already truthful work; it does not own
ticket closure.See references/drive-loop.md for the fuller parent checklist.
A dedicated outer-loop subagent may be used for context management when the parent needs fresh synthesis of an objective chain, option set, tranche plan, or risk list.
This is transport only: the subagent proposes owner-record changes, tickets, and risks; the parent reviews and reconciles the output before depending on it; canonical records and tickets retain truth ownership.
Use references/outer-loop-subagent-transport.md when optional outer-loop
subagent transport is relevant. Use templates/outer-loop-handoff.md only when a
bounded handoff would reduce context pressure or improve reviewability.
When a user decision is required, ask one focused question or a small batch of related choices, state why owner records and delegated autonomy cannot safely answer it, and name the owner record that should be updated after the response. Do not ask the user merely to approve low-risk, reversible assumptions that stay inside delegated authority.
Read immediately when activating loom-drive:
references/drive-loop.md for the parent-loop checklist.references/continuity-contract.md for the owner-record fields that must
carry resumable drive state.references/tranche-decision-protocol.md for conditional objective-gap
summaries, optional tranche detail, decision priority, and reconciliation
targets.references/checkpoint-resume-protocol.md for hard safety gates, checkpoint
updates, and deterministic resume.skills/loom-records/references/route-vocabulary.md when distinguishing
workflow choices from statuses, packet outcomes, commands, or support cues.skills/loom-workspace/references/routing.md if the owner layer or workflow
coordinator is still unclear.Then read conditionally:
skills/loom-initiatives/SKILL.md when creating or refining the objective and
success metrics.skills/loom-research/SKILL.md, skills/loom-specs/SKILL.md, or
skills/loom-plans/SKILL.md when evidence, intended behavior, or sequencing
is missing.skills/loom-tickets/SKILL.md before creating, advancing, or accepting
bounded execution work.skills/loom-ralph/SKILL.md before packetized implementation execution.skills/loom-evidence/SKILL.md, skills/loom-critique/SKILL.md,
skills/loom-wiki/SKILL.md, or skills/loom-retrospective/SKILL.md when
observations, review, accepted explanation, or learning assimilation is next.references/outer-loop-subagent-transport.md when optional outer-loop
subagent transport is relevant.templates/outer-loop-handoff.md only when launching an optional bounded
outer-loop synthesis subagent.