matteotitta Orchestrator
The orchestrator is a routing convention, not an executor.
Today: routing happens manually — the user types a slash command (/positioning, /aeo-content, /competitor-research), and that skill runs in the current session. When the user types something ambiguous ("help me launch this product"), the orchestrator surface is the catalog + ontology chain reference, and the operator picks the right entrypoint.
Tomorrow: the Agent / Workflow tools dispatch role-based agents to execute these same chains automatically, with locked-down state preserved across cycles. See .claude/rules/orchestration-patterns.md for the patterns + the tool-agnostic mechanics.
This file describes what the orchestrator IS, not what it DOES. The doing happens in the skills themselves.
What the orchestrator decides
When a user request maps to multiple possible skills, the orchestrator answers three questions:
- What is the user actually asking for? Map intent to an ontology output type (positioning, messaging, competitor-intel, etc.).
- What chain is this in? Look up the chain in
.claude/rules/ontology.md. Identify which step the user is at. - What's blocked vs ready? Check upstream skill outputs are present + locked-down for the current client. If not, route to the upstream skill first.
That's the entire decision space. Routing logic doesn't live in this file — it lives in the catalog (which lists every skill, owner, ontology type, gate) and the ontology (which lists every chain).
Routing reference — by user intent
| User intent | Primary chain | Entrypoint skill |
|---|---|---|
| New client engagement | New client (full) chain | /company-context |
| Competitive refresh | Competitive positioning refresh | /competitor-research |
| Content engine ramp-up | Content engine | /content-strategy |
| YouTube channel launch | YouTube channel launch | /youtube-strategy |
| Account prioritization (TAM scoring) | Account prioritization | /lead-scoring |
| Sales enablement build | Sales enablement | /battlecards |
For the canonical chain definitions (slugs and order), read .claude/rules/ontology.md. Don't duplicate them here — chains drift, and one source of truth prevents that.
Where decisions live
| Decision | Source of truth |
|---|---|
| Skill metadata (deps, gate, owner, ontology type) | .claude/skills/meta/catalog/skill-catalog/SKILL.md (auto-generated) |
| Chain definitions (which skill follows which) | .claude/rules/ontology.md |
| Locked-down state (which client outputs are canonical) | Per-client goals/, latest.md, and the status: field in skill outputs |
| Role-agent dispatch + lock-down state | .claude/rules/orchestration-patterns.md |
Add new skills by writing a SKILL.md under the right primitive folder. The catalog regenerates on commit; chain-lint surfaces broken edges. Don't update this orchestrator file unless the routing principle itself changes.
When NOT to invoke
- The user asks for a specific skill by name → run that skill directly.
- The user asks for a single artifact in isolation → just produce it.
- The user is mid-execution → finish the current step, don't re-route.
- The chain is one skill long → no orchestration needed.
Operational footer
DO NOT add new logic here without first updating ontology.md (chain definitions) or the catalog (skill metadata). The orchestrator describes; ontology + catalog prescribe. Aspirational pseudocode and "future state" architecture diagrams have been intentionally removed from this file (Phase 5, 2026-04-30) — orchestration patterns + mechanics now live in .claude/rules/orchestration-patterns.md.