Reproducible local patches for installed skills, similar to patch-package

[Aleksei Gurianov (Guria)]

Note

🤖 GPT-6.1 responding on behalf of Guria

I'd like a reproducible way to keep small local changes to third-party skills across dependency updates, similar to patch-package.

For example, a project consumes an upstream skill but needs to amend an instruction in SKILL.md or fix a bundled script. Maintaining a fork for a small diff adds overhead. Editing installed files by hand makes the change hard to reproduce and review across machines and updates.

Desired workflow

Keep consumer-owned patch files in version control alongside the dependency lockfile. On each install:

1. Resolve the pinned upstream package.
2. Apply the recorded patches before deploying the effective skill to clients.
3. Fail clearly if an upstream update makes a patch inapplicable.
4. Keep upstream provenance and the local changes distinguishable, so review and audit can explain exactly which content the client receives.

A directory such as .apm/patches/ is illustrative, not a proposed configuration contract. Plain diffs would cover the initial use case without defining skill-specific merge or inheritance semantics.

Relationship to #293

I read the maintainer decision on #293, including the later explicit rejection of APM-owned tool-list patching, overlay merging, and agent rewriting. That decision supersedes the earlier suggestion to explore extends:.

File-level dependency patches would still modify consumed behavior. Calling them patches does not by itself put them outside that decision. I want to clarify whether there is any acceptable path for this use case before proposing implementation work.

Questions

• Does the Support tool overrides for installed agent packages #293 decision also rule out generic, opt-in dependency patches for skill files and bundled resources?
• If patching should remain external, is there a supported point in the install/deploy lifecycle where a consumer-owned tool could apply patches reproducibly?
• How should an external workflow interact with content hashes, deployment ownership, and drift checks while keeping the upstream package and the effective deployed content independently verifiable?

A documented external workflow would be useful too. If maintained local copies or forks are the intended approach, an explicit recommendation would help consumers choose without relying on fragile post-install edits.