How to Use OpenClaw ClawFlow — The Current Task Flow Guide

If you found an old OpenClaw note mentioning ClawFlow, do not build against that name. The official docs now redirect ClawFlow to Task Flow, and the CLI redirect is equally clear: flow commands live under openclaw tasks flow, not a standalone openclaw flows command. That sounds tiny, but it matters when you are writing automation that another operator will inherit later.

The 30-second answer

Use ClawFlow as a search term only. For current work, read and implement Task Flow. Task Flow is the durable workflow layer for multi-step jobs that need owner context, state, waits, and child task coordination. If a guide, script, or agent prompt says “ClawFlow,” translate it to Task Flow before you copy commands or config.

Use the current command surface

The documented CLI shape keeps flow inspection under the tasks command family. That makes sense because Task Flow is tied to the same background task ledger that tracks subagents, ACP runs, cron executions, and other detached work.

openclaw tasks flow list --json
openclaw tasks flow show <lookup>
openclaw tasks flow cancel <lookup>

Those commands are for inspection and control. They do not replace cron, heartbeat, or ordinary sessions. Cron and heartbeat decide when work runs; tasks and Task Flow help you understand what happened, what is still running, and what should be cancelled when a workflow goes sideways.

When Task Flow is the right tool

• A job needs to wait for an external reply, review, build, or deploy result.
• A parent task needs to spawn child work and summarize it later.
• You need durable state instead of hoping a chat session remembers everything.
• The work should survive handoff across heartbeats, cron runs, or detached agent sessions.

For simple one-shot reminders, cron is cleaner. For ambient “notice if something important changes” behavior, heartbeat is usually better. Task Flow shines when the work has a lifecycle: start, wait, resume, branch, complete, or cancel.

How I would migrate an old ClawFlow note

First, replace the name in the operator-facing docs so nobody keeps teaching the old term. Second, check every command example. If it says openclaw flows, treat it as stale and rewrite it to the documented openclaw tasks flow surface. Third, add a short note in the workflow file explaining what owns timing. If cron triggers the workflow, say that. If heartbeat resumes it, say that. Confusion usually appears when people mix scheduler, task ledger, and workflow state into one mental bucket.

Finally, inspect completed and failed work with the task ledger. openclaw tasks list, openclaw tasks show <lookup>, and openclaw tasks audit are the boring tools that save you from guessing why a detached run vanished.

If you are turning Task Flow into real operations instead of a demo, The OpenClaw Playbook is the shortcut I wish every operator had: identity files, memory rules, safety boundaries, channel discipline, and production habits in one field-tested guide.

Naming hygiene

The safest migration habit is boring: grep old runbooks, cron prompts, and workspace notes for ClawFlow before anyone copies them into a new workflow. Keep the old term as an alias in human explanation, but write current commands and file names with Task Flow. That avoids a slow split where half the team says ClawFlow and the other half debugs openclaw tasks flow.

Verification drill

After you migrate a workflow, inspect the flow list, inspect the underlying task record, and cancel a disposable test flow once so the operator path is rehearsed. You are proving two things: the workflow exists in the durable ledger, and the person on call knows which control surface stops it when the happy path gets stuck.

Operator checkpoint

Keep the first rollout narrow: one owner, one environment, one reversible test, and one written rollback note. Once the behavior matches the docs in that small setting, widen it deliberately. That habit prevents a useful OpenClaw feature from becoming another invisible system nobody knows how to debug. If the verification step is unclear, stop and tighten the runbook before you hand it to an autonomous agent.