How does the orchestrator decide which domain skills to invoke?

It uses Step 3 - Domain Skill Routing, guided by the user intent signals and a routing matrix that maps complexity and required domains to specific skills.

What happens if a prerequisite gate fails?

The orchestrator halts execution, reports the missing prerequisites, and instructs the user or upstream skills to address the gaps before retrying.

What is a 'full-build' and how is it handled?

A full-build is a greenfield application requiring plan -> all domains -> devops -> infra; the orchestrator sequences every domain in the defined order and ensures gating at each stage.

orchestrator

npx machina-cli add skill mrsknetwork/supernova/orchestrator --openclaw

Files (1)

SKILL.md

4.5 KB

Orchestrator Skill

Purpose

The orchestrator is the air traffic controller of the Supernova system. It exists to solve a specific problem: vibe-coders ask for outcomes ("I want a user login system") without understanding what that entails. The orchestrator's job is to translate that intent into an ordered, coordinated sequence of domain skill activations - and to act as a hard gate preventing execution until prerequisites are met.

Progressive Disclosure

Load references/skill-matrix.md (when available) for the full skill-to-domain routing table.

SOP: Orchestration Workflow

Step 1 - Intent Classification

Receive the user's request and classify it along two axes:

Complexity:

simple: A single domain is affected (e.g., "fix this SQL query", "style this button").
compound: Multiple domains are affected (e.g., "add a checkout flow" = DB + API + Frontend + Security).
full-build: Greenfield application (requires plan -> all domains -> devops -> infra).

User Type (infer from language and context):

technical: Uses precise terminology, references files, provides stack context.
non-technical: Describes the idea, not the implementation. May not know what a "schema" is.

Adjust communication style accordingly. For non-technical users, avoid jargon in routing explanations.

Step 2 - Prerequisite Gate (Hard Rule)

Before dispatching any domain skill, check:

Has the plan skill been invoked and produced a checklist? If not, invoke it first.
Is the tech stack confirmed? If not, the plan skill must resolve it.
Is there a database schema for this feature? If the feature touches data, db skill runs before backend.
Is authentication required? security skill must define the auth strategy before api skill builds endpoints.

Do not skip this gate. An executor without a plan is how projects get rebuilt from scratch.

Step 3 - Domain Skill Routing

Use this matrix to determine which skills apply:

User Intent Signals	Skills Invoked	Order
"Build a new app / full stack"	plan, system-architecture, db, backend, api, frontend, ui-ux, security, devops	Sequential per phase
"I need an API endpoint / backend feature"	plan, db (if schema change), backend, api	Sequential
"I need a UI component / page"	plan, ui-ux (if new flow), frontend	Sequential
"I need a database / schema design"	plan, db	Sequential
"Review / audit the codebase"	audit	Standalone
"Write documentation for X"	docs	Standalone
"I want a deployment setup"	devops, infra	Sequential
"Summarize / report on status"	report	Standalone

When a request is compound, fan out to multiple domain skills but respect the dependency order: db must precede backend, backend + api must precede frontend.

Step 4 - Dispatch Log

After routing is decided, output a brief dispatch plan so the user understands what will happen:

Format:

Routing Plan for: [User Request]
User Type: [technical / non-technical]
Complexity: [simple / compound / full-build]

Dispatch Order:
1. plan - Define requirements and checklist
2. db - Design schema for [entities]
3. backend - Implement service and repository layers
4. api - Define [REST/GraphQL] endpoints
5. frontend - Build [components described]
6. security - Apply [auth/auth checks]

Step 5 - Error Recovery Protocol

If a domain skill fails or produces incomplete output, the orchestrator must:

Identify the failed step in the dispatch log.
Determine if the failure is a blocker for downstream skills (it usually is).
Re-invoke the failed skill with additional context before proceeding.
Never silently skip a step and continue.

Step 6 - Progress Tracking

After each domain skill completes, append its status to the dispatch log:

1. [x] plan - Checklist produced (8 tasks)
2. [x] db - `users` and `sessions` tables migrated
3. [/] backend - UserRepository complete, AuthService in progress
4. [ ] api - Pending backend

This log is the source of truth for what has been done and what is next.

Source

git clone https://github.com/mrsknetwork/supernova/blob/main/skills/orchestrator/SKILL.mdView on GitHub

Overview

The orchestrator acts as the air traffic controller for complex, multi-domain builds. It translates vague user intent into an ordered sequence of domain skill activations, enforces prerequisites with a hard gate, and coordinates the overall build workflow. Use it whenever a request spans multiple technical domains or when coordinating output from several skills.

How This Skill Works

It first classifies intent by complexity and user type, then enforces a prerequisite gate (planning, tech stack, schema, and auth as needed). Next, it routes to the appropriate domain skills in dependency order based on a routing matrix, and finally emits a dispatch log. If a step fails, it triggers the error recovery protocol to identify the failed step and halt safely.

When to Use It

When a user request spans multiple technical domains (e.g., building a SaaS app) and requires coordinated actions across plan, db, backend, frontend, or devops.
When coordinating output from multiple other skills and you need a single entry point to manage dependencies and flow.
When initiating a full-build (greenfield) project that requires plan, all domains, devops, and infra.
When a request involves an API, a UI component, and data schema changes that must be executed in a defined order.
When you need a clear dispatch plan and hard gate before any domain work begins.

Quick Start

Step 1: Route the user's request through the orchestrator to classify intent and complexity.
Step 2: Run the prerequisite gates (plan, tech stack, and schema/auth as needed) before any domain work.
Step 3: Dispatch domain skills in dependency order and present a Dispatch Log to the user.

Best Practices

Always route through the orchestrator first to ensure proper planning and gating.
Invoke the plan skill early and verify the checklist, tech stack, and schema before domain work.
Respect dependency order (e.g., db before backend, backend + api before frontend).
Provide a clear Dispatch Log to the user describing the planned execution order.
Implement and follow the error recovery protocol to gracefully handle failures.

Example Use Cases

A SaaS application build that coordinates plan, system architecture, db schema, backend services, API endpoints, frontend UI, and security, then deploys via devops.
Adding a new API endpoint that touches the database and updates the frontend, all orchestrated in the correct sequence.
Auditing a codebase where the orchestrator routes to the audit skill and reports findings as a standalone step.
Generating feature documentation after backend and UI implementations using a coordinated docs skill.
Setting up a complete deployment and infra pipeline for a greenfield project with sequential devops and infra steps.

Frequently Asked Questions

Add this skill to your agents