multiagent-orchestration

name	multiagent-orchestration
description	Run a genuinely-parallel multiagent implementation with detailed guidance - plan, gate on environment, spawn subagents concurrently, aggregate, and debug/retry
languages	["all"]
subagents	["all"]
tools_needed	["read","glob"]

Instructions

Invoke this on demand ("run the multiagent implementation"). You (the host assistant) perform the orchestration using your own subagent-spawning primitives. prompticorn is a prompt/config generator, not an agent runtime — the parallelism is realized by you, the capable host, not by prompticorn. This skill composes (does not duplicate) the existing multi-agent-coordination, workflow-orchestration-patterns, and async-workflow-execution workflows; read those for the coordinator pattern, diagrams, and async model.

Two gates are non-negotiable: the environment-readiness gate (Step 4) and the plan-before-work approval gate (Step 5). Never spawn implementation lanes before both pass.

Step 1: Load conventions

Purpose: Every subagent must implement against the same rules.

• Locate and read all governing docs: coding standards, ADRs, naming, directory structure, security guidance, and test patterns.
• Confirm explicitly which docs loaded (list them).
• Flag gaps: any convention area with no doc is a risk to call out in the plan.

Step 2: Discover agents

Purpose: Know your roster before designing the pipeline.

• Enumerate the available agent prompts.
• Map each to a pipeline role: code, ATDD, TDD, verify, enforce, security, debug, PM/architect.
• Flag any role with no matching agent (a coverage gap for the plan's gap report).

Step 3: Design the execution model

Purpose: Maximize safe parallelism.

• Explicit dependencies: each agent/subagent declares what it depends on.
• Parallel by default: independent units run concurrently.
• Aggregator per phase: define the aggregator that collects a phase's outputs and gates the next phase. Reuse the coordinator pattern from multi-agent-coordination / workflow-orchestration-patterns rather than reinventing it.

Step 4: Environment-readiness gate (HARD)

Purpose: No lane starts against a dead dependency.

• A dedicated setup subagent identifies, starts, and health-checks every required service (DBs, queues, caches, external stubs) before any other lane is unblocked.
• The pipeline owns setup. Never instruct the human to start services.
• An unstartable service is a surfaced blocker — stop and report it, don't silently proceed with a degraded environment.

Step 5: Present the plan for approval (HARD gate)

Purpose: The human approves the shape of the run before any work happens.

Present, in one plan:

• Conventions loaded (from Step 1).
• Agent roster and role mapping (Step 2).
• Environment manifest (services + health checks, Step 4).
• A Mermaid execution map: env gate → parallel lanes → subagent spawn points → aggregation → sequential gates → debug/retry loop.
• Subagent specs (each unit's inputs, outputs, dependencies, owning agent).
• Convention-enforcement checkpoints (where the enforce/verify roles gate).
• Test strategy: ATDD before coding, TDD concurrent with coding.
• Gap report (roles/conventions/services with no coverage).
• Debug / retry / escalate logic.

Wait for explicit approval before Step 6.

Step 6: Concurrent execution on approval

Purpose: Realize the parallelism.

• Spawn all currently-unblocked subagents simultaneously.
• Unblock a downstream unit the moment its dependencies resolve — do not wait for a whole phase if a unit is ready.
• Aggregate at each gate; a gate advances only when its inputs are complete and pass enforcement.
• On failure, run the debug/retry loop; escalate a persistently-failing unit as a blocker rather than looping indefinitely.

Delegated background/isolated subagents must emit progress heartbeats per the core "Subagent Progress Heartbeats" convention so their status is observable.