@openlife/cli 1.8.3 → 1.10.0

package/dist-templates/claude-code/commands/openlife/agents/vortex.md

@@ -0,0 +1,28 @@
+---
+description: Activate Vortex — DevOps — EXCLUSIVE authority over git push, gh PR, MCP, releases
+argument-hint: "[optional context]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**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:
+   - Display the persona greeting (icon + 1-line role)
+   - Show the top 5 commands
+   - HALT and await `*command` from the user
+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/claude-code/commands/openlife/ask.md

@@ -1,14 +1,37 @@
 ---
-description: Ask the OpenLife Brain a question (uses primary/fallback model chain configured in models.json)
-argument-hint: <question>
-allowed-tools: Bash(openlife:*)
+description: Ask OpenLife — the host LLM answers directly using the OpenLife method context (no external API key required)
+argument-hint: "<question>"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - 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:
-- The Brain uses the configured `models.json` chain (primary + fallbacks). If the primary fails, it falls through automatically.
-- The `OPENLIFE_ASK_TIMEOUT_MS` env var caps the total time (default 90s).
-- If the user wants a specific model, suggest they edit `models.json` or set the env var — don't pass model flags inline (the `ask` command doesn't accept them).
+Answer the user's question directly using your own reasoning. You ARE the OpenLife Brain when invoked through a host CLI.
 
-After the answer comes back, present it cleanly to the user. If `ask` errors (timeout, all models failed), report the error and suggest `openlife system doctor` to diagnose.
+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/claude-code/commands/openlife/audit.md

@@ -0,0 +1,43 @@
+---
+description: Run brownfield-discovery — host LLM orchestrates the 10-phase audit of an existing codebase
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
+---
+
+**Mode:** host-native (the host LLM running this conversation answers directly — no external API key required).
+
+Orchestrate the 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/claude-code/commands/openlife/doctor.md

@@ -1,19 +1,14 @@
 ---
 description: Run OpenLife health checks (API keys, model chain, runtime catalogs, daemon state)
-allowed-tools: Bash(openlife:*)
+allowed-tools:
+  - Read
+  - Bash(openlife:*)
+  - Grep
+  - Glob
+  - Agent
+  - AskUserQuestion
 ---
 
-Run `openlife system doctor` and walk the user through the results.
+Run `openlife system doctor` and walk the user through results.
 
-For each failed check:
-1. Quote the failure line
-2. Explain in 1 sentence what the check verifies
-3. Suggest the concrete fix (usually setting an env var or running a follow-up command)
-
-Common failures and fixes:
-- **Missing `GEMINI_API_KEY` / `OPENAI_API_KEY` / `ANTHROPIC_API_KEY`** → add to `.env` at project root
-- **Missing `TELEGRAM_BOT_TOKEN`** → only required if profile is `autonomous`
-- **Catalog empty** → run `openlife system setup` (likely incomplete install)
-- **Ollama not reachable** → optional unless `OPENLIFE_ENABLE_OLLAMA=true`
-
-If everything passes, say so concisely — don't pad.
+For each failed check: quote the line, explain in 1 sentence what it verifies, suggest the concrete fix.

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

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

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

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

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

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

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

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

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

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

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

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

package/dist-templates/claude-code/commands/openlife/flow/epic.md

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

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

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

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

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

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

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

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

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

package/dist-templates/claude-code/commands/openlife/flow/release.md

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