Composing Skills: When To Chain, When To Wrap, When NOT To

A single skill solves one workflow. Real work — shipping a feature, reviewing a release, onboarding a customer — is a chain of workflows. Composing skills is how an OpenClaw soul handles the chain. Done right, composition turns a portfolio of small skills into a force multiplier. Done badly, it produces fragile, expensive, and unobservable behavior.

Three composition patterns

Chaining: the simplest move

The simplest composition is a chain. The user asks for X, the soul fires Skill A, captures its output, and the user (or the soul, with explicit instruction) feeds the result into Skill B. Each skill stays simple and atomic. The chain lives in the conversation, not inside any one skill — which means you can debug it, replay any step, and swap pieces without rewriting.

Wrapping: orchestration as a skill

A wrapper skill is a skill whose procedure mostly calls other skills. The 'release' skill might call `run-tests`, then `bump-version`, then `release-notes`, then `tag-and-push`. The wrapper holds the order, the conditions, and the rollback logic. The wrapped skills stay general-purpose; the wrapper encodes a specific workflow.

• Wrappers shine when the order is non-obvious or condition-rich
• Wrappers should declare the union of permissions of their children — not blanket bash access
• Wrappers without rollback logic become foot-guns the moment a step fails
• If the wrapper is just 'do A then B', a conversational chain is simpler and easier to debug

When NOT to compose

1. 1When the workflow runs once a year — composing is a maintenance burden
2. 2When the steps share state in messy ways — explicit handoff in conversation is clearer
3. 3When debugging would require seeing each step's reasoning — composition hides traces
4. 4When the skills come from different publishers — every step inherits every publisher's risk
5. 5When you would not be able to explain the composed behavior to a teammate in three sentences

Recursion is almost always a bug

A skill that invokes itself, or a pair that mutually invoke each other, is a recursion hazard. Without explicit base cases the soul keeps spawning sub-tasks until it exhausts its context, its tokens, or your patience. OpenClaw allows recursion, but the responsibility for stopping it is yours. Most apparent uses of recursion are better expressed as a loop in the procedure — 'repeat steps 1-3 until the test suite passes' is finite and visible; 'invoke yourself with the failing test' is not.

Cost and latency tradeoffs

Apply: audit one composed workflow

1. 1Pick a workflow that already chains two or more skills in your team
2. 2Map it on paper: which skill, in what order, with what handoff
3. 3Ask: does it actually need composition, or is the conversational chain enough?
4. 4If it earns a wrapper — write the wrapper with explicit error handling and rollback steps, not just the happy path
5. 5Set a maximum step count or token budget; abort cleanly when exceeded
6. 6Test with one scripted failure per step — does the wrapper handle it, or does it cascade?

The big idea: chains are usually enough; wrappers earn their keep when orchestration logic is real; recursion is almost always a bug. Compose only when the workflow's stability and your team's tolerance for failure modes both justify the cost.