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:

1. What is the user actually asking for? Map intent to an ontology output type (positioning, messaging, competitor-intel, etc.).
2. What chain is this in? Look up the chain in .claude/rules/ontology.md. Identify which step the user is at.
3. 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.