Your AI Coworker's Skills Can Move. Can You Prove They Still Work?

A Portable Skill Is Not a Portable Result

On October 22, Anthropic donated Agent Skills to the Agentic AI Foundation. More than 70 products have integrated the format, according to Anthropic. That is real progress for any business that wants its AI coworkers to carry their working procedures between systems instead of rebuilding them inside each vendor's interface.

There is an important qualification in the same announcement: a proposed roadmap includes versioned releases and security guidance. Those are proposals for what comes next, not proof that every Skill installed today is versioned, reviewed, or safe in every runtime. A common way to package a procedure answers the question, “Can this system read it?” It does not answer, “Will this coworker make the right decision with it, under our rules, in this environment?”

Think about a monthly invoice-review procedure. The same document can tell two AI coworkers to collect unpaid invoices, compare payment records, draft reminders, and flag discrepancies. One may have read-only access to current invoices; another may see stale exports and hold a credential that can send reminders immediately. The text moved intact. The work did not.

This is the next practical portability problem. The file is transferable; the outcome depends on data, permissions, execution environment, model behavior, and who can intervene. Businesses need a release process for Skills, not a folder copied from one machine to another.

What the Shared Skills Format Actually Gives You

The Agent Skills specification defines a directory with a required SKILL.md containing a name, description, and instructions. It can also include scripts, references, and assets. Its overview describes loading the description first, reading full instructions when relevant, and accessing bundled resources as needed. This is a useful separation: a procedure becomes a portable artifact rather than an undocumented habit embedded in a chat session.

But the specification also permits optional compatibility notes and an experimental allowed-tools field whose support can vary by implementation. The body can say whatever the author thinks will help. Those facts matter operationally. A Skill can describe how to do a job without guaranteeing that each host grants the same tools, interprets the same restrictions, runs the same script dependencies, or even activates the Skill for the same request.

Three different kinds of portability

Format portability means another product can discover and read the folder. This is the standard's immediate promise. It reduces the cost of moving written know-how between products.

Environment portability means the Skill has what it needs to run: supported tools, accessible data, working dependencies, compatible file paths, and a permitted connection to each external service. Copying a script without its runtime or access model does not satisfy this test.

Decision portability means the business gets acceptable results under its own rules. A coworker should pause at the same consequential boundary, cite the same authoritative records, and hand the same unresolved exception to the right person. That is not a property a file extension can confer.

A business can pass the first test and fail the other two. Treat those tests separately in your rollout plan. If you have already mapped how a coworker's rules travel between runtimes, add the procedures that invoke those rules to the migration inventory. The policy may travel while a Skill calls a different connector or interprets a missing field as permission to continue.

Make the Skill a Contract for a Job, Not a Bag of Instructions

A useful Skill describes an outcome, but a production Skill also needs a boundary around the route to that outcome. Write a small operating contract beside the instructions. The contract belongs to the business even if the Skill is published in an open format.

Specify the inputs and the source of truth

Name the records the coworker may use, their required freshness, and what to do if a record is absent. “Check the customer's balance” is too vague. “Use the current invoice ledger and settled-payment feed; if either is unavailable, prepare an exception instead of a reminder” is testable. A missing source must not quietly become an estimated value.

If a Skill uses reference documents, assign an owner and review date to each one. A portable procedure can still be wrong because it brings last quarter's policy into this quarter's workflow. See our guide to editing an AI coworker's knowledge base for the difference between keeping a document and keeping it authoritative.

Describe allowed actions independently of the prose

Put read, draft, send, payment, deletion, and permission changes in separate categories. A Skill may request an action, but the runtime identity and connected service must enforce whether that action is allowed. Writing “ask before sending” in Markdown is not a substitute for removing unsupervised send access.

For an invoice-review Skill, the coworker can read ledger entries and produce a draft. A person approves the customer-facing reminder after reviewing the balance and recipient. Changing bank details is outside this Skill altogether. That division is an example of trust architecture: the system cannot silently promote a draft into a payment or message just because its instructions sounded confident.

Define an observable completion state

“Invoice reminders prepared” should have a precise meaning: records checked against the source systems, exception list saved, drafts attached to the correct accounts, and no message transmitted. Include an owner for exceptions, an expiry time for the packet, and a marker for any action that might already have happened. The completion record lets a human check the work without replaying a conversation.

What bad looks like: An owner pastes a downloaded Skill into two AI products. Both generate a reminder list, so the migration is called complete. The second product uses an old spreadsheet, silently ignores one missing settlement, and sends to every contact it can reach. The file was portable; the approval and evidence boundary was not.

What good looks like: The owner pins the reviewed Skill revision, maps the required sources and roles in the second product, removes direct send permission, and runs the same sample invoices through both environments. One missing settlement produces a named exception in each; no customer receives a message. Differences in model wording are acceptable. Differences in financial facts or allowed actions are not.

Run a Skills Portability Test Before Any Production Move

You do not need a large testing department. You need a small, repeatable release gate that someone in operations owns. Apply it whenever a Skill changes, a connector changes, or the underlying runtime or model changes. A file copied into a new host is a candidate for deployment, not the deployment itself.

