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:

1. Identify the failed step in the dispatch log.
2. Determine if the failure is a blocker for downstream skills (it usually is).
3. Re-invoke the failed skill with additional context before proceeding.
4. 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.