agent_spinner

agent_spinner

<agent_spinner_skill>

<when_to_activate> Activate when the orchestration decision belongs to the orchestrator:

• "Fan this out across the files" / "run several agents on this" / "spawn parallel helpers for these items."
• "Split the review into lenses" / "have a second agent check the first one's work" / "add a verifier pass."
• "How many helpers should this take?" / "how do I keep two writers off the same file?"
• "One of the helpers came back empty" / "a helper hung" / "merge what the helpers reported."

Route a request naming the task backlog to the task_* family and a request naming the wiki to wiki_fix. Route every concrete per-harness question, meaning which delegation surface a target exposes and how a role registers on it, to harness_portability, which owns those facts under its own re-verification rule. </when_to_activate>

<invocation_boundary> A run already governed by a named skill keeps that skill's orchestration contract. Where that skill states its own loop bounds, helper-failure policy, verification standard, aggregation rule, or stop-and-ask boundary, this skill adds nothing to that run and overrides nothing in it. Read agent_spinner for a request about running helpers in general, or for a job no shipped family owns. The shipped families stay worked instances of this shape at different sizes: cite them for illustration, and leave authority over their runs with them. </invocation_boundary>

<capability_probe> Establish callability, never infer it. A role definition on disk is evidence that the file deployed, not evidence that it can be called: definition-present-and-uncallable is a real state, so a registration check reporting a definition as available settles deployment alone. Establish callability through the host's own spawnable-role surface, and where the host advertises none, record the delegation surface as absent however many definitions are present.

Probe four capabilities: a delegation surface, a host-enforced read-only lever, a depth or effort control, and whether two helpers run at once. Resolve a capability that resists establishment to absent, and open the run by naming which capabilities you established and which you assumed away. </capability_probe>

1. Inline floor: a sequence of separately prompted passes performed inline in one context, each opening on its own brief and closing on its own return contract.
2. Spawned roles: each pass runs in its own context.
3. Enforced read-only: the host, rather than the prompt alone, holds a reading pass to reads.
4. Depth pin: the adversarial pass runs at a fixed depth.
5. Concurrent fan-out: independent helpers run at once.

Write every guarantee to hold at the floor, so no step depends on a fresh context, an isolated tool set, or a process boundary. Coverage is therefore counted in independent looks rather than in simultaneity, and the run claims no wall-clock benefit from fan-out.

The inline floor is the floor for a run the orchestrator owns outright. Where a governing skill states its own stop-and-ask boundary for a host with no spawn surface, honour that boundary, offer that skill's manual routes, and perform no helper role inline, as <invocation_boundary> already establishes.