After You Adapt an Agent Skill

Matt Pocock’s installation instructions offer two ways to add reusable planning, testing and debugging procedures to an AI agent. These procedures, called skills, can arrive as a plugin, a package managed by the agent’s software, or as editable files in your project. His README describes the plugin as updating itself. With copied files, you manage updates. Pocock encourages people to make the skills their own.

Editable instructions give you room to change a procedure for your project. Once you change the copy, replacing it with a newer source version also becomes a decision about what to keep. The original author maintains the shared procedure. You maintain the version that fits your work.

An October 8 preprint study reports limited coordinated change among skill copies in public GitHub repositories. It observes files and their histories, without showing whether people used them or suffered failures. For anyone relying on an imported skill, it sharpens an everyday question: how will later source changes reach the instructions your agent receives, while preserving the changes that made them fit?

Following the files

Fahd Seddik’s Skill Constellations reconstructs distribution from skill-file commits and overlap between repositories. A match can identify an earlier distributor without proving where a particular person installed the skill from.

A group contains repositories holding the same skill version in a week. Only 11.1% of changes to these groups saw every member move to the same next version, the paper reports. That demanding group-level test is not an individual copy’s update probability.

The result does not establish defective versions or neglect. Repositories may be unused; differences may be intentional. It shows limited coordinated change among the stored files.

An update to a public source and an update to your working copy are separate events. The first gives you something new to consider. Whether it changes your agent’s procedure depends on the route between them.

Differences worth keeping

A July preprint study by Haoyu Gao and colleagues examined reused software-engineering skills and their registry sources. Among 1,295 copies with no later local change, 40.2% had a source that changed after adoption. Where both versions changed, 429 of 689 had diverged when compared around the first later source change, under the study’s content-similarity rule. This is related repository evidence, not a replication of the October measure or an account of people’s motives.

The study’s analysis of edits shows why differences can be useful. Adaptations changed paths, setup and tool choices. In one Android example, adopters changed the recommended software framework to match the project’s existing tools. Returning the file to its source version could restore the tool choice they had changed.

That makes replacement a different operation from bringing in a particular improvement. The desired change might be a revised testing step, while the local version still needs its own tool names and paths. Accepting one does not logically require surrendering the other, although separating them takes review work.

A March 1 feature request in Vercel’s skills tool makes that tradeoff concrete. GitHub user TreeTreeDi reported that updating a global installation replaced the skill directory, losing local edits and local-only helper files. They requested an option to preserve local material and flag conflicting files for a decision. This is a historical user report, not a reproduced test or a claim about today’s release.

The request matters because the person wanted to update. What they wanted preserved was part of the installed procedure. A reminder to take the latest version would not, on its own, answer which contents should survive.

Which connection did you install?

Current tools offer several ways to handle that relationship. Vercel’s installation documentation distinguishes independent copies for each agent from symbolic links, filesystem pointers that lead multiple agents to one canonical local copy. Updating that local copy can then serve the linked agents. A link between local folders does not itself fetch later changes from GitHub.

The tool also documents commands for updating installed skills, including a named skill or a project or global installation. Claude Code’s official documentation separately describes plugin auto-updates when enabled for their marketplace. A running session keeps its loaded version until a reload or a new session. The repository studies should not be read as a claim that every current installation lacks an update path.

These routes make different choices convenient. Managed updates can deliver revisions without a separate manual import. Editable copies leave room for project-specific changes. A deliberately maintained local fork, a copy developed separately from its source, can do both jobs. Someone still has to compare the source’s revisions with what the project already changed. Neither study establishes a universal winner.

For a skill you depend on, one useful question is: can you identify the source revision behind the installed files and explain what would happen to your local changes during an update? This is a suggested engineering check, not a remedy tested by the studies. It asks about the version in use, rather than merely whether a newer version exists elsewhere.

One published skill-maintenance procedure spells out a selective approach. Written for locally adapted copies, it tells the maintainer to compare the last reviewed source commit with later changes and treat an advanced source branch as an update candidate. Its instructions call for reviewing the difference, preserving recorded local changes and running checks before recording the imported revision. This documents a workflow, not measured evidence that it prevents errors.

The useful detail is when the record changes. Under those instructions, the source moving ahead does not advance the recorded, reviewed revision of the local copy. That happens after review and import. A local skill need not become identical to its source to receive a source revision. What matters in this procedure is keeping track of the source changes reviewed and the local choices preserved.

Sources

• Fahd Seddik, Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub, arXiv v1, submitted October 8, 2026. Historical network reconstruction and group-change measure.
• Haoyu Gao et al., From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained, arXiv v2, July 6, 2026. Repository maintenance and local adaptation.
• Matt Pocock, Skills For Real Engineers. Current README and installation choices, inspected October 10, 2026.
• TreeTreeDi, Feature request: add a preserve-local mode for skills update -g, March 1, 2026. Historical issue report.
• Vercel Labs, skills tool documentation. Current installation and update behavior as documented, inspected October 10, 2026.
• Anthropic, Install and manage plugins. Current Claude Code documentation, inspected October 10, 2026.
• bolens, Sync skill upstreams. Authored maintenance procedure, inspected October 10, 2026.