@openlife/cli 1.9.3 → 1.10.0

package/dist-templates/gemini-cli/commands/openlife/dream.md

@@ -1,5 +1,5 @@
 ---
-description: Run the OpenLife Dream Organizer — surfaces ideas, pending stories, and prioritization from accumulated context
+description: Dream Organizer — surface ideas, pending stories, and prioritization from accumulated context (host LLM answers directly)
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,25 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife dream "$ARGUMENTS"` to surface unprioritized ideas and stories from memory. Present the output grouped by theme.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Run the OpenLife Dream Organizer using your own reasoning, not an external model.
+
+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
+
+If the user wants the external model chain for richer ideation: `openlife dream "..."` in a terminal.
+
+---
+
+### 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/gemini-cli/commands/openlife/explore.md

@@ -1,5 +1,5 @@
 ---
-description: Exploratory ideation with Lyra — divergent brainstorming, then convergent narrative
+description: Exploratory ideation — host LLM acts as Lyra for divergent brainstorming then convergent narrative
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,22 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate `@openlife-lyra` (reads `.openlife/method/agents/lyra.md`) and run `*brainstorm "$ARGUMENTS"`. Surface options + tradeoffs. Do NOT commit to a plan in this command — that's `/openlife:plan`.
+**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/gemini-cli/commands/openlife/flow/brownfield-discovery.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run brownfield-discovery $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-discovery` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/brownfield-discovery.yaml` (or `.openlife/method/workflows/brownfield-discovery.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/brownfield-fullstack.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run brownfield-fullstack $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-fullstack` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/brownfield-fullstack.yaml` (or `.openlife/method/workflows/brownfield-fullstack.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/brownfield-service.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run brownfield-service $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-service` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/brownfield-service.yaml` (or `.openlife/method/workflows/brownfield-service.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/brownfield-ui.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run brownfield-ui $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `brownfield-ui` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/brownfield-ui.yaml` (or `.openlife/method/workflows/brownfield-ui.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/epic.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run epic-orchestration $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `epic-orchestration` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/epic-orchestration.yaml` (or `.openlife/method/workflows/epic-orchestration.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/greenfield-fullstack.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run greenfield-fullstack $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-fullstack` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/greenfield-fullstack.yaml` (or `.openlife/method/workflows/greenfield-fullstack.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/greenfield-service.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run greenfield-service $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-service` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/greenfield-service.yaml` (or `.openlife/method/workflows/greenfield-service.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/greenfield-ui.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run greenfield-ui $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `greenfield-ui` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/greenfield-ui.yaml` (or `.openlife/method/workflows/greenfield-ui.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/qa-loop.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run qa-loop $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `qa-loop` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/qa-loop.yaml` (or `.openlife/method/workflows/qa-loop.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/release.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run continuous-deployment $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `continuous-deployment` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/continuous-deployment.yaml` (or `.openlife/method/workflows/continuous-deployment.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/spec-pipeline.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run spec-pipeline $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `spec-pipeline` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/spec-pipeline.yaml` (or `.openlife/method/workflows/spec-pipeline.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/flow/story-cycle.md

@@ -10,11 +10,29 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run story-development-cycle $ARGUMENTS` and walk the user through the workflow as it executes.
+**Mode:** host-native — you (the host LLM) orchestrate the `story-development-cycle` workflow yourself, playing the personas as needed.
 
-- The workflow YAML is at `dist-templates/workflows/story-development-cycle.yaml` (or `.openlife/method/workflows/story-development-cycle.yaml` if locally overridden).
-- Each phase invokes one or more OpenLife method agents.
-- On any failure: surface the failing step + which agent is responsible, then offer to escalate to `@openlife-maestro`.
-- `--dry-run` prints the phase plan without executing.
+### Step 1 — Load the workflow definition
 
-Refer the user to the persona of the active phase when they ask "who is doing this?".
+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/gemini-cli/commands/openlife/health.md

@@ -1,5 +1,5 @@
 ---
-description: Extended health check — combines `doctor` with runtime diagnostics from Maestro
+description: Extended health check — combines `doctor` runtime check with Maestro's framework integrity review
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,27 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife system doctor` first, then activate `@openlife-maestro` and run `*health` to check cross-agent integrity (catalog completeness, missing handoff artifacts, draft components pending promotion).
+**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/gemini-cli/commands/openlife/plan.md

@@ -1,5 +1,5 @@
 ---
-description: Run the spec pipeline — gather requirements, assess complexity, write executable spec
+description: Run the spec pipeline (gather → assess → research → write → critique → plan) — host LLM orchestrates the 6 phases
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,28 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run spec-pipeline "$ARGUMENTS"`. The 6-phase pipeline: gather → assess → research → write → critique → plan. Walk the user through each phase's output.
+**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.