---
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.
