A Cascade workflow is a Markdown file in .windsurf/workflows that a human launches by hand with a slash command; the documentation caps it at 12,000 characters. It described a repeatable trajectory well: a sequence of steps and prompts at the level of the whole task. But in Devin Local the recommended form of repeatable knowledge is not a workflow but a skill, and the move between them is not renaming a file.
The naive move is to copy the workflow's text into a skill or, worse, into a single always-on rule and consider the migration done. Since it is Markdown with steps there and Markdown with steps here, it seems enough to change the folder. The expectation is natural: the format is similar, so the behavior will carry over on its own.
It breaks on the fact that a workflow and a skill are different contracts, not different syntax. A workflow launches only manually and only as a whole; a skill is loaded on demand by its description and triggers, when it is appropriate. A long workflow pasted as an always-on rule hangs in the context permanently, bloats it and fires when it is not needed. A mechanical move preserves the letters and loses the control. The 12,000-character limit of a workflow is an indirect sign of the same thing: it was conceived as a long scenario taken whole, not as a compact skill for a specific trigger.
Hence the way to migrate: split what is fused into one text in a workflow. Instructions separately (what to do), tools separately (with what), permissions separately (what is allowed without asking). Add frontmatter, a precise description of the result and explicit triggers by which the skill is loaded, and build in a check - how to make sure the skill worked. The skill becomes an executable contract with clear inputs and outputs, not free-form text. Triggers are what a workflow did not have at all: it waited for a manual call, while a skill declares by itself under what conditions it is appropriate, and the agent loads it without a reminder. So the result description and the triggers matter more than the migrated text of the steps: without them the skill stays the same manual workflow, only in a new folder.
You do not have to do this by hand. For the move there is the Devin: Open Cascade Migration Wizard command - it guides a workflow into a skill step by step. The wizard removes the mechanical part but does not think for you: the decision of what stays from the old workflow, what is split into parts and what is deleted is still made by the engineer.
A migration is also an occasion to clear out rituals. A team's workflow often accumulates steps that have long stopped affecting the result or duplicate what CI already does. If a step changes nothing or repeats a check from the pipeline, it is excluded, not migrated. Typical candidates for cleanup are steps like "remind to run the linter" or "do not forget to run the tests", which in a mature project the pipeline already does; duplicating them in a skill means dragging distrust of CI into a new environment instead of relying on automation. A skill should be an executable contract, not an archive of the team's history.
Why Devin Local leads to skills rather than keeping workflows. A skill is loaded on demand, so it does not occupy the context until needed; it has a result description and triggers, so the agent itself understands when to apply it; it separates instructions and permissions, so it fits the new agent's permission model. The Cascade-era workflow could do none of this - it was text meant for a manual launch.
The cost of a mechanical move is concrete. A long workflow copied whole as an always-on rule weighs down every turn and gets in the way rather than helping. Preserved ritual steps reproduce the old sluggishness in a new environment. The separation of permissions lost during copying means the skill asks for confirmation in the wrong place or, conversely, acts more freely than intended. A bad migration is costlier than no migration.
You should check the migration by running it, not by reading it. Whether the skill fired by its own triggers, without a manual call. Whether it gives the declared result - the one described in the frontmatter. Whether it hangs in the context when it is not needed. Whether the instructions fit a reasonable size instead of the former 12,000 characters in one lump. A skill that cannot be checked by a run is not fully migrated.
The typical failure is to move the form and lose the meaning. "The skill does not launch on its own" - because it has no explicit triggers, the manual launch stayed from the workflow. "The context is bloated" - because a long workflow was laid down as an always-on rule. "The skill does extra work" - because ritual steps were moved verbatim along with the working ones. The sign is the same: the workflow was copied, not rethought. First split instructions, tools and permissions and ask which step actually affects the result - the rest will fall away on its own.