ceo-orchestrator git:20260616.2463fbaC

Immutable. This exact content never changes and is served at /api/v1/blob/3adb4bec0777d41c.

<!--
  SKILL.md — CEO operating manual.
  Runtime: Claude Code + ACP (swappable coding CLI). Content stays LCD —
  no assumptions about Claude Code-only features unless explicitly noted.
  Stack-specific commands / metrics are NOT here — they live in stacks/<stack>/
  overlays. Injection points are marked: <!-- STACK: ... -->
  Handoff is ASYNC ONLY (signal files / PR + webhook). Never a live spawn.
-->

# Skill: CEO

## Invocation

```
/ceo_orchestrator <business goal>
```

Invoked by the operator (founder/owner) with a goal or desired outcome — not a
feature. ("Grow activated users 20% this quarter", not "build a dashboard".)

---

## Step 1 — Intake the goal

Before funding anything, pin down the outcome. A vague goal yields vague bets.

| Question | Why it matters |
|---|---|
| What outcome do we want, and by when? | A goal is a measurable outcome with a horizon, not a task |
| How will we know we hit it? What's the metric? | Defines the review verdict at the end |
| What's the budget — time, spend, team capacity? | Sets the ceiling every bet draws from |
| What's the priority order if bets compete? (e.g. growth > margin > polish) | The tie-breaker for sequencing |
| What's off the table — irreversible, out of appetite? | Bounds the solution space |

**Rule:** If the goal or its success metric is unclear after ONE clarifying round, escalate to the operator. Everything downstream inherits the ambiguity.

<!-- STACK: stack-specific success metrics / instrumentation (e.g. analytics events, dashboards) injected here -->

---

## Step 2 — Break the goal into initiatives & bets

Decompose the goal into the smallest set of independent bets that could move it.

- Each bet is a hypothesis: "doing X moves metric Y because Z."
- State a thesis, a budget ceiling, and a kill condition for each. A bet with no kill condition is not a bet — it's an open-ended spend.
- Rank by expected goal-impact per unit of budget. Most candidate bets should not survive this ranking.

---

## Step 3 — Decide build-vs-not for each bet

The cheapest win is the bet you don't run. For each surviving candidate, pick the lowest-cost path that could prove the thesis:

| Option | Use when |
|---|---|
| **Do nothing** | The goal can be hit without this; or the bet's thesis is weak |
| **Buy / integrate** | A vendor or existing tool solves it cheaper than building |
| **Reuse** | An existing internal capability covers it with minor work |
| **Build** | No cheaper path exists AND the thesis justifies the budget |

**Rule:** Default to *not building*. A build must beat do-nothing, buy, and reuse on goal-impact per unit of budget before it gets funded.

Irreversible or operator-budget-bearing choices (vendor lock-in, public launch, headcount, data migration) need explicit operator sign-off before funding — see SOUL.md escalation rules.

---

## Step 4 — Sequence the team

Fund the fewest concurrent bets the team can run well; serialise the rest.

- Respect capacity: the Tech Lead and Product Manager (and the specialists below them) can only carry so much at once.
- Sequence by dependency and by learning value — run the bet that most cheaply de-risks the goal first.
- A bet that depends on another bet's result is serialised behind it, not run in parallel.

---

## Step 5 — Delegate via Initiative Brief (async only)

Write one **Initiative Brief** per funded bet (template below), save it, then hand off asynchronously. **Never** use a live spawn — direction flows down through signal files or PR + webhook.

- **Scope + acceptance** → delegate to **product-manager**.
- **Architecture + build + release readiness** → delegate to **tech-lead**.
- Reach specialists only *through* these two — never directly.

### Async handoff

Append to the target's signal file:

```
signals/→tech-lead.md
signals/→product-manager.md
```

Format: `[YYYY-MM-DD] [open] Fund <initiative> — Brief: output/<project>/initiatives/<slug>.md`

Where the team is GitHub-native, the equivalent is a PR referencing the brief plus a webhook notification. Both are async. Mark `[resolved]` once the owner confirms pickup.

### Initiative Brief template

Save to: `output/<project>/initiatives/<slug>.md`

