4 OpenClaw layers: commands, hooks, skills, workflows

If your agent setup got messy, the cause is usually misplaced logic rather than missing features. Commands, hooks, skills, and workflows each answer a different question, and the answers do not overlap. This article walks through each layer, the mistake that shows up most often, and the four questions that tell you where a new piece of logic belongs.

OpenClaw commands, hooks, skills, and workflows in one pass

OpenClaw commands, hooks, skills, and workflows are four layers with different jobs: a command starts something directly, a hook reacts to an event, a skill holds reusable know-how, and a workflow connects steps into one repeatable process. Keeping them separate is what makes an agent setup easier to maintain.

The four layers map cleanly onto four questions. Do you want to start it directly? That is a command. Should it react automatically? That is a hook. Does it need reusable know-how? That is a skill. Does it span multiple stages? That is a workflow. The distinctions hold regardless of how big the setup later becomes.

The layering also has an ownership rule. A workflow is usually the top-level structure, a command might start a workflow, a hook might trigger one part of it automatically, and a skill gets used inside the workflow steps. Each layer calls into the next rather than absorbing it.

What a command should do, and where it usually goes wrong

A command is the direct trigger you use when you want to start something yourself. Briefing, video backup, and status are the kinds of entry points that fit, and the transcript's core advice is that a command should stay an entry point rather than becoming the architecture.

The recurring mistake is stuffing too much logic into the command itself. Once the command passes everything, decides everything, and executes everything, it becomes harder to maintain, reuse, and extend. A better pattern is simple: the command starts the process, and the real work lives in a skill or a workflow.

That split pays off the first time you want the same work started from somewhere else. A command that only triggers can be reused from a message, a schedule, or another step without rewriting the logic underneath it.

Technically, in the setup described in the video, commands mostly live in the gateway service. That placement matches the role: the gateway is where an incoming request or an operator action enters the system, so it is where a trigger belongs.

How OpenClaw hooks differ from skills

A hook is the event-driven layer: it reacts to something happening rather than being started by hand. OpenClaw splits hooks into two kinds, internal hooks that react to things happening inside OpenClaw and external hooks, which are webhooks where another system sends an HTTP request in from the outside.

Internal hooks live as hook folders, while external hooks live as webhook mappings in config. Both are triggers, and that shared job is why the failure mode looks the same in both cases. The mistake is a hook that starts doing too much.

Once a hook makes too many decisions, handles a lot of branching logic, or coordinates multiple follow-up steps, it is carrying the wrong responsibility. The hook should be the trigger, not the whole system. Decisions and follow-up steps belong in a skill or a workflow.

The practical test is whether you could describe the hook in one sentence without the word 'and' appearing twice. If the description keeps growing, the logic has outgrown the layer.

Where reusable know-how belongs: the skill layer

A skill is what you use when the agent needs reusable know-how. Method guardrails, best practices, and domain knowledge belong in a skill, which is the layer that answers how a task should be solved well rather than when it should run.

The signal to promote something into a skill is repetition. If you keep repeating the same playbook, it should probably become a skill. Skills live as folders containing a skill.md file, which keeps the method itself separate from the trigger that started it.

Skills also travel well. A method stored in a skill can be called from several commands or workflow steps, and improving it once improves every place that uses it. That is the return on keeping method out of the trigger.

This is the layer people skip when they are moving fast, and it shows up later as inconsistency. The same task gets done slightly differently each time because the method exists only in the prompts and habits of whoever set the system up.

What a workflow adds that a skill does not

A workflow is what you use when a job spans multiple connected steps. It turns a sequence such as a video pipeline, inbox triage, or a morning briefing into one repeatable system rather than a set of separate tasks you assemble by hand each time.

Workflows usually show up as structured multi-step systems, whether that is cron jobs, task flow, or orchestration files. A workflow is often the top-level structure, which is why the other three layers tend to hang off it: a command starts it, a hook can trigger one part automatically, and skills run inside its steps.

The test is span, not importance. A single task does not need a workflow even if it matters a lot, and a sequence of three trivial steps does need one if it has to happen the same way every time.

How the four layers fit together in practice

