run

name	run
description	The production run order for multi-agent work on the agent bus. Use when a task will involve more than one agent, at the start, before any dispatch. Covers opening a run, planning, disjoint dispatch, central integration, outside-eye verification, acceptance, and close.

run: the production cycle

You are about to orchestrate multi-agent work. Follow this order; each step exists because omitting it produced a recorded failure. The full rationale is in dispatch/RUN-ORDER.md where this skill is installed from.

Open

1. Create the run file first: bus-new <run-name> (see the bus skill for the message schema and tools). Post an opening note: the goal, the constraints as given. Confirm the embedding model is available (bus-model status); fetch the default if missing. Model switches (bus-model use) are deliberate and recorded on the bus with their reason.
2. You are bound by the bus too. Post your own survey findings, decisions, and direction changes as you go, with provenance. Mid-run direction from the operator is recorded as testimony when it arrives, not reconstructed later.

Plan

3. Survey before building; post what you find as findings so the plan rests on checkable claims. Where ground is unfamiliar, dispatch the researcher first.
4. Prefer the smallest true architecture. A wrong abstraction costs more than a missing one.

Dispatch

5. Give each parallel worker an explicitly disjoint file scope, its bus agent name, and the run file path. State scopes in the dispatch prompt itself.
6. While any parallel worker is writing, you alone run version control. Never use bulk staging (git add -A or equivalents) while workers are active; stage explicitly or serialize commits after they finish.
7. Relay direction changes to affected workers immediately; record the relay on the bus.

Integrate

8. Workers return compact summaries and message ids; read the bus for the substance. Where two rankings disagree, resolve on the bus with a stated basis. Never average silently.

Verify

9. Verification is done by a reviewer who did not build the work, from a clean tree. A green suite is a claim; it becomes evidence when a deliberately broken guard makes it fail. For releases, verify install and onboarding steps cold, as a stranger would.

Close

10. Before declaring the work finished, run the acceptance question honestly: finished, or wanting exactly one named next pass. Both answers are legitimate.
11. Every substantial contribution closes with a cost line (consumed, produced). Lint the run file; leave it consistent. State plainly anything unfinished and why.