with one click
orchestration
// Use this skill to orchestrate multiple agents to resolve complex problems and achieve overarching goals.
// Use this skill to orchestrate multiple agents to resolve complex problems and achieve overarching goals.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | orchestration |
| description | Use this skill to orchestrate multiple agents to resolve complex problems and achieve overarching goals. |
The default orchestration workflow follows this sequence:
1. FINDER ──► Explore codebase, gather context, research dependencies
│
2. ORCHESTRATOR ──► Brainstorm with user interactively, explore ideas, converge on direction
│
3. PLAN DESCRIBER ──► Create detailed, step-by-step implementation roadmap
│ └── Also produces plan-manifest.json for verification
│
4. IMPLEMENTOR ──► Write code strictly following the plan
│
┌──────┴──────┐
▼ BUILD CHECK ▼ (MANDATORY)
│ Implementor MUST run build │
│ and return full build output│
└──────┬──────┘
│ (build fails → Implementor fixes, rebuilds)
▼
┌──────┴──────┐
▼ LINT GATE ▼ (MANDATORY if linter configured)
│ Implementor MUST run linter │
│ (eslint, prettier --check, │
│ tsc --noEmit, etc.) │
└──────┬──────┘
│ (lint fails → Implementor fixes, re-lints)
▼
5. QA ──► Test, validate, report results
│
┌──────┴──────┐
▼ SMOKE TEST ▼
│ QA runs smoke test to │
│ confirm app is runnable│
└──────┬──────┘
│
6. VERIFIER ──► Compare implementation against plan manifest
│ └── Structural checks (Pass 1)
│ └── Behavioral checks (Pass 2)
│ └── Produces compliance score + deviation report
│
┌──────┴──────┐
▼ FAILURE ▼ (score < 80% → Orchestrator reviews, may cycle back to Implementor)
│ Escalate to │
│ Orchestrator│
└──────┬──────┘
│
7. ORCHESTRATOR ──► Review all results, report to user
Every implementation MUST pass through two mandatory validation gates:
| Gate | Who Runs It | What It Checks | Failure Action |
|---|---|---|---|
| Build Gate | Implementor | Code compiles without errors (e.g., npm run build, tsc) | Implementor fixes and rebuilds before proceeding |
| Lint Gate | Implementor | Code passes linter/style checks (e.g., eslint, prettier --check, tsc --noEmit) | Implementor fixes lint errors before proceeding |
| Smoke Test | QA | Application boots/starts without crashing, or module loads cleanly | QA reports as Critical bug; Orchestrator cycles back to Implementor for fixes |
| Plan Verify | Verifier | Code matches plan-manifest.json checkpoints (structural + behavioral) | Score < 80% → Orchestrator reviews; may cycle back to Implementor or PlanDescriber |
Build Gate Protocol:
Smoke Test Protocol:
Lint Gate Protocol:
eslint, prettier --check, tsc --noEmit) after the build passesWhen passing work from one agent to the next, the Orchestrator MUST include:
Orchestrator to PlanDescriber:
"After brainstorming with the user, we've agreed on Option B (modular monolith approach).
Finder has analyzed the codebase (see files: src/services/user.ts, src/models/user.ts).
Please create a detailed implementation roadmap for adding user profile management,
following the code-philosophy and backend-code-philosophy skills.
Focus on: data models, service layer, and API endpoints."
When passing from QA to Verifier, include:
plan-manifest.json file produced by PlanDescriberExample:
Orchestrator to Verifier:
"The plan manifest is at plan-manifests/user-profile-manifest.json.
Implementation added UserService with createUser and getUser methods.
QA smoke test passed.
Please verify all checkpoints in the manifest and report the compliance score."
When QA discovers bugs or issues, use this iterative refinement cycle:
QA reports bugs ──► Orchestrator reviews ──► Implementor applies fixes ──► QA re-verifies
If the same bug resurfaces after 3 fix attempts, escalate back to PlanDescriber for roadmap revision.
When cycling back to Implementor, use task_id (ses_xxx) to preserve conversation context with the prior subagent session so the agent retains memory of the code it wrote.
The Orchestrator serves as the primary brainstorming partner for the user. This is by design:
The system includes a circuit breaker to prevent infinite agent loops:
| State | Meaning | Action |
|---|---|---|
| Closed | Normal operation | Agents execute as normal |
| Open | Repeated failures detected | Orchestrator pauses cycling to the same agent for the same issue |
| Half-Open | Probation period | Orchestrator allows one retry to test if the issue is resolved |
1. Agent task fails (build, lint, smoke test, or verification)
2. Orchestrator records the failure in a counter for that specific check
3. If counter < threshold (3), Orchestrator cycles back for retry
4. If counter >= threshold, Orchestrator opens the circuit:
a. Pauses further retries for that specific check
b. Escalates to PlanDescriber if the root cause is plan-related
c. Reports to user with failure summary and escalation decision
5. After PlanDescriber revises the plan, Orchestrator resets the circuit (Half-Open)
6. One retry is allowed — if it passes, circuit closes; if it fails, circuit opens again