1. Inventory the complete package. Record the Skill folder's revision, scripts, references, assets, upstream source, and owner. Compare the actual files, not just the SKILL.md title. If a third-party package changed without a review, stop the release until the diff is understood.
2. Map every dependency. List input systems, output locations, runtime packages, network destinations, connected accounts, and human reviewers. Mark what is present in the target environment and what behaves differently. A missing integration is a failed test, not a detail to improvise around.
3. Write invariant outcomes. Pick a handful of things that must remain true regardless of host: totals reconcile to the ledger; an absent payment feed produces an exception; external reminders remain drafts; the reviewer is named. These are acceptance criteria, not stylistic preferences.
4. Build representative fixtures. Include a normal invoice, a duplicate, a credit memo, a payment received after the export, and a customer with ambiguous contact details. Remove real personal data from test copies. Save expected results so the next release can be compared with this one.
5. Test denied and uncertain paths. Remove access to one input, reject a proposed action, interrupt a run, and simulate an ambiguous response from a connected service. The coworker should stop or hand off with evidence. It must not assume a failed response means an action did not occur and retry blindly.
6. Check actual authority. Inspect the account and service permissions used in the target environment. Test that direct send, payment, and permission changes are blocked where the contract forbids them. A successful instruction-following test is weaker than an enforced denial.
7. Stage, observe, and roll back. Begin with a bounded workload and a named reviewer. Compare outputs and exceptions with the old procedure, then expand only if the acceptance criteria hold. Keep the previous working version and a way to route work back to it. Record the decision and the change that triggered it.

Do not mistake identical prose for identical behavior. A model may select a Skill differently, summarize a reference differently, or interpret a tool failure differently. The tests above focus on business invariants so you can change models without demanding identical sentences. That is the point of a model-agnostic approach: preserve the job and its boundaries while the underlying model changes.

The Owner Still Owns the Procedure

The October 22 donation matters because neutral stewardship makes an open procedure format less dependent on one vendor. Anthropic says the proposed next steps include versioned releases, a proposal process, and security guidance. Those developments are worth following. They will not decide your invoice policy, your source-of-truth hierarchy, or who can authorize a customer message.

This is where intent engineering becomes practical. A Skill answers how a task can be done. The organization must answer why this task exists, which outcomes matter, where the human judgment seam sits, and what failure looks like. The Skill is a reusable expression of work, not a replacement for organizational authority.

Consider a sales follow-up Skill. It can gather account context and draft a reply on any compatible system. It should not decide whether an upset customer receives a promotional sequence or a call from a human account owner. That decision depends on the organization's priorities, live customer state, and escalation rules. A portable procedure without a clear intent boundary may just produce the wrong outcome more consistently.

Assign one named owner to each production Skill. The owner approves revisions, validates dependencies, reviews exceptions, and retires the Skill when the business process changes. This need not be a full-time technical role. In a small business, it may be the person who already owns the underlying process. What matters is that a question about the Skill has an answer more specific than “the AI team handles it.”

Keep a short change record: the prior revision, what changed, the fixtures rerun, the result, the approver, and the rollback path. If a third-party Skill includes executable scripts, review those as code and scope what they can reach. The earlier OpenClaw plugin supply-chain discussion covers why trusted packaging alone is not a runtime permission boundary. The same principle applies to a portable Skill, without treating every package as malicious.

The payoff is not that every coworker produces the same sentence in every app. It is that the business can move a proven procedure and still know which source informed it, which actions it could take, and which person owns the exceptions. A shared format makes that possible to attempt. A release gate makes it credible.

FAQ

Q: Does the Agent Skills standard guarantee that a Skill works in every AI product? A: No. It standardizes the package and its basic metadata and instructions. Each product may differ in activation, tools, execution environment, and permission enforcement. Test the business outcome in the target environment.

Q: What is the difference between a Skill and an AI coworker's role? A: A Skill is a reusable procedure or domain guide. The coworker's role includes ownership, connected systems, permissions, memory boundaries, escalation rules, and accountability across jobs. One role can use several Skills; one Skill may be used by several roles under different authority.

Q: Should we automatically update a Skill from its source repository? A: Not for consequential business work. Record and review the revision, inspect changed scripts and references, rerun representative tests, then promote it. Automatic intake and automatic production authority are different decisions.

Q: Can we switch models without changing the Skill? A: Often the same package can be loaded, but the outcomes still need testing. Verify selection, tool behavior, source use, denied actions, and exception handling. Keep the business invariants fixed while you evaluate the new model.

Q: What is the minimum test for a small business? A: Choose one normal example, one missing-source example, and one action that must be denied. Confirm the source-backed result, a useful handoff, and an enforced denial in the target environment. Add cases as the cost of a mistake rises.

If you're ready to give your AI coworkers repeatable Skills without handing over the boundaries that make them trustworthy, explore Associates AI Teammates and choose a plan. Build the team on persistent agent servers, with model-agnostic configuration and human review where the work demands it.