@openlife/cli 1.9.3 → 1.10.0

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

package/dist-templates/claude-code/commands/openlife/review.md

@@ -1,5 +1,5 @@
 ---
-description: Run the QA gate on a story (Sentinel) — 7-check verdict: PASS / CONCERNS / FAIL / WAIVED
+description: Run the QA gate on a story — host LLM acts as Sentinel and applies 7 quality checks
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,24 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate `@openlife-sentinel` (reads `.openlife/method/agents/sentinel.md`) and run `*qa-gate "$ARGUMENTS"`. Pass the story id or the file path as the argument. Report the verdict + structured findings.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Read `.openlife/method/agents/sentinel.md`, become Sentinel, and run `*qa-gate` on the target (story id or file path from `$ARGUMENTS`).
+
+Apply the 7 checks: code review, unit tests, AC coverage, no regressions, performance, security (OWASP-grade), documentation.
+
+Return verdict: PASS / CONCERNS / FAIL / WAIVED with structured findings (severity + category + file:line + recommendation per finding).
+
+If verdict is FAIL with HIGH/CRITICAL issues, suggest `/openlife:agents:builder` for the fix-loop iteration.
+
+---
+
+### 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 review "$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/claude-code/commands/openlife/ship.md

@@ -1,5 +1,5 @@
 ---
-description: Run the continuous-deployment workflow — release pipeline driven by Vortex
+description: Run the continuous-deployment pipeline — host LLM orchestrates Vortex through PR → merge → tag → publish
 allowed-tools:
   - Read
   - Write
@@ -11,4 +11,25 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Run `openlife flow run continuous-deployment "$ARGUMENTS"`. Vortex drives: pre-release QA, PR open, CI wait, merge, version bump, tag, publish. Maestro logs the release event at the end.
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Orchestrate the continuous-deployment workflow yourself.
+
+1. Read `dist-templates/workflows/continuous-deployment.yaml` to understand the phases
+2. Read `.openlife/method/agents/vortex.md` and become Vortex for steps that require the EXCLUSIVE git/PR/release authority
+3. Walk through: pre-release QA → open PR → wait CI → merge → version bump → tag → publish → release notes → log event
+4. EVERY destructive step (push, tag, publish) requires explicit user OK before proceeding — never auto-merge
+
+Vortex is the only persona authorized to push, open/merge PRs, and run releases.
+
+---
+
+### 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 ship "$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/claude-code/commands/openlife/start.md

@@ -11,15 +11,28 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Detect the project mode:
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Detect the project mode and route to the right workflow.
 
 1. Read `.openlife/project.json` if it exists. Use its `mode` field (`greenfield` / `brownfield` / `not-applicable`).
-2. If missing, ask the user via AskUserQuestion:
-   - "Is this a brand new project (greenfield) or existing codebase (brownfield)?"
-3. Based on the answer, recommend a workflow:
-   - greenfield + fullstack → `openlife flow run greenfield-fullstack`
-   - greenfield + service → `openlife flow run greenfield-service`
-   - greenfield + ui → `openlife flow run greenfield-ui`
-   - brownfield + first time → `openlife flow run brownfield-discovery`
+2. If missing, ask the user via AskUserQuestion: "Is this a brand new project (greenfield) or existing codebase (brownfield)?"
+3. Based on the answer, decide and announce the recommended workflow:
+   - greenfield + fullstack → run `/openlife:flow:greenfield-fullstack`
+   - greenfield + service → run `/openlife:flow:greenfield-service`
+   - greenfield + ui → run `/openlife:flow:greenfield-ui`
+   - brownfield + first time → run `/openlife:flow:brownfield-discovery`
    - brownfield + already discovered → ask sub-mode (fullstack/service/ui)
 4. If mode was just set, persist via `openlife project-mode set <mode>`.
+
+---
+
+### 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 start "$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/claude-code/commands/openlife/status.md

@@ -2,8 +2,6 @@
 description: Show OpenLife system status — installed profile, host, catalog counts, daemon state
 allowed-tools:
   - Read
-  - Write
-  - Edit
   - Bash(openlife:*)
   - Grep
   - Glob

package/dist-templates/claude-code/commands/openlife/story.md

@@ -1,5 +1,5 @@
 ---
-description: Create the next story from an epic (Conductor) or validate a draft (Steward)
+description: Create the next story (Conductor) or validate a draft (Steward) — host LLM acts as the right persona
 allowed-tools:
   - Read
   - Write
@@ -11,8 +11,24 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Determine intent from $ARGUMENTS:
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
 
-- If the user wants to CREATE a story → activate `@openlife-conductor` (reads `.openlife/method/agents/conductor.md`) and run `*create-next-story`.
-- If the user wants to VALIDATE a draft → activate `@openlife-steward` and run `*validate-story`.
+Determine intent from `$ARGUMENTS`:
+
+- If the user wants to CREATE a story → read `.openlife/method/agents/conductor.md`, become Conductor, run `*create-next-story`. Apply the story template (frontmatter, title, description, AC, scope, deps, complexity, business value, risks, DoD).
+- If the user wants to VALIDATE a draft → read `.openlife/method/agents/steward.md`, become Steward, run `*validate-story` with the 10-point checklist. Verdict: GO (≥7/10) or NO-GO (with required fixes).
 - If unclear, ask via AskUserQuestion which action to take.
+
+You play the persona directly — no shellout.
+
+---
+
+### 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 story "$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/agents/atlas.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Atlas** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Atlas** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/atlas.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Atlas** 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/builder.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Builder** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Builder** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/builder.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Builder** 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/conductor.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Conductor** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Conductor** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/conductor.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Conductor** 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/forge.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Forge** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Forge** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/forge.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Forge** 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/genesis.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Genesis** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Genesis** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/genesis.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Genesis** 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/lyra.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Lyra** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Lyra** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/lyra.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Lyra** 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/maestro.md

@@ -12,7 +12,9 @@ allowed-tools:
   - AskUserQuestion
 ---
 
-Activate **Maestro** from the OpenLife method.
+**Mode:** host-native — you (the host LLM) become **Maestro** for this conversation.
+
+Activation:
 
 1. Read `.openlife/method/agents/maestro.md` in full.
 2. Adopt the persona and execute the activation flow defined there:
@@ -22,3 +24,5 @@ Activate **Maestro** 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.