directive

Execute Directive

Execute the CEO directive: $ARGUMENTS

Role Resolution — Read First

Before executing, read .claude/agent-registry.json to map roles to agent names. The pipeline uses role-based language throughout. Resolve roles to concrete agent names using the registry:

• COO = the agent with "title": "COO" (plans projects, orchestrates execution)
• CTO = the agent with "title": "CTO" (architecture, audits, reviews, technical decomposition)
• CPO = the agent with "title": "CPO" (product strategy, UX review, user perspective)
• CMO = the agent with "title": "CMO" (growth, SEO, content strategy)
• Frontend Developer = the agent with "title": "FE" (React, Tailwind, components)
• Backend Developer = the agent with "title": "BE" (server, API, infrastructure)
• Full-Stack Engineer = the agent with "title": "FS" (cross-domain work)
• Data Engineer = the agent with "title": "DE" (pipelines, parsers, indexing)
• Content Builder = the agent with "title": "CB" (MDX, documentation, copywriting)
• QA Engineer = the agent with "title": "QA" (testing, investigation, validation)
• UI/UX Designer = the agent with "title": "UX" (design review, wireframes, visual quality)

Use each agent's id field as the subagent_type value when spawning. Use the agentFile field to locate personality files. The registry is the single source of truth for who fills each role.

---

MANDATORY: Start with Triage — DO NOT SKIP

YOU MUST read and execute 00-delegation-and-triage.md BEFORE doing anything else.

DO NOT read source code. DO NOT edit files. DO NOT start solving the problem. The pipeline exists to ensure quality — every shortcut you take skips a review, a gate, or a verification step.

Your FIRST action must be: Read the triage doc, classify the directive weight, output the triage block, and create directive.json. Only then proceed to the next pipeline step.

If you catch yourself wanting to "just fix it quickly" — STOP. That impulse is exactly what the pipeline prevents. Even lightweight directives have a defined process (triage → context → audit → plan → build → review → digest → completion). The COO plans for ALL weights.

---

How to Use This Routing Map

This file is a routing table. Each row points to a modular doc containing full instructions for that step. Read only the docs you need for the current step — don't load everything at once.

Pipeline Progress Protocol

After completing each pipeline step, update .context/directives/{id}/directive.json:

1. Set pipeline.{stepId}.status to "completed" with:
   • agent: who performed this step (e.g. "CEO", "COO", "CTO, full-stack engineer")
   • output: REQUIRED object with at least a summary string (1-2 sentences of what happened/decided). Add other keys as relevant (e.g. decision, weight, projects).
   • artifacts: array of file paths produced (if any)
2. Set current_step to the next step's ID
3. Set updated_at to the current ISO timestamp
4. Use the Write tool to overwrite the full directive.json

When starting a step, set pipeline.{stepId}.status to "active" and pipeline.{stepId}.agent to the array of participating agent first names (lowercase, e.g. ["sarah", "marcus", "morgan"]). This is critical for the dashboard game view — the game reads step agents to route characters to the meeting room during brainstorm/plan/clarification steps. Without this, characters won't move.

Why output is mandatory: The dashboard renders pipeline step details directly from directive.json. Without output.summary, the UI shows empty steps — the CEO can't see what happened. Every step must leave a trace.

The server's directive-watcher reads directive.json directly (NOT current.json) and pushes pipeline state to the dashboard via WebSocket. Keeping pipeline updated is what makes the stepper UI show real-time progress.

Step Execution Loop

After completing a step and updating directive.json, immediately read the next step's doc from the routing table below and execute it. Do NOT stop, do NOT pause, do NOT ask for confirmation between steps. The pipeline is designed to run end-to-end in a single pass.

STOP gates — the only points where you must stop and wait for the CEO:

1. clarification — heavyweight/strategic: STOP and present synthesized intent for CEO verification. Lightweight/medium: still run the step (synthesize intent) but auto-approve without stopping. Do NOT skip this step — the verified_intent output feeds the COO planner.
2. approve — heavyweight/strategic: STOP and present plan for CEO approval. Lightweight/medium: auto-approve without stopping.
3. completion — all weights. The CEO must approve, amend, extend, or redirect the directive.

At every other step, transition directly to the next step without delay. If a step is skipped for the current weight class (brainstorm for lightweight/medium), set its status to "skipped" in directive.json and advance to the next step.

Pipeline Steps

Reference Docs — Schemas

Reference Docs — Templates

Reference Docs — Rules

Validation Scripts