OpenWork has published a command that helps people bring their Claude Cowork setup into a different assistant. The October 5 merge in different-ai/openwork adds discovery, preview and import for supported plugin marketplaces, plus the instruction text of personal Cowork skills. Its public migration guide tells an agent how to carry out the move.
The downloadable command is already there: on October 5, we fetched the public CLI and confirmed that it exactly matched the inspected source revision. That establishes more than a proposed interface. It does not establish that a real account's complete migration succeeds; our execution check covered discovery using synthetic local files.
For someone who has spent time teaching an assistant how to prepare a weekly report or organize project work, switching products means more than choosing another model. There is setup worth keeping. OpenWork is making some of that investment easier to carry into its own environment, while leaving service access and task execution to be established separately.
The new part is the move, not the file format
OpenWork's August 8 migration guide already described compatible plugins and copying skill directories. Reusable instructions are not new here. What changes is the work needed to find and import them: the new command assembles steps that previously required manual copying or separate API calls.
The implementation first reads Cowork's marketplace records and personal-skill manifests. It also recognizes Claude Code's marketplace and installed-plugin records. A preview then asks OpenWork's service what each marketplace offers. Import brings the selected plugins into an OpenWork organization and uploads personal skill instructions.
This discovery is selective. Anthropic's built-in skills are excluded. Automatic marketplace import uses public GitHub sources; a local-folder marketplace is reported as unsupported. Cowork's records do not identify which plugins the person actually used, so the guide tells the agent to ask rather than import everything. Claude Code's installed-plugin list supplies more information.
In our small check, the downloaded scanner found a synthetic personal skill, excluded a built-in one, combined the same marketplace found in both products, and flagged a local-folder source. We did not sign in, upload content or execute the authenticated preview and import steps.
A disconnected service no longer hides the instructions
The more consequential design choice sits behind the command. In the preceding import change, the maintainer describes a sales plugin whose instructions were blocked until twenty suggested connectors had been configured. An imported call-preparation skill could exist without being available to read.
The new backend logic marks connectors imported from Claude-style plugins as optional. A skill can return its instruction text together with connection status and setup actions. OpenWork's separate Agent Plugin format retains required dependencies. The change distinguishes an instruction a user can start reading from a service the agent is authorized to use.
That distinction enables a useful gradual trial. A person could examine an imported reporting procedure and use the parts based on supplied files before connecting a calendar or customer database. A step that needs those services still needs access. “Optional” changes whether the instruction is withheld; it does not make the service unnecessary to every task.
What comes across—and what stays behind
For a personal Cowork skill, the command uploads SKILL.md text. It does not package the neighboring scripts, reference documents or other assets that a richer skill may need. This is narrower than the older guide's instruction to copy an entire skill directory. A procedure written wholly in text is a better fit for this path than one that delegates work to an accompanying program.
The migration documentation also keeps conversation history, credentials and schedules outside automatic transfer. Users reconnect services, recreate recurring jobs and verify the output. Trying OpenWork need not mean abandoning Claude models: the guide describes connecting an Anthropic provider separately. The product carrying the workflow and the model answering inside it are different choices.
Visibility is another choice to make at the start. Imported marketplace plugins default to organization-wide access; --private limits a new import to the person. Personal skill instructions are created privately. Reimporting an existing marketplace plugin preserves its access, so adding --private later is not a way to retract its earlier sharing.
Repeat import is useful, but bounded. The backend can find an earlier public-plugin import from the same creator, organization, name and repository, update changed instruction text and leave unchanged items alone. This is not two-way synchronization. Personal-skill matching also relies on names and a single-skill plugin shape, rather than a general proof of origin; a same-name item deserves inspection before an update. The import command can also report success after a marketplace preview fails, so compare the expected inventory with the returned imports.
Try the procedure, not just the import
The upstream evaluation defines a fuller synthetic journey: discover files, preview plugins, import one, read the resulting instructions and repeat the operation. The author reports successful local and hosted runs. We inspected those definitions; we did not independently run that authenticated journey or a migrated business task.
The strongest reading is therefore practical: OpenWork has reduced the manual setup involved in trying a competing assistant, and separated access to instructions from optional connector setup. It has not made assistants interchangeable. The next useful demonstration is one real procedure carried over with its required files, separately authorized services and a checked result. For users, that is a better switching test than whether an import ends with a success message.