How Workflows Orchestrate Multiple Skills
ClawFlows workflows compose skills into routines. Here's the architecture — how workflows call skills, pass state, and handle errors across steps.
The distinction between a skill and a workflow confuses people at first. Both do things. Both have names. Both run in response to invocations. What's the difference?
The short version: a skill is a capability. A workflow is a routine that composes multiple skills. A skill knows how to send an email. A workflow knows that "morning routine" means sending one specific email after reading a calendar after checking the weather. The skill is a verb; the workflow is a recipe.
This post digs into the architecture — how ClawFlows workflows actually orchestrate skills under the hood, how state flows between steps, and how errors propagate. Understanding this is the difference between being a workflow user and being a workflow designer.
Key Takeaways
- Skills are atomic capabilities — reusable units that do one thing well.
- Workflows are routines that compose skills into multi-step sequences.
- ClawFlows workflows pass state between steps using a shared context object.
- Error handling is explicit — each step can define what happens on failure.
- Understanding the architecture is how you go from user to designer of workflows.
The Skill Layer
A skill, in the OpenClaw and ClawFlows sense, is a self-contained capability. It has:
- A name and description
- A set of inputs it expects
- A set of outputs it produces
- Implementation (usually code, sometimes a prompt template)
- Metadata for discovery and permissions
Examples of skills: send-email, read-calendar, query-github, check-weather, fetch-rss. Each one does exactly one thing and doesn't know about the larger context in which it's being called.
This is deliberate. Skills are reusable precisely because they don't embed routine logic. The send-email skill doesn't know whether it's part of a morning briefing or a standup notification — it just sends an email when asked.
The Workflow Layer
A workflow sits above skills and orchestrates them. It has:
- A name and description
- A set of inputs (trip date, meeting type, focus duration, etc.)
- An ordered list of steps
- State that flows between steps
- Error handling and branching logic
- Output to one or more destinations
When you invoke a workflow, the runtime:
- Parses the workflow definition
- Initializes the shared state
- Executes each step in order, passing state forward
- Handles errors according to the workflow's error policy
- Returns the final output
Each step in a workflow is typically a call to one skill, with arguments derived from either the workflow's inputs or the state produced by previous steps.
A Concrete Example
Consider morning-briefing (profiled in Morning Briefing Workflow: Start Your Day Right). The workflow definition might look roughly like:
- Step 1: Call
read-calendarwith today's date. Store the result instate.calendar. - Step 2: Call
read-taskswith today's date. Store the result instate.tasks. - Step 3: Call
check-weatherwith the user's configured location. Store instate.weather. - Step 4: Call
fetch-newswith configured sources. Store instate.news. - Step 5: Call
compose-briefingwith all the state. Producesstate.briefing. - Step 6: Call
output-to-terminal(or email, or Slack) withstate.briefing.
Each of those is a skill invocation. The workflow is the glue that passes outputs forward and ensures they happen in the right order.
State Between Steps
ClawFlows workflows use a shared context object to pass state between steps. Each step reads from and writes to this context, which persists for the duration of the workflow run.
This is simpler than alternatives like message passing or return-value chaining, and it makes the flow explicit. A workflow author can see at a glance what state is available at each step.
It also means workflows are debuggable — you can inspect the context at any step to see what state exists.
Why Not Make Skills Directly Call Each Other?
Because that breaks reusability. If the read-calendar skill directly called compose-briefing, it would only be useful in a morning briefing workflow. By keeping skills independent and using workflows as the composition layer, each skill remains reusable across many workflows.
This is the same separation-of-concerns principle that works in software architecture generally. Skills are the modules; workflows are the main function that wires them together.
Error Handling
Each step in a workflow can declare what happens on failure:
- Abort — stop the workflow entirely
- Skip — skip this step and continue
- Retry — try again with configurable attempts and backoff
- Fallback — run a different step instead
- Log and continue — record the failure but keep going
A well-designed workflow uses these deliberately. For morning-briefing, the fetch-news step might use "log and continue" — you still get a briefing even if the news API is down. The read-calendar step might use "abort" because a briefing without calendar data is pointless.
This explicit error policy is what separates production-ready workflows from fragile scripts.
Branching and Conditional Logic
Workflows support conditional branching. A step can evaluate a condition and choose which subsequent step to run. This is how pre-trip-automation (covered in Travel Workflows: Pre-Trip Automation) handles different trip types — domestic vs international branches to different subsequent steps.
The conditional logic is usually simple (if/else on state values) because workflows aren't meant to be full programs. When you need complex logic, it belongs inside a skill, not inside the workflow definition.
Why This Architecture Works
The skill-workflow separation is a good design for a few reasons:
- Reusability compounds. Every new skill can be used in every new workflow. The value of the skill library grows multiplicatively.
- Testing is tractable. You test skills in isolation and test workflows as integration tests.
- Errors are localized. A failing skill only fails in the contexts where it's used, not across the whole system.
- Users can author workflows without writing code. Skills are code; workflows are structured data.
The last point is underrated. Because workflows are declarative, non-programmers can customize and author them. This dramatically broadens who can automate their own life.
Workflow Composition
Workflows can call other workflows. This is how complex routines stay manageable — you break a big routine into smaller named workflows and compose them.
For example, end-workday might call save-open-files, post-eod-summary, and log-hours — each of which is its own workflow that calls its own skills. The tree can nest as deep as needed.
This is another reason the architecture scales. Each workflow remains small and focused, and composition handles the complexity.
Comparison to Other Systems
How does this compare to other automation architectures?
- Shell scripts — imperative, brittle, no error policy, no state management. Workflows are significantly more robust.
- Zapier/Make — similar in spirit but proprietary and UI-based. ClawFlows workflows are text-based and version-controllable.
- GitHub Actions — similar structure but focused on CI/CD. ClawFlows covers personal and household automation.
- Cron jobs — good for scheduling, bad for composition. Workflows + cron is a powerful combination.
We explore the differences in depth in Workflows vs Cron Jobs vs Shell Scripts and Why ClawFlows Beats Zapier for Developers.
FAQ
Can I write a workflow without code?
Yes. Workflows are structured definitions, not code. You edit a text file (YAML or similar) and the runtime interprets it. Skills are where the code lives.
What language are skills written in?
Depends on the skill. OpenClaw skills can be shell scripts, Python, JavaScript, or prompt templates. The workflow runtime handles the dispatching.
Can skills call other skills?
Technically yes, but the convention is that skills stay atomic and workflows handle composition. Breaking this convention works but makes the system harder to understand.
How do I debug a workflow?
The ClawFlows runtime supports verbose mode that prints the state at each step. You can also set breakpoints (conceptually) by adding a log step anywhere.
Where do I learn more?
Start with the nikilster/clawflows README, then read a few workflow definitions in the repo. The architecture becomes obvious once you've seen three or four examples.
Design Your Own Workflows
Understanding the architecture is how you stop being a passive user and become someone who designs their own routines. The skill-workflow separation is elegant and productive — every hour you invest in learning it pays back across every workflow you ever author.
Install ClawFlows (see How to Install ClawFlows in One Command), read a few workflow definitions, and then write your first one. The architecture is designed to make this approachable.
Explore all 113 workflows at aiskill.market/workflows or submit your own.