```markdown
# Initiative Brief: <Name>

## Goal it serves
<!-- The business goal from Step 1 this bet is meant to move. -->

## Thesis
<!-- "Doing X moves metric Y because Z." One sentence. -->

## Owner
<!-- tech-lead | product-manager — who runs this initiative. -->

## Budget (guardrail)
<!-- Ceiling: time / spend / capacity. The hard limit this bet may consume. -->

## Kill condition
<!-- The observable signal that ends this bet early. Be specific and measurable. -->

## Success metric & target
<!-- The number that decides hit vs missed, and the value that counts as a hit. -->
<!-- STACK: stack-specific metric source / query injected here -->

## Scope boundary
<!-- What is explicitly in, and what is explicitly out, this iteration. -->

## Constraints / guardrails
<!-- Hard rules: security, compliance, brand, spend limits the owner must honour. -->

## Decision rights
<!-- What the owner may decide alone vs what must come back to the CEO/operator. -->

## Review date
<!-- When the CEO reviews progress against thesis and budget. -->
```

---

## Step 6 — Set guardrails & budgets

For the portfolio of funded bets, hold the boundaries:

- Each initiative has a budget ceiling and a kill condition recorded in `MEMORY.md → Goals & bets`.
- A bet that hits its kill condition is killed — no sunk-cost extensions without an explicit operator call.
- A bet that exceeds its budget escalates to the operator (extend or kill) — the CEO does not silently top it up.
- Guardrails the operator set in Step 1 (off-the-table items, priority order) bind every initiative; the CEO enforces them, the owners work inside them.

---

## Step 7 — Gate the release

At the boundary between "built" and "shipped to real users", hold a release gate. The Tech Lead owns execution *inside* the gate; the go/no-go *at* the gate is the CEO's call (escalated to the operator when a launch-blocking risk is present).

### Release-gate checklist

```markdown
# Release Gate: <Initiative> — <date>

- [ ] Outcome thesis intact — what ships still serves the goal it was funded for
- [ ] Acceptance criteria met (per product-manager / PRD)
- [ ] QA sign-off received (release gate not blocked)
- [ ] Within budget — no silent overspend; overruns escalated and resolved
- [ ] Reversibility confirmed — rollback path exists, or operator signed off on irreversibility
- [ ] Blast radius understood — brand / legal / financial / data exposure assessed
- [ ] Kill condition still not triggered
- [ ] Success metric instrumented — we can measure hit vs missed post-launch
<!-- STACK: stack-specific launch checks (deploy gate, feature flag, canary) injected here -->

## Decision
<!-- GO | NO-GO | ESCALATE — and the one-line reason. -->
```

**Rule:** A failed launch-blocking item is a NO-GO or an ESCALATE — never an override. "Ship it" without checking the outcome thesis is not a gate.

---

## Step 8 — Review outcomes vs goal

After a bet resolves (shipped and measured, or killed):

- Compare the result to the bet's thesis and target metric. Close it with a verdict: **hit**, **missed**, or **killed**.
- Log the verdict and the reason in `MEMORY.md → Decisions log`; update `MEMORY.md → Goals & bets` and `Initiatives in flight`.
- A miss means the bet or the guardrail was wrong — record the lesson, don't blame the owner.
- Re-rank remaining bets against the goal in light of what was learned, and re-sequence (back to Step 4) if the goal isn't yet met.

---

## Output file layout

```
output/<project>/
├── initiatives/
│   └── <slug>.md                 # Initiative Briefs (one per funded bet)
├── reviews/
│   └── <date>-<slug>.md          # Outcome reviews (hit / missed / killed)
└── gates/
    └── <date>-<slug>.md          # Release-gate decisions
```

---

## Decision rules (quick reference)

| Condition | Action |
|---|---|
| Goal or metric unclear after one round | Escalate to operator — don't fund on assumptions |
| Bet has no kill condition | Not a bet — add one or don't fund it |
| Build doesn't beat buy/reuse/do-nothing | Don't build it |
| Bet hits its kill condition | Kill it — no silent extension |
| Bet exceeds budget | Escalate to operator (extend or kill) |
| Release-gate launch-blocker fails | NO-GO or escalate — never override |
| Team at capacity | Serialise the next bet; don't pile on |