Agent Skills joins a foundation. What should a company preserve when it changes AI tools?

Public developments and original analysis · Announcement date: 2026-10-22 · Sources

On October 22, Anthropic announced the transfer of Agent Skills to the Linux Foundation’s Agentic AI Foundation, including its name, branding, GitHub organisation and domain. The foundation confirmed the project’s admission that day. For a company already using AI assistants, this raises a practical question: how much of the effort spent teaching an assistant a job will survive a change of tools?

The Agent Skills specification packages task instructions in a folder centred on SKILL.md, with optional scripts, references and assets. A team can keep the material for a job together instead of searching old conversations for a useful prompt. Deciding which knowledge belongs in that folder requires closer attention to the work itself.

Recording the decisions behind a technical review

Consider a hypothetical review of a technical tender response. A reviewer needs to match the offered model, the tender requirements and the current product manual. “Check carefully and avoid omissions” gives a new colleague little help. More useful instructions explain that a parameter must come from the specified model’s documentation; that test conditions in a tender must be compared with those in the manual; and that an unsupported requirement should remain unresolved rather than be filled using a similar model.

The value lies in those decisions. The same number can mean different things under different operating conditions. An old specification may remain valid for installed equipment while being unsuitable for this bid. Documenting experience means identifying what to consult, who resolves missing evidence and what references the response table must retain. Understanding the wording covers only part of the job.

Box’s developer-skills announcement on the same day offers a concrete comparison. Its guidance addresses uploads, bulk operations and synchronisation, including checks on the operating environment and results. Box explicitly says that installing a skill neither connects an account nor grants access. The useful lesson is the level of operational detail. Written guidance gives a team something to reuse; working access still needs to be established.

Tender review has a similar distinction. Model-matching rules and citation requirements can be documented for reuse. Reading a product repository, opening a project folder and updating a response table depend on the current systems and permissions. After an assistant changes, the first group may remain useful while the second needs testing. A procurement question limited to “Does it support Skills?” leaves much of that migration work unexplored.

A company need not turn every procedure into a skill. A stable check performed once a month may be adequately supported by a maintained spreadsheet. Recurring tasks that require professional judgement and pass between people or tools are stronger candidates. Where staff disagree about the procedure, a business owner needs to resolve the rule before contradictory instructions are handed to an agent.

What needs to travel with the instructions

Foundation stewardship provides a neutral arrangement for the standard. A company still needs to maintain its own task instructions. An open format makes material easier to retain and exchange; the amount of migration work saved depends on how tightly those instructions are coupled to one assistant’s tool names, paths and implicit behaviour. Dependencies scattered through business rules will need to be found individually later.

One useful separation lets a reviewer read the business rules independently. A technical response table might retain an agreed set of contents: the requirement, supporting product evidence, conclusion and unresolved points. Instructions for retrieving the manual from a particular system can be maintained separately. Business staff can then assess the judgement while implementers locate the connection details that need changing. This takes preparation, justified when the task genuinely needs reuse.

Mokyun’s stated focus on technical-document preparation, knowledge retrieval and task orchestration provides a place to contribute: organise authorised product evidence and review rules into a defined task, produce a referenced response draft and identify questions for the technical reviewer. This describes a workflow based on the current product direction. A project requiring the Agent Skills format must separately check loading behaviour, tool support and versions in the target runtime; a general import capability has not been established here.

A useful implementation should leave the business able to understand its rules and maintenance staff able to find their evidence. When product documentation changes, the team should be able to identify which judgements need revisiting. When a model changes, a retained set of sanitised examples allows comparison. Those examples should include complete evidence as well as mismatched models or missing test conditions that require a different response.

That comparison gets closer to the purchasing decision than a successful folder import. Two assistants may read the same instructions and still handle missing evidence differently. Differences in format or tool naming suggest adaptation work. Missing evidence behind a judgement requires returning to the business rule. A standard helps make these costs visible; it cannot remove them by itself.

Instructions should also be allowed to shrink. After a model upgrade, repeated explanations of routine concepts may obstruct the important requirements. After a rule changes, an old example may mislead. The purpose of maintenance is to retain the expertise the job still needs. Clear ownership of that expertise is more useful than accumulating skill files that nobody feels able to revise.

• Mokyun specialist workflows

Mokyun Editorial · neo@mokyun.com