@openlife/cli 1.9.3 → 1.10.0

package/dist-templates/codex/commands/openlife/agents/mesh.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Mesh** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Mesh** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/mesh.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Mesh** from the OpenLife method.
 3. If `$ARGUMENTS` is non-empty, treat it as an initial task or context for the persona.
 
 After the user's first `*command`, follow the persona's hand-off rules to suggest the next persona when appropriate.
+
+This activation does NOT use any external model — you ARE the agent. The OpenLife Brain (external model chain) is reserved for headless / CI usage via `openlife ask` in a terminal.

package/dist-templates/codex/commands/openlife/agents/prism.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Prism** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Prism** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/prism.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Prism** from the OpenLife method.
 3. If `$ARGUMENTS` is non-empty, treat it as an initial task or context for the persona.
 
 After the user's first `*command`, follow the persona's hand-off rules to suggest the next persona when appropriate.
+
+This activation does NOT use any external model — you ARE the agent. The OpenLife Brain (external model chain) is reserved for headless / CI usage via `openlife ask` in a terminal.

package/dist-templates/codex/commands/openlife/agents/sentinel.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Sentinel** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Sentinel** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/sentinel.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Sentinel** from the OpenLife method.
 3. If `$ARGUMENTS` is non-empty, treat it as an initial task or context for the persona.
 
 After the user's first `*command`, follow the persona's hand-off rules to suggest the next persona when appropriate.
+
+This activation does NOT use any external model — you ARE the agent. The OpenLife Brain (external model chain) is reserved for headless / CI usage via `openlife ask` in a terminal.

package/dist-templates/codex/commands/openlife/agents/steward.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Steward** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Steward** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/steward.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Steward** from the OpenLife method.
 3. If `$ARGUMENTS` is non-empty, treat it as an initial task or context for the persona.
 
 After the user's first `*command`, follow the persona's hand-off rules to suggest the next persona when appropriate.
+
+This activation does NOT use any external model — you ARE the agent. The OpenLife Brain (external model chain) is reserved for headless / CI usage via `openlife ask` in a terminal.

package/dist-templates/codex/commands/openlife/agents/vortex.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Vortex** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Vortex** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/vortex.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Vortex** from the OpenLife method.
 3. If `$ARGUMENTS` is non-empty, treat it as an initial task or context for the persona.
 
 After the user's first `*command`, follow the persona's hand-off rules to suggest the next persona when appropriate.
+
+This activation does NOT use any external model — you ARE the agent. The OpenLife Brain (external model chain) is reserved for headless / CI usage via `openlife ask` in a terminal.

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

@@ -1,5 +1,5 @@
 ---
-description: Ask the OpenLife Brain a question (uses primary/fallback model chain configured in models.json)
+description: Ask OpenLife — the host LLM answers directly using the OpenLife method context (no external API key required)
 argument-hint: "<question>"
 allowed-tools:
   - Read
@@ -12,9 +12,26 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife ask "$ARGUMENTS"` and return the Brain's answer.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
 
-Notes:
-- Uses the configured models.json chain (primary + fallbacks). If primary fails, it falls through.
-- The `OPENLIFE_ASK_TIMEOUT_MS` env var caps total time (default 90s).
-- If ask errors, report the error and suggest `openlife system doctor` to diagnose.
+Answer the user's question directly using your own reasoning. You ARE the OpenLife Brain when invoked through a host CLI.
+
+Optional context (read only when relevant to the question):
+- `.openlife/method/agents/lyra.md` — research / synthesis persona to adopt when the question is research-shaped
+- `.openlife/project.json` — current project mode (greenfield/brownfield)
+- `.catalog/` — user's agents, squads, skills, capabilities
+- `dist-templates/workflows/` — bundled method workflows
+
+If the question is open-ended or asks for OpenLife status, prefer answering from this conversation's existing context rather than reading files speculatively. If the user explicitly wants the external model chain (e.g., for batch / cron / cost-tracking reasons), they can invoke `openlife ask "..."` directly in a terminal or pass `--external` to this command.
+
+---
+
+### 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 ask "$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/audit.md

@@ -1,5 +1,5 @@
 ---
-description: Run brownfield-discovery — 10-phase audit of an existing codebase
+description: Run brownfield-discovery — host LLM orchestrates the 10-phase audit of an existing codebase
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,33 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run brownfield-discovery "$ARGUMENTS"`. The 10-phase audit produces architecture, schema, frontend specs, technical-debt assessment, and a backlog of remediation stories.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Orchestrate the brownfield-discovery workflow yourself, playing multiple personas inline.
+
+1. Read `dist-templates/workflows/brownfield-discovery.yaml` to understand the 10 phases
+2. Walk through:
+   - Phase 1 (Atlas): system-architecture.md
+   - Phase 2 (Mesh, conditional): SCHEMA.md + DB-AUDIT.md
+   - Phase 3 (Prism, conditional): frontend-spec.md
+   - Phase 4 (Atlas): technical-debt-DRAFT.md
+   - Phase 5 (Mesh): db-specialist-review.md
+   - Phase 6 (Prism): ux-specialist-review.md
+   - Phase 7 (Sentinel): qa-review.md (gate: APPROVED / NEEDS WORK)
+   - Phase 8 (Atlas): technical-debt-assessment.md (final)
+   - Phase 9 (Lyra): TECHNICAL-DEBT-REPORT.md (executive)
+   - Phase 10 (Genesis): Epic + stories ready for backlog
+
+Each phase ends with the user 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 audit "$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/doctor.md

@@ -2,8 +2,6 @@
 description: Run OpenLife health checks (API keys, model chain, runtime catalogs, daemon state)
 allowed-tools:
   - Read
-  - Write
-  - Edit
   - Bash(openlife:*)
   - Grep
   - Glob

package/dist-templates/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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/codex/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.