How can I make an APM marketplace package installable through the Claude and Copilot interfaces ?

[maximedelattreLV]

Hello,

I’ve created an APM package that includes our company standards, and I’d like to make it available to Claude and GitHub Copilot users directly through their respective interfaces. I’m also looking into their auto-update features so users can stay up to date.

I’ve created an APM marketplace that points to the package. When I connect the marketplace to Claude or Copilot, they can find the package, but it remains in the APM format.

How and when should I convert the package into a format that Claude or Copilot can use (the format produced by apm install)?

Am I missing something?

Thanks!

[André (itzmitto)]

Hello maximedelattreLV,

The step to check here is packaging your APM source before publishing it through the marketplace 🙂

From your package directory, you can preview what APM would include:

apm pack --dry-run --verbose

Then create the package:

apm pack

The documented default output is build//, containing plugin.json and the exported plugin files. Check that output includes the standards you want to distribute, then have your marketplace entry reference the packaged content.

These docs explain both steps:
https://microsoft.github.io/apm/producer/pack-a-bundle/
https://microsoft.github.io/apm/producer/publish-to-a-marketplace/

Are you using Claude Code and Copilot CLI, or other interfaces? That matters for the installation and automatic-update part.

If you can share a redacted example of your apm.yml and marketplace entry, we can check whether the paths point to the right content. You don't need to share your internal standards.

Hope this helps!

[maximedelattreLV]

Thanks for your answer!

We are currently using Claude Code CLI and Copilot in VS Code.
We are looking for two properties:

1. Being decoupled from the platform (Claude, Copilot, Codex, etc.), since the landscape is changing fast.
2. Having a "push mechanism" to keep our users up to date, so we can get faster feedback while developing our AI packages and push security patches.

About 1.
I see that apm pack --format agent-plugin produces a plugin that follows the open agent plugins standard.
My question is: don't we lose the transformations that apm install --target would apply? Wouldn't we lose some features as a result, for example path rewriting or hook keys that change depending on the platform?

About 2.
Claude Code can indeed update the package by itself. I tried it yesterday with an APM marketplace pointing to an APM package build/.
I found some limitations:

• The update only happens after restarting the CLI and waiting a few minutes.
• The user still needs to install the plugin manually the first time. Pulling a project .claude/settings.json that lists the required plugins is not enough.

Copilot in VS Code updates every 24 hours, the users needs to install manually the plugins once through the IDE (at workspace scope)

Do you know of any other options for automatic updates with APM, Claude, Copilot etc. ?

Here are the marketplace's apm.yml and the package's apm.yml:

name: ai-marketplace
version: 1.0.0
description: Marketplace of reusable agentic assets
author: Author Name
license: UNLICENSED

targets:
  - copilot
  - claude

dependencies:
  apm: []
  mcp: []
includes: auto
scripts: {}
marketplace:
  owner:
    name: Organization
    url: https://github.com/Organization/ai-marketplace.git

  build:
    tagPattern: "v{version}"

  outputs:
    claude: {}

  packages:
    - name: docker-standards
      source: https://github.com/Organization/ai-docker-standards.git
      ref: 1.0.4
      subdir: build/docker-standards-1.0.4

name: docker-standards
version: 1.0.4
description: "Docker standards -- base images, Dockerfile build and security rules, and GitHub Actions CI/CD pipeline (Wiz scan, GCP Artifact Registry)."
type: skill
targets: [claude, copilot]

dependencies:
  mcp: []

[André (itzmitto)]

Hi maximedelattreLV!

Thanks for sharing the configuration and explaining what you're trying to achieve! 🙂

I had another look at the APM documentation, and I think your concerns make sense.

About the platform-specific transformations:

You're right to question this. The agent-plugin format is more portable, but it doesn't support everything that APM can handle.

According to the documentation, apm pack --format agent-plugin only supports a limited set of resources, such as skills and MCP configuration. It actually rejects unsupported features like hooks, commands, and agents rather than silently converting them.

So if your company standards depend on platform-specific hooks or path transformations, I wouldn't assume the portable format preserves everything.

For that reason, I'd keep your apm.yml as the main source of truth and use APM's target-specific installation process where those transformations are needed.

About automatic updates:

Your findings about Claude Code and Copilot are useful. From what I understand, APM provides apm update for refreshing dependencies, but that isn't the same as pushing an update directly into every user's IDE.

One thing I noticed in your marketplace configuration is: ref: 1.0.4

That reference is fixed, so publishing a newer package alone won't automatically make the marketplace point to it. You'll also need to update the marketplace entry and regenerate its published metadata.

For company-managed environments, a possible approach would be to automate APM update checks through a controlled setup script or development environment configuration.

However, I wouldn't promise fully automatic installations or immediate updates across Claude Code and Copilot without testing their individual update behavior.

These two documentation pages might help:

https://microsoft.github.io/apm/producer/pack-a-bundle/

https://microsoft.github.io/apm/consumer/update-and-refresh/

I think keeping APM as your source of truth while handling installation and updates per platform is a reasonable approach for now.

Hope this helps clarify things a bit!

[maximedelattreLV]

Thanks a lot. I now have a better understanding of how far we can take the APM/platform decoupling in a push-update setup, and of the trade-offs involved. That hit the spot! :)