AI tools keep multiplying. Claude, Cursor, OpenClaw, Hermes, and OpenCode each have their own strengths and interaction patterns, but many of the tasks we want them to help with are not unique to one application.
That raises an interesting question: can a useful AI workflow travel between tools without pretending that every tool works the same way?
Separate the job from the wrapper
A reusable skill should begin with the task itself: its purpose, the inputs it needs, the steps it follows, the output it produces, and the conditions under which it should stop or ask for help. Those parts are the workflow’s core.
For example, a workflow definition can make the handoff and approval points explicit:
workflow:
input: validate
context: gather
proposal: show-user
side_effects: require-approval
report: summarize
Tool-specific instructions can then act as adapters. One assistant may load a skill from a directory, another may expect a command or a rules file, and a third may rely on a tool call. Keeping the core description and scripts independent makes it easier to translate the workflow without rewriting its intent.
Make the workflow inspectable
An automation is easier to trust when its steps are explicit. A simple sequence might be:
- Collect and validate the input.
- Gather relevant context.
- Propose the next action.
- Request approval for consequential changes.
- Execute and report what happened.
Scripts are useful for deterministic work such as formatting, validation, or moving data between systems. The model can help interpret ambiguous input, while ordinary code handles repeatable operations. Keeping those roles clear reduces surprises.
Portability is not sameness
The goal is not a universal prompt that magically fits every product. It is a well-defined workflow with thin, honest adapters for the tools that support it. Each integration should document what it can do, what it cannot do, and where a human needs to stay involved.
I’m exploring this space by building reusable skills, scripts, and full workflow automations. A good measure of progress is not how many tools are supported—it is whether the workflow remains understandable and dependable when it moves between them.