One Skill, Five Tools: Building AI Workflows That Run in ChatGPT, Claude, Gemini, Grok, and Cursor

Roles have different needs. Code-adjacent work benefits from a tool that reads the repository; long-document review favours whatever handles context best this quarter; client work sometimes comes with a mandated platform.

Model capability also moves faster than procurement. A team that standardised eighteen months ago has already been overtaken, which is a good argument for designing around switching rather than against it.

Custom GPTs, Projects, and Gems are convenient and quietly expensive. The process gets entangled with one platform’s file handling and memory behaviour, and the only export is a wall of text that loses half its meaning elsewhere.

Treat those containers as install targets. The skill is the asset; the container is where a copy of it happens to live. What each platform gives you out of the box, where those native features run out, and how to migrate a working Custom GPT are covered in Custom GPTs, Projects, and Gems versus packaged skills.

Four things move cleanly between every tool: the method, the sources the job may use, the checks the output must pass, and the output specification. Together they are most of the value.

If your workflow’s value is mostly in these four, you are already portable. If it is mostly in one platform’s connectors, you are not.

Tool connections, file APIs, plugin behaviour, memory, and context handling all differ. So does how each platform treats a long reference document versus pasted text.

Trying to write one instruction set that papers over these differences produces text full of conditionals that degrades everywhere. Separate the layers instead.

The useful convention that has settled is a folder with one instruction file at its root plus the resources it depends on: references, templates, and any scripts. It is plain text, diffable, and versionable.

The format matters less than the discipline it imposes — a compact procedure at the root, detail in references, and a single unit you can install rather than a scatter of documents. The section-by-section conventions — routing, activation boundaries, output schema, checks, unknowns policy — are in SKILL.md conventions that travel.

Start from the deliverable and the method, with no assumptions about how inputs arrive. Then, per tool, write the thin adapter: how this platform gets the transcript, what it can read directly, what has to be pasted.

The adapter is usually a paragraph. When it starts growing, that is a signal the skill has absorbed platform assumptions and needs cleaning.

Coding tools change what is possible: the workflow can read the repository, run a script, and inspect actual test output rather than a pasted summary. Release-readiness and code-review workflows are meaningfully better there.

The skill stays the same; the adapter says “read the branch” instead of “paste the ticket list.” That variant appears in the release readiness workflow, and the fuller engineering treatment — briefs built from tickets, diffs, and test results — is in review briefs from tickets, diffs, and tests.

Models differ in default verbosity, willingness to hedge, and how readily they volunteer an inference. None of this is a defect; it is a reason to specify rather than assume.

The fix is the same one that makes skills good generally: state the output shape, state what counts as evidence, state what must never be asserted. Specified behaviour varies far less across models than unspecified behaviour does.

Prefer explicit structure over stylistic direction. “Four sections in this order, each claim attributed” travels. “Be concise and insightful” does not.

Avoid relying on a model noticing something implied. If a rule matters, write it as a rule and test for its violation.

Where a platform can fetch its own inputs, let it — but keep that in the adapter layer. The procedure should be indifferent to whether the transcript arrived by API or by paste.

That indifference is what lets you add a connector later without touching the skill, or run the same workflow in a tool that has no connectors at all. Where an integration platform is already gathering the inputs, the same boundary applies — the division of labour is in how automation and skills divide the work.

One version number for the job, plus a short per-platform note describing install and known limits. When the process changes, you bump one version and everyone is current regardless of tool.

The alternative — five independently versioned copies — recreates exactly the drift problem described in the drift problem five diverging copies create.

When the process is the artifact, changing tools is an install change. People already know the method, the output shape, and what to check — only the mechanics move.

This is the strongest practical argument for portability. It converts a migration into an afternoon.

Run the identical case set in every target environment and score against the same checks. Differences show up quickly, and they are usually in how much the model volunteers rather than in correctness.

Where a platform consistently fails a check, fix it in the adapter or restrict that platform to a variant of the job. The method is in running the same cases across models.

Occasionally a job genuinely benefits from a specific model — very long inputs, repository access, a platform a client requires. Record that as a parameter of the skill with a reason, not as a rewrite.

A documented preference is maintainable. A fork is not.

Retention, training defaults, connector permissions, and admin controls differ by platform and plan. A workflow that is fine in one environment may be unacceptable in another with identical instructions.

Decide per workflow which platforms are allowed for which data classes, and write it down next to the skill. Our own posture is on the security page.

Per tool, one page with screenshots: where the skill goes, how to invoke it, what to paste, what to check. Assume no prior knowledge and no interest in the underlying format.

Have someone outside the project follow the page without help. Every question they ask is a missing line. Installing in one tool first and stabilising before adding the rest keeps you able to tell a workflow problem from an adapter problem — the rollout order is in multi-tool rollout order.

Copying means five artifacts, five drift paths, and no way to tell which is current. Installing means one definition with five thin adapters and one version number.

The difference shows up the first time a rule changes — which is usually within a month of launch.

Common, well-understood jobs are better served by a ready-made skill you install and adjust — that is what the skill library and bundles are for.

Jobs with team-specific rules, source systems, or approval logic justify a custom build. The four stages are described on the custom workflows page, and the line between installing and commissioning is drawn in the install-or-commission test.

Keep one registry: skill name, owner, version, target tools, allowed data classes, last test date. Without it, nobody can answer which version finance is running in which tool.

The registry is also how you retire things. A catalogue with no deprecation path becomes sprawl, as covered in building an internal AI skill library.

One skill folder as the source of truth, per-platform adapters kept deliberately thin, one shared test suite run against every target, and one registry entry tracking version and scope.

That is the whole architecture. It is unglamorous, and it is why switching tools stops being a project. You can see finished workflows built this way in the examples.