dos-goal-fleet
dos-goal-fleet launches multiple independent headless worker instances in parallel waves, each pursuing a single goal whose completion is verified by an external witness rather than self-reported. Use it when decomposing a multi-objective context into concurrent independent tasks where each worker's "done" claim must be corroborated by effects the worker did not author, and load-balanced account-aware wave launching is required.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernel /tmp/dos-goal-fleet && cp -r /tmp/dos-goal-fleet/src/dos/skills/dos-goal-fleet ~/.claude/skills/dos-goal-fleetSKILL.md
# dos-goal-fleet — wave-launched self-stopping goal workers, witnessed not narrated > **A fleet that trusts each worker's "I'm done" is a fleet of silent fails.** > The move this skill makes is the one the whole substrate exists for: a worker's > "the goal is met" is a *claim with a byte-author*, and the byte-author is the > judged worker. So each child's stop is gated on `dos-goal-gate` — it cannot > declare done until a witness it did not write (git ancestry, an effect > read-back) corroborates the goal's effects. The fleet launches the leaves; the > kernel decides which ones actually landed. The skill narrates; it never rules. Take an operator-supplied context describing several **independent objectives**, turn each into ONE headless worker armed with a single goal, and fire them in **waves** sized to whatever seat pool the host exposes — so the launch is load-balanced and no single account walls. This is the fan-out analogue of two sibling skills: - **`dos-goal-gate`** is one self-stopping leaf — a single agent whose "done" is grounded. `dos-goal-fleet` arms *many* such leaves at once. Each child runs the goal-gate discipline; this skill is the launcher and the rollup around them. - **`dos-witness-claim`** is the *fold* — believing only the confirmed effects when many workers' results converge. Step 5 here is that fold, applied to the fleet's per-instance outcomes. The shape is domain-free: **decompose into independent goals → arbitrate co-launch safety → wave-launch one self-stopping child per goal → witness every claimed ship → roll up.** The *policy* (which lanes, which plan grammar, how the host rotates accounts, which model a child runs) is **data** read from `dos doctor --json` / `dos.toml` and from the host's own launch convention — never a literal this screenplay hardcodes. A shipped generic skill names no host (the litmus); the host-specific launch verb is a seam you fill in Step 3. ## When to use this (and when not) - **Use it** when the operator hands a context with **2+ independent objectives**, each describable as a single goal condition (a visible deliverable), and wants them run concurrently rather than serially. - **Use `dos-goal-gate`** when it is **one** objective — just arm a single self-stopping agent; no fleet needed. - **Use `dos-dispatch` / `dos-next-up`** when the work is already shaped as a phased-plan *dispatch packet* of disjoint repo tasks — that is packet-driven; this skill is goal-condition-driven over free-form objectives. - **Use a single agent or a loop** when the objectives are a *sequenced plan* — one goal waits on another's output. The fleet is for **independent** goals. > **Never arm a loop spine.** Do not goal-gate a dispatch-loop or a supervisor > spine — those have their own typed stop authority. `dos-goal-fleet` arms *leaf* > objectives, which is exactly the sanctioned use. ## Inputs | Shape | What it looks like | Route | |---|---|---| | Explicit goal list | "goal 1: …, goal 2: …, goal 3: …" | one instance per listed goal | | A context to decompose | a paragraph / doc / set of asks | Step 1: split into independent objectives, one instance each | | A count + theme | "launch 5 workers to each find a bug in X" | derive 5 distinct goal conditions over X | ## Step 0 — Discover the workspace layout, and the host's seat pool Run the doctor verb once and read the result. **Every path / lane / exit-code below comes from here, never a literal** (the WCR on-ramp — EXAMPLES.md Recipe 0). ```bash dos doctor --workspace . --json ``` The fields this skill uses: - `lanes` / `lanes.trees` — the lane taxonomy and each lane's file-tree, for the `dos arbitrate` co-launch check in Step 2. - `paths.plans_glob` / `stamp` — the host's plan grammar and ship-stamp convention, for the `dos verify` ship-witness in Step 5. - `git` — if `false`, the git-phase ship-witness (Step 5) has no history; every claimed ship resolves `source="none"`. Say so; do not silently pass it. - `runtime_hooks` — which runtimes already have `dos hook stop` wired (Step 3). **The seat pool (sizes the waves).** The wave size is the host's serving-account count — read it from the host's own account/seat command, **not** from any verb this kernel ships (DOS names no account mechanism). The skill needs one number, `SERVING` = how many worker seats can run concurrently right now: - **`SERVING == 0` (every seat walled)** → STOP. Do not launch a paid child into a standing usage wall. Report the soonest reset the host exposes and offer to schedule the launch for after it. - **`SERVING == 1`** → rotation is a no-op; launch serially or in a wave of 1, and warn the operator that all goals share one seat's window. - **`SERVING >= 2`** → proceed; wave size = `min(SERVING, total_goals, --max-concurrent)`. > **Account rotation is a host seam, not a DOS verb.** How launches spread across > a seat pool — round-robin cursor, per-launch origin overlay, whatever — is the > *host's* concern, wired into the launch command of Step 3. This skill only > requires that the host's launch verb rotates seats per instance; it names no > such mechanism itself. If the host has none, every child shares one seat — set > `SERVING = 1` and say so in the rollup. ## Step 1 — Derive one goal per objective (the three-clause contract) If the operator gave an explicit goal list, use it verbatim. Otherwise split the context into **independent objectives** — each must stand alone, no cross-goal dependency. For each objective write a goal **condition** stated as a *checkable effect*, obeying three clauses (this is what makes the child's "done" witnessable by `dos-goal-gate`, not self-certified): 1. **Deliverable as a visible effect** — a `(plan, phase)` the child will ship, a named file it will write, a commit it will land. State it as the thing a witness can later read back (`dos verify`, a fresh GET). **Never** "the work is good" — that has no byte-author but the worker. 2. *
Adjudicate a GitHub issue's "this is resolved" claim from witnesses the claimant didn't author — then close it carrying the evidence, or refuse with the typed gap. Use when an issue looks already-solved, after landing a fix that should have closed one, or to sweep open issues for silently-resolved ones.
Pick the next most important open GitHub issue this agent can actually complete, make its done-condition true, land it with witnesses (suite + parity + commit-audit), and priority-tag every issue touched along the way. Use when asked to "work the backlog", "complete the next most important issue", or to fix a specific issue number end-to-end.
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/<codename> git tag on the same commit. Does NOT bump versions or build new artifacts.
One automatic plan-class lifecycle tick. Reads the DECLARED class set + transition list from the workspace `[lifecycle]` table (not a hardcoded taxonomy), evaluates each trigger, spawns a read-only JUDGE-rung adjudicator (the `dos.judges` seam — advisory, fail-to-abstain) to approve/defer each candidate transition, applies the gated transitions as plan-meta edits + one commit per cycle, and logs to the run archive. Failsafes (per-cycle cap, per-plan cooldown, a veto class) are `[lifecycle]` data; the judge content is a host `dos.judges` driver. Every path/class comes from `dos doctor --json`. Use to garden a plan portfolio's lifecycle automatically, judge-gated. The DOS lifecycle gardener (SKP Axis 5, docs/207 Phase 5c).
Run /dos-dispatch on a recurring cadence, alternating with /dos-replan when the backlog drains — the dispatch→replan→dispatch cycle. The continue/stop/next-mode decision is the kernel's typed loop decision, not inline prose: each iteration is classified (`dos gate`) into a verdict and the loop's counters (drained-twice, the unclear/dirty-zero breakers, the iteration cap) drive the next step. Several loops on disjoint lanes run concurrently, each taking its own lane lease via `dos arbitrate`. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference loop workflow (SKP Axis 5).
End-to-end plan-and-ship for one lane — snapshot the portfolio with /dos-next-up, take a lane lease via `dos arbitrate` so parallel dispatches don't collide, gate the empty case via `dos gate`, ship the packet, and archive the run under the configured run dir. Driven entirely by `dos` verbs + the workspace's `dos.toml`; names no host path, lane, or commit convention. Use when you want to plan and ship the next batch on one lane in a single command, with concurrency safety. The DOS reference dispatch workflow (SKP Axis 5).
Ground a "keep working until the goal is met" stop condition in a witness the agent did not author, instead of letting the agent self-certify "done". A harness goal/Stop-hook condition is normally checked by the model re-reading its OWN work — consistency, not grounding. This skill turns the operator's goal into checkable EFFECT claims and wires `dos hook stop` so the Stop is refused until git ancestry (a shipped phase) or an effect read-back corroborates the claimed effect. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when you want a self-stopping agent (or a `/loop` worker) to be unable to declare a goal complete on its own say-so. The single-agent self-stop analogue of `dos-witness-claim`.