@openlife/cli 1.8.3 → 1.10.0

package/dist-templates/codex/commands/openlife/dream.md

@@ -1,20 +1,35 @@
 ---
-description: Run the OpenLife Dream Organizer — surfaces ideas, pending stories, and prioritization from accumulated context
-allowed-tools: Bash(openlife:*)
+description: Dream Organizer — surface ideas, pending stories, and prioritization from accumulated context (host LLM answers directly)
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
 ---
 
-Run `openlife dream` (the Dream Organizer) and present the output as a ranked list of next actions for the user.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
 
-The Dream Organizer reads:
-- Conversation memory (last sessions)
-- Pending stories in `docs/stories/`
-- Open governance consents in `.openlife/governance-consents.json`
-- Mission state in `.openlife/`
+Run the OpenLife Dream Organizer using your own reasoning, not an external model.
 
-Format the output as:
+1. Read recent context from this conversation + any planning files the user has open
+2. Optionally read `.catalog/` for project-specific ideas already captured
+3. Surface unprioritized ideas, pending stories, and recommendations grouped by theme
+4. Be opinionated about priority order — don't return a flat list
 
-1. **Top 3 priorities** — the highest-signal items with one-line justification
-2. **Deferred** — items the Dream Organizer parked
-3. **Open questions** — anything the user needs to decide before work can proceed
+If the user wants the external model chain for richer ideation: `openlife dream "..."` in a terminal.
 
-Don't make up items the command didn't return.
+---
+
+### Want the external model chain instead?
+
+If you specifically need the configured `models.json` chain (for cost-tracking, batch, or non-host contexts), run the command in a terminal:
+
+```bash
+openlife dream "$ARGUMENTS"
+```
+
+That path uses the Brain dispatcher and requires the appropriate API key in `.env`. The slash command (this one) intentionally bypasses external APIs to keep host-CLI usage zero-config.

package/dist-templates/codex/commands/openlife/explore.md

@@ -0,0 +1,32 @@
+---
+description: Exploratory ideation — host LLM acts as Lyra for divergent brainstorming then convergent narrative
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Read `.openlife/method/agents/lyra.md`, become Lyra, and run `*brainstorm "$ARGUMENTS"`.
+
+Surface options + tradeoffs. Mark confidence per claim (high / medium / low). Cite sources when claims are non-obvious.
+
+Do NOT commit to a plan in this command — that's `/openlife:plan`. Explore is divergent; Plan is convergent.
+
+---
+
+### Want the external model chain instead?
+
+If you specifically need the configured `models.json` chain (for cost-tracking, batch, or non-host contexts), run the command in a terminal:
+
+```bash
+openlife explore "$ARGUMENTS"
+```
+
+That path uses the Brain dispatcher and requires the appropriate API key in `.env`. The slash command (this one) intentionally bypasses external APIs to keep host-CLI usage zero-config.

package/dist-templates/codex/commands/openlife/flow/brownfield-discovery.md

