Understanding Expectations

[jklaus-work]

Hello,
I am looking for a level-set on what our expectations should be in terms of behavior.
We currently have a copilot plugin marketplace that we are considering changing over to APM. This is a mono-repo where the plugins live within the same repo as the marketplace. My understanding is that we are to apm init --marketplace in the root of the repo then down inside each of our ./plugins/{plugin-directory} we should apm init --plugin.
This gives us the following structure:

my-marketplace/
├── apm.yml
└── plugins/
    └── plugin-one/
        ├── apm.yml
        ├── plugin.json
        └── [plugin-content-files-here]

The marketplace level apm.yml would have:

...
marketplace:
  ...
  packages:
    - name: plugin-one
      source: ./plugins/plugin-one
      ...

The plugin level apm.yml & plugin.json files only contain the content that is populated during the init process, or should we be adding content to apm.dependencies.apm[] (specifically asking for locally referenced plugins)?

When running apm pack on the marketplace I see that a ./.claude-plugin/marketplace.json is generated and it matches the format for the copilot plugin marketplace json however when I add the apm marketplace and install the package/plugin the plugin does not show via copilot plugin list. I assume we should operate under the assumption that APM Packages are not Copilot Plugins and thus will not show up in the Copilot CLI - please confirm.

If any of this is in flux due to the rapid changing nature of the project please provide current state and future intentions.
Note: in regard to what I saw during pack and install, everything is targeting copilot.

Thanks,
jKlaus

[Daniel Meppiel (danielmeppiel)]

Thanks for the patience while we shipped this out — the monorepo path is now first-class as of apm 0.14.0 (in flight: #1372) and apm-action v1.9.0 (in flight: microsoft/apm-action#44).

Direct answers to your three questions:

1. Layout you described is exactly right. Root apm.yml with a marketplace: block + per-plugin apm.yml + plugin.json under plugins/<name>/. The new Repo shapes doc names this the monorepo shape (one of four canonical shapes) with a paste-ready scaffold.

2. Don't add anything to dependencies.apm[] for locally-referenced plugins. The marketplace.packages[].source: ./plugins/<name> pointer is the only wire required. dependencies: is for consumer-side installs (pulling other people's plugins into your project); it has no role on the producer side of a marketplace monorepo.

3. Re: "plugin doesn't show in copilot plugin list" — you're right that APM Packages ≠ Copilot Plugins, but with the v0.14 producer surface there's no friction. Two paths:

   • The packaging side (your repo): APM scaffolds + builds the marketplace artifacts (apm pack --marketplace=all emits one marketplace.json per format under build/.claude-plugin/, build/.codex/, etc.). Whether Copilot CLI / Claude Code / Codex picks them up is a function of which format you build and where the consumer points their CLI.
   • The consumer side: This is intentionally out of APM's scope. We document the install patterns for each assistant on Installing from marketplaces (e.g. claude plugin marketplace add ..., copilot extension install ..., the Cursor cursor-plugin.json registration flow). We never name a single vendor CLI in apm pack output — that's a policy, since plugins built today get installed by assistants that ship next month.

For your CI: swap to microsoft/apm-action@v1 mode: release (apm-action#44, post-tag) and your release.yml collapses to:

- uses: microsoft/apm-action@v1
  with:
    mode: release
    release-tag: ${{ github.ref_name }}

That single step runs apm pack --check-versions --check-clean --json, builds per-format marketplace artifacts, computes sha256 sidecars, detects drift, generates release notes, and publishes via gh release create.

Worked example: DevExpGbb/zava-agent-config is a 7-plugin monorepo using exactly this shape; it'll be migrated to mode: release post-tag.

Closing this discussion as resolved. Open follow-ups welcome.

[Daniel Meppiel (danielmeppiel)]

Follow-up: golden-path now docs-attested.

Three docs polish edits landed in #1384 pointing readers from the concepts in producer/repo-shapes.md and producer/releasing-from-any-ci.md at the live reference deployment: DevExpGbb/zava-agent-config @ v6.1.2 ships 7 plugins out of a monorepo-hybrid layout, with a single repo-wide tag attaching 15 release assets (7 tarballs + 7 .sha256 + marketplace-6.1.2.json).

One correction to my earlier reply on the CLI flag: apm pack does expose -m, --marketplace TEXT (comma-separated, accepts values like claude,codex or all). The default behavior is to build every output configured under marketplace.outputs: in your apm.yml, so most producers never need to pass the flag — but it is available when you want to override per-build (e.g. publish a Claude-only preview from a feature branch).

Pipeline that ships zava end-to-end: .github/workflows/release.yml. Requires apm 0.14.0 + apm-action v1.9.1 or newer.