Tracing AI Skill File Replication and Governing the Supply Chain

1. Background: AI Skill Packages Are Becoming a New Supply Chain Unit

As AI coding assistants become part of mainstream development workflows, lightweight “skill packages” are emerging as a primary way to extend their capabilities. A skill package is typically a directory containing a skill instruction file and a set of supporting scripts. After reading the instructions, an AI assistant may execute commands, access the network, and read or write files, often with the permissions of the current user.

From an engineering perspective, a skill package resembles both a plugin and a configuration bundle. However, unlike traditional plugin ecosystems, it often lacks an application marketplace, versioning, signature verification, and formal review.

Research has observed that, on a major code hosting platform, the number of repositories related to AI skills grew from almost zero to the hundreds of thousands within ten months. The total number of skill files reached the millions, and roughly half were exact copies. Open-source collaboration naturally encourages reuse, but skill packages are not ordinary source code: they directly instruct AI assistants to perform potentially privileged operations.

If a skill instruction file contains malicious commands, an unpatched vulnerability, or an unsafe default configuration, replication can amplify its impact. More importantly, downstream users often do not know who the original author was, how many times the file has been copied, or whether upstream fixes can reach downstream copies.

These are the central questions of skill supply chain governance: How do these files move? Who copies from whom? Do fixes propagate along with the copies? Which nodes deserve the most attention?

2. Why Snapshot-Based Scanning Is Not Enough

Early studies often used a snapshot-based approach: scan code hosting platforms at a particular point in time, identify which repositories contain which skill files, and then classify and assess their risks. This method can answer “who has what now,” but it cannot answer “where did it come from?”

Consider a town where every household displays the same type of potted plant. A snapshot study can count the plants and classify their varieties, but it cannot determine who first brought the plant into town. It also cannot tell whether Neighbor A propagated a cutting from Neighbor B or bought the plant independently from a market. If a blight suddenly appears, authorities cannot determine whom to alert first because the relationships between the plants are unknown.

The same problem applies to skill files. A simple inventory of repositories cannot distinguish original authors, first-time adopters, secondary copies, or bulk package migrations. Without direction and timing, it is impossible to identify source nodes, key distributors, or high-risk aggregation points.

For this reason, researchers are moving beyond static snapshots and examining the version-control history behind each skill instruction file. The goal is to reconstruct a time-stamped, directed propagation graph: who had the file first, who added it later, who copied from whom, and when each copy was made.

For an individual skill file, the subnetwork formed by all of its copies can be described as a “constellation graph.” This graph changes the research question from “where does this file exist?” to “how does this file move?”

3. Reconstructing a Propagation Network from Commit History

The core approach is to use the content fingerprint of a skill instruction file as its node identity, then derive edges from file creation, modification, and deletion events in repository histories. Time ordering is used to infer the direction of propagation.

The process can be abstracted into the following steps:

1. Collect skill instruction files and calculate their content hashes to build a set of copies.
2. Read the commit history of each repository and extract the file’s first appearance, modification times, and parent commit relationships.
3. Create candidate edges between identical or highly similar copies, using timestamps to determine direction.
4. Cluster commits in which many files appear together to identify batch migration patterns.
5. Calculate metrics such as in-degree, out-degree, and betweenness centrality on each constellation graph to locate source and key propagation nodes.

A simplified pseudocode example is shown below:

for each repository:
    history = read_commit_history(repository)
    for each commit in history ordered by time:
        files = extract_skill_files(commit)
        for file in files:
            fingerprint = hash(normalize(file.content))
            record_node(fingerprint, repository, commit.time)
            if file.is_new():
                for parent in commit.parents:
                    if parent.contains(fingerprint):
                        add_edge(parent.repository -> repository, time=commit.time)
        if files.count() > threshold:
            mark_batch_migration(commit)

This graph can answer three critical questions:

1. Where did a particular skill file first appear?
2. Which repositories act as hubs for replication and distribution?
3. Are downstream copies updated after an upstream change?

Compared with a snapshot, a constellation graph shifts the governance target from a file inventory to the propagation path.

4. Key Findings: Batch Migration and Copy Homogeneity

The first major finding is that skills are rarely adopted one at a time. They are more often migrated as complete bundles. Developers may import a group of skill files from the same template repository, tutorial project, or toolchain configuration.

This batch migration creates clustered rather than isolated, point-to-point propagation. The governance implication is that monitoring individual files is not enough. Systems must also identify skill package combinations and bulk adoption events.

The second finding is a high degree of copy homogeneity. Approximately half of the copies are completely identical to the originals, indicating that many adoption events involve direct copying rather than further development.

Homogeneity has two opposing effects. On one hand, an upstream fix may be naturally propagated when downstream users copy the updated version. On the other hand, if a downstream project locks an old copy and stops synchronizing, the fix cannot reach it.

The situation becomes more complex when batch migration includes path changes, script modifications, or minor edits to instruction files. These changes create “near-duplicates” that cannot be identified through simple hash matching. Content similarity and commit timing must be considered together.

A third issue is the loss of source visibility. Because skill ecosystems often lack marketplace-style publication records, repeated copying can strip away author information, license notices, and version details. Downstream users may see only a usable instruction file, without a reliable way to assess its provenance.

This resembles dependency governance problems in software projects that lack a software bill of materials: without component provenance, it is difficult to evaluate licensing exposure, vulnerability impact, or supply chain attack surface.

5. Supply Chain Risks and Governance Recommendations

Based on these propagation patterns, the supply chain risks of AI skill files include at least four categories:

• Malicious instruction injection
• Inheritance of outdated vulnerabilities
• Loss of licensing and compliance information
• Difficult audits caused by untrusted or unknown provenance

Governance should not rely solely on manual spot checks. Skill packages should be managed as controlled artifacts.

1. Build a provenance index and content fingerprints

Calculate normalized hashes separately for skill instruction files and supporting scripts. Record the first appearance time, repository identifier, and commit information to create a searchable provenance index.

2. Introduce signatures and version locking

Skill package publishers can sign their content. When consumers lock a version, they can verify the signature and hash to prevent silent replacement.

3. Audit batch migrations

When a commit introduces multiple skill files, trigger a provenance check and differential review. This can help determine whether the files originated from a trusted template.

4. Monitor critical nodes

Prioritize repositories with high in-degree, high out-degree, or other signs of centrality in constellation graphs. These repositories may function as de facto distribution hubs and should receive special attention for remediation notices and risk alerts.

5. Establish downstream synchronization

Use similarity matching to identify near-duplicates. When an upstream project releases a security fix, notify downstream adopters that may still be using related copies.

At the implementation level, general-purpose cloud capabilities can support this type of governance. Artifact repositories can provide version locking and hash verification for skill package distribution. Audit logs can record the introduction and modification of skill files. Code hosting and CI/CD integrations can block unsigned or unknown-origin packages during pull request or merge review.

Baidu AI Cloud capabilities such as code hosting, artifact management, and logging services are among the possible options for building these controls. The specific design must still be aligned with an organization’s permission model and release workflow.

6. Conclusion

The propagation of AI skill files is not simply a matter of open-source reuse. It is a high-privilege supply chain that often lacks versioning, signatures, and review mechanisms.

Snapshot-based scanning reveals only the current inventory. Reconstructing propagation from commit history and representing it through constellation graphs reveals how the files actually move. Batch migration and copy homogeneity mean that governance must address skill package combinations and key propagation nodes rather than isolated files.

For developers and platform operators, establishing provenance indexes, signature verification, batch migration audits, and downstream synchronization early will make it easier to protect the supply chain as the AI skill ecosystem continues to expand.