@@ -0,0 +1,38 @@
+---
+description: Brownfield Discovery: 10-phase audit of an existing codebase
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-discovery` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/brownfield-discovery.yaml` (project local override at `.openlife/method/workflows/brownfield-discovery.yaml` or `.catalog/workflows/brownfield-discovery.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run brownfield-discovery --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run brownfield-discovery "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/brownfield-fullstack.md

@@ -0,0 +1,38 @@
+---
+description: Brownfield Full-Stack: enhance an existing full-stack app
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-fullstack` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/brownfield-fullstack.yaml` (project local override at `.openlife/method/workflows/brownfield-fullstack.yaml` or `.catalog/workflows/brownfield-fullstack.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run brownfield-fullstack --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run brownfield-fullstack "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/brownfield-service.md

@@ -0,0 +1,38 @@
+---
+description: Brownfield Service: modify an existing service / API
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-service` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/brownfield-service.yaml` (project local override at `.openlife/method/workflows/brownfield-service.yaml` or `.catalog/workflows/brownfield-service.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run brownfield-service --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run brownfield-service "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/brownfield-ui.md

@@ -0,0 +1,38 @@
+---
+description: Brownfield UI: refactor or enhance an existing UI
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-ui` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/brownfield-ui.yaml` (project local override at `.openlife/method/workflows/brownfield-ui.yaml` or `.catalog/workflows/brownfield-ui.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run brownfield-ui --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run brownfield-ui "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/epic.md

@@ -0,0 +1,38 @@
+---
+description: Epic Orchestration: coordinate multiple dependent stories within an epic
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `epic-orchestration` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/epic-orchestration.yaml` (project local override at `.openlife/method/workflows/epic-orchestration.yaml` or `.catalog/workflows/epic-orchestration.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run epic-orchestration --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run epic-orchestration "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/greenfield-fullstack.md

@@ -0,0 +1,38 @@
+---
+description: Greenfield Full-Stack: end-to-end new app from concept to shippable stories
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-fullstack` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/greenfield-fullstack.yaml` (project local override at `.openlife/method/workflows/greenfield-fullstack.yaml` or `.catalog/workflows/greenfield-fullstack.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run greenfield-fullstack --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run greenfield-fullstack "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/greenfield-service.md

@@ -0,0 +1,38 @@
+---
+description: Greenfield Service: backend-only / API-only / CLI / worker / MCP server
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-service` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/greenfield-service.yaml` (project local override at `.openlife/method/workflows/greenfield-service.yaml` or `.catalog/workflows/greenfield-service.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run greenfield-service --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run greenfield-service "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/greenfield-ui.md

@@ -0,0 +1,38 @@
+---
+description: Greenfield UI: frontend-only / SPA / landing / admin panel / docs site
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-ui` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/greenfield-ui.yaml` (project local override at `.openlife/method/workflows/greenfield-ui.yaml` or `.catalog/workflows/greenfield-ui.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run greenfield-ui --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run greenfield-ui "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/qa-loop.md

@@ -0,0 +1,38 @@
+---
+description: QA Loop: iterative review-fix cycle (max 5 iterations) between Sentinel and Builder
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `qa-loop` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/qa-loop.yaml` (project local override at `.openlife/method/workflows/qa-loop.yaml` or `.catalog/workflows/qa-loop.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run qa-loop --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run qa-loop "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/release.md

@@ -0,0 +1,38 @@
+---
+description: Continuous Deployment: release pipeline driven by Vortex (PR → merge → tag → publish)
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `continuous-deployment` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/continuous-deployment.yaml` (project local override at `.openlife/method/workflows/continuous-deployment.yaml` or `.catalog/workflows/continuous-deployment.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run continuous-deployment --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run continuous-deployment "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/spec-pipeline.md

@@ -0,0 +1,38 @@
+---
+description: Spec Pipeline: 6-phase gather → assess → research → write → critique → plan
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `spec-pipeline` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/spec-pipeline.yaml` (project local override at `.openlife/method/workflows/spec-pipeline.yaml` or `.catalog/workflows/spec-pipeline.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run spec-pipeline --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run spec-pipeline "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/flow/story-cycle.md

@@ -0,0 +1,38 @@
+---
+description: Story Development Cycle: 4-phase Create → Validate → Implement → QA
+argument-hint: "[--dry-run] [--vars key=value]"
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native — you (the host LLM) orchestrate the `story-development-cycle` workflow yourself, playing the personas as needed.
+
+### Step 1 — Load the workflow definition
+
+Read `dist-templates/workflows/story-development-cycle.yaml` (project local override at `.openlife/method/workflows/story-development-cycle.yaml` or `.catalog/workflows/story-development-cycle.yaml` takes precedence if present).
+
+If `$ARGUMENTS` contains `--dry-run`, ALSO shell out to `openlife flow run story-development-cycle --dry-run` to print the phase plan, then STOP.
+
+### Step 2 — Walk the phases
+
+For each phase in the workflow's `sequence`:
+
+1. Announce which phase you're entering and which persona owns this phase (the `agent:` field on the step)
+2. Read `.openlife/method/agents/<persona-id>.md` for the active persona — adopt that persona for this phase
+3. Execute the step's `action` using the persona's discipline (commands, hand-off rules, anti-patterns)
+4. Produce the artifacts listed in `creates:` — write them to the paths declared in the YAML
+5. If `elicit: true`, ask the user via AskUserQuestion before proceeding
+6. Hand off to the next phase's persona; announce the handoff
+
+### Step 3 — Surface failures explicitly
+
+On any step failure: identify the failing step, the active persona, and offer to escalate to `@openlife-maestro` (read `.openlife/method/agents/maestro.md`).
+
+### Why host-native, not shell?
+
+Running the workflow this way uses your reasoning (the host LLM) instead of the external Brain chain. Zero API key needed for orchestration. If the user wants the external Brain to drive (headless / batch / cron), they can run `openlife flow run story-development-cycle "$ARGUMENTS"` in a terminal.

package/dist-templates/codex/commands/openlife/health.md

@@ -0,0 +1,37 @@
+---
+description: Extended health check — combines `doctor` runtime check with Maestro's framework integrity review
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Two-step health check:
+
+1. Run `openlife system doctor` (real shell command) to capture API keys, model chain, catalog state, daemon state
+2. Read `.openlife/method/agents/maestro.md`, become Maestro, and check cross-agent integrity:
+   - Catalog completeness (314 agents / 46 squads / 55 skills present?)
+   - Missing handoff artifacts in `.openlife/handoffs/`
+   - Draft components pending promotion in `.catalog/{agents,squads,skills}/<id>/` with `status: draft`
+   - Any contradictions between `.openlife/project.json` mode and active workflow
+
+Present both diagnostics in one consolidated report.
+
+---
+
+### Want the external model chain instead?
+
+If you specifically need the configured `models.json` chain (for cost-tracking, batch, or non-host contexts), run the command in a terminal:
+
+```bash
+openlife health "$ARGUMENTS"
+```
+
+That path uses the Brain dispatcher and requires the appropriate API key in `.env`. The slash command (this one) intentionally bypasses external APIs to keep host-CLI usage zero-config.

package/dist-templates/codex/commands/openlife/plan.md

@@ -0,0 +1,38 @@
+---
+description: Run the spec pipeline (gather → assess → research → write → critique → plan) — host LLM orchestrates the 6 phases
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Orchestrate the spec-pipeline workflow YOURSELF, phase by phase. You play multiple personas inline.
+
+1. Read `dist-templates/workflows/spec-pipeline.yaml` to understand the phases
+2. Phase 1 — Gather: become @openlife-genesis (read `.openlife/method/agents/genesis.md`) and elicit requirements from the user via AskUserQuestion
+3. Phase 2 — Assess: become @openlife-atlas, score the 5 complexity dimensions
+4. Phase 3 — Research (skip if SIMPLE complexity): become @openlife-lyra, surface unknowns
+5. Phase 4 — Write: become @openlife-genesis again, draft spec.md
+6. Phase 5 — Critique: become @openlife-sentinel, return verdict (APPROVED / NEEDS_REVISION / BLOCKED)
+7. Phase 6 — Plan: become @openlife-atlas, generate implementation.yaml
+
+Each phase ends with the user explicitly OK'ing before the next.
+
+---
+
+### Want the external model chain instead?
+
+If you specifically need the configured `models.json` chain (for cost-tracking, batch, or non-host contexts), run the command in a terminal:
+
+```bash
+openlife plan "$ARGUMENTS"
+```
+
+That path uses the Brain dispatcher and requires the appropriate API key in `.env`. The slash command (this one) intentionally bypasses external APIs to keep host-CLI usage zero-config.