| name | directive |
| description | Execute work through the directive pipeline — evaluate, plan, cast agents, build, review, and report. Takes a directive name (matching .context/directives/), a project path, or an ad-hoc CEO request.
TRIGGER: Use this skill whenever the user requests non-trivial work that goes beyond a one-liner fix. This includes: building features, running projects with project.json, executing multiple tasks, multi-file changes, or any work with defined DOD/reviewers. Route through this pipeline so reviews and verification steps fire. Do NOT spawn builder agents directly.
For heavyweight/strategic work, create a directive file in .context/directives/ first. For medium work with an existing project.json, pass the project path. For quick multi-step tasks, pass an ad-hoc description — no directive file needed. |
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:
- 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)
- Set
current_step to the next step's ID
- Set
updated_at to the current ISO timestamp
- 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:
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.approve — heavyweight/strategic: STOP and present plan for CEO approval. Lightweight/medium: auto-approve without stopping.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
| # | Step ID | Doc | Purpose | Depends On |
|---|
| 1 | triage | 00-delegation-and-triage.md | Triage directive weight + select process | — |
| 2 | checkpoint | 01-checkpoint.md | Check for existing checkpoint, resume if found | — |
| 3 | read | 02-read-directive.md | Read directive file + create directive.json | triage |
| 4 | context | 03-read-context.md | Read all context files before planning | read |
| 5 | audit | 06-technical-audit.md | Technical codebase audit | context |
| 6 | brainstorm | 04-brainstorm.md | Approach brainstorm (includes challenge for heavyweight/strategic) | audit |
| 7 | clarification | 04b-clarification.md | Synthesize verified intent (auto-approve for lightweight/medium) | audit |
| 8 | plan | 05-planning.md | COO strategic planning | clarification |
| 9 | approve | 07-plan-approval.md | Present plan to CEO for approval | plan |
| 10 | project-brainstorm | 07b-project-brainstorm.md | CTO + builder decompose projects into tasks with DOD | approve |
| 11 | setup | 08-worktree-and-state.md | Worktree isolation + directive state init | project-brainstorm |
| 12 | execute | 09-execute-projects.md | Execute all tasks (phases, agents, UX) | setup |
| 13 | review-gate | 09-execute-projects.md | Review verification gate (end of doc) | execute |
| 14 | wrapup | 10-wrapup.md | OKRs, follow-ups, stale doc detection, digest, lessons, report | review-gate |
| 15 | completion | 11-completion-gate.md | CEO completion gate -- approve, amend, extend, or redirect | wrapup |
Reference Docs — Schemas
| Doc | Content |
|---|
| plan-schema.md | COO plan output JSON schema |
| audit-output.md | Architect output JSON schema (design recommendations — second phase of two-agent audit) |
| investigation-output.md | QA Engineer's investigation output JSON schema (pure data — first phase of two-agent audit) |
| checkpoint.md | Checkpoint JSON schema (deprecated — merged into directive-json.md) |
| directive-json.md | Directive JSON schema (THE source of truth — includes pipeline progress for dashboard) |
| brainstorm-output.md | Brainstorm output JSON schema (proposals + rebuttals + challenge) |
Reference Docs — Templates
Reference Docs — Rules
Validation Scripts
| Script | Content |
|---|
| validate-cast.sh | Mechanical casting validation — checks reviewer present, builder != reviewer, complex/moderate has C-suite reviewer, no self-review of own prompts, depends_on valid, no circular deps |
| validate-project-json.sh | Pre-execution gate — blocks execute step if project.json missing or incomplete (no tasks, no DOD, no scope) |
| detect-stale-docs.sh | Post-directive — scans docs for references to modified files, flags potentially stale docs |
| validate-gate.sh | Pipeline step gate — validates prerequisites before advancing to next step |
| validate-reviews.sh | Review-gate hard gate — blocks completion if reviews missing, detects self-review and self-certification |
