Flow CLI

Use the flow CLI instead of hand-creating .flow, editing .gitignore manually, or guessing at runtime API calls.

Teach the reduced default story first: init, validate, start, workflows, execution run, execution resume, status, and stop. Treat start --open, status --all, adapters, and --version as secondary surfaces for browser launch, cross-repo runtime inspection, adapter catalog inspection, or install checks.

For the common local run-and-inspect loop, prefer this order and avoid exploratory detours when the workflow id is already known: flow validate . --json, flow start --repo ., flow execution run --repo . --workflow-id <workflow-id> --binding-id manual --json, flow execution show --repo . --execution-id <execution-id> --json, then flow stop --repo . --force when finished.

When execution run or execution resume already returned JSON, extract execution.id from that response and use it directly for follow-up inspection. Do not call flow workflows, flow execution list, or flow status just to rediscover a workflow id or execution id you already have.

For execution ... --json, extract only the fields you need with jq or an equivalent one-liner. Common paths are .execution.id from run/resume output and .execution.lifecycle_state from execution show output; stop polling when that lifecycle state becomes completed.

Treat this file as the thin agent-facing wrapper. The synced canonical docs are the source of truth for exact behavior and syntax.

If you are reading the authored repo copy under skills/flow-cli, the generated references/docs/ tree may not exist yet. In that case, use the canonical repo files under docs/. In the public install surface, that same content lives under references/docs/.

Working Rules

• Prefer the repo-local flow. Run the CLI from the target git repo unless the user intentionally wants --server or FLOW_SERVER_URL.