The layers connect in one direction, and that direction is what makes the whole system easier to reason about. A command starts the process, a hook reacts to events, a skill handles the repeatable method, and the workflow defines the sequence.

It helps to look at how a good setup differs from a bad one, because the failure is usually structural rather than a missing feature.

The four questions that decide which layer you need

If you only remember one part of this, remember the decision sequence. It resolves most placement questions in a few seconds and stops you from building a command that should have been a workflow.

1. Do you want to start it directly? Then it is probably a command. 2. Should it react automatically? That is a hook. 3. Does it need reusable know-how? That is a skill. 4. Does it span multiple stages? Then it probably needs a workflow.

The order matters. Test the trigger question first, because a direct entry point is the cheapest thing to build, and only escalate to a workflow when the job genuinely crosses stages. Building a workflow for a single trigger adds structure with nothing to hold.

How OpenClaw's layering compares with other agent setups

The separation is not unique to OpenClaw. Claude, Anthropic AI assistant, also separates commands, hooks, and reusable playbooks, and OpenAI approaches the same ground in terms of instructions, tools, and knowledge. The difference is emphasis.

The table below compares how each stack names the same four jobs. It compares vocabulary and structure, not benchmarked performance, because the video offers no measurements for any of the three.

Recap and common questions

The recap is short: a command starts work directly, a hook reacts to an event, a skill defines how work gets done well, and a workflow connects multiple steps into one repeatable system. Better results come from putting the right logic in the right layer.

If you have an agent setup that grew organically, the fastest audit is to look for a command that does everything and a hook that duplicates part of it. Those two symptoms usually mean the skill layer is missing and the workflow exists only in your head.

OpenClaw commands, hooks, skills, and workflows: FAQ

• What is the difference between a command and a hook in OpenClaw? A command is a direct trigger you start yourself, such as a briefing or a status check. A hook reacts to an event instead, either an internal event inside OpenClaw or an external webhook arriving from another system. The distinction is who initiates the action.

• When should a command become a skill? When the command has started deciding how the work should be done. If you are repeating the same method or playbook, that method belongs in a skill and the command should only start the process. This keeps the trigger small and the method reusable.

• What are the two kinds of OpenClaw hooks? Internal hooks react to things happening inside OpenClaw, and external hooks are webhooks where another system sends an HTTP request in from outside. Internal hooks live as hook folders, while external hooks appear as webhook mappings in config.

• Where do skills live in OpenClaw? Skills live as folders containing a skill.md file. That format keeps reusable know-how, method guardrails, and domain knowledge in one place that several commands or workflow steps can call on.

• Does a workflow replace commands, hooks, and skills? No. A workflow is often the top-level structure, and the other layers attach to it: a command can start it, a hook can trigger one part of it, and skills run inside its steps. They operate at different levels rather than competing.

• What is the most common mistake in an OpenClaw setup? Cramming too much logic into one layer. A command that passes, decides, and executes everything, or a hook that handles branching and follow-up steps, becomes hard to maintain. Each layer should do its own job and hand off the rest.

• Which layer should handle a morning briefing? A morning briefing is a sequence, so it fits a workflow, with a command available as the direct entry point if you want to start it by hand. The briefing steps themselves can call skills where a repeatable method is involved.

• How do you decide which layer to use for a new piece of logic? Ask four questions in order: do you want to start it directly, should it react automatically, does it need reusable know-how, and does it span multiple stages. The first question that fits points to the layer: command, hook, skill, or workflow.

• Does the same layer split apply outside OpenClaw? The specific terms vary between agent platforms, but the underlying jobs of trigger, event reaction, reusable method, and orchestration show up elsewhere too. Platforms differ mainly in how explicitly they expose those layers to the person configuring the agent.

Sending what you already know into a form people can search

The four layers in this article exist because the same work kept repeating. A command that starts a briefing, a skill that holds the method, a workflow that runs the sequence, and the logic lives in one place instead of being rebuilt each time. Video explanations tend to work the same way, so if you have already recorded a walkthrough of how you structure your own agent setup, that recording is the raw material.

Skalablog turns a YouTube video into a written article: paste the video URL, let it transcribe the audio, and get a structured draft you can review and publish. If your explanation is sitting in a video that search engines cannot read, that is the gap it closes.

Source video