[FEATURE] Publish APM CLI releases with Packslip metadata
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 3.9k
- Forks
- 365
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 132
Description
Is your feature request related to a problem? Please describe.
APM already provides package-level reproducibility through apm.yml and apm.lock.yaml, but installing the APM CLI does not also give an agent version-matched guidance for using that CLI. Teams must provide their own instructions, and those instructions can drift from the installed APM version.
This creates practical problems for agents and developers. For example:
- An agent should know when to use
apm installto reproduce the dependencies declared by a project. - An agent investigating a dependency or content problem should know how to use
apm auditand the lockfile. - An agent preparing a package should know how to use
apm packand how the resulting package is distributed. - An agent compiling configuration for a client should know when to use
apm compile -t copilotor another supported target. - An organization reviewing its agent dependencies should know how to export the lockfile as CycloneDX or SPDX with
apm lock export.
These workflows need guidance that matches the installed CLI version. Consumers such as mise also need release metadata that identifies the correct APM artifact and the skills shipped with it. Packslip can connect those two needs without changing APM's package registry, dependency resolution, or package integrity checks.
Describe the solution you'd like
Integrate the Packslip format into the APM CLI release process so each published APM CLI release can include a signed packslip.sigstore.json release manifest alongside its existing release assets.
The release workflow should:
- Generate a Packslip manifest from the final native release artifacts, after any archive rewriting, signing, or notarization.
- Record the
github.com/microsoft/apmidentity, version, artifact names and digests, supported platforms, formats, executable paths, and host requirements. - Describe only resources shipped with the release, such as agent skills, if the release intentionally includes them.
- Sign and verify the manifest and artifacts before publication, then upload the manifest alongside the existing release assets.
- Document how Packslip-aware consumers can discover and verify the release. The format should remain consumer-neutral, with mise as one interoperability target.
The first version should publish accurate release metadata without changing existing APM installation paths or executing generated resource commands during publication. It succeeds when a Packslip-aware consumer can verify the official release identity and digest, select the correct platform artifact, and continue to use existing APM installation paths unchanged.
For example, a release could declare a versioned apm skill. The skill could give an agent guidance such as:
Use `apm install` to install the dependencies declared in apm.yml.
Use `apm audit` to inspect package integrity and detect drift.
Use `apm pack` to bundle an agent package for distribution.
Use `apm compile -t copilot` to generate Copilot instructions from the project manifest.
Use `apm lock export --format cyclonedx` or `--format spdx` to create a software inventory.
The skill should be versioned with the CLI so that command names, options, and behavior remain aligned. After installing the Packslip-enabled CLI, a mise consumer could inspect and synchronize the declared skill:
mise use packslip:github.com/microsoft/apm
mise skills ls
mise skills sync --dir .agents/skills
The agent would then find the matching skill under .agents/skills/apm/SKILL.md and could apply it when helping with APM tasks.
Packslip can declare that skill in several ways. The paths below are illustrative and would need to match the published release layout:
# Skill directory inside the selected CLI archive
resources: |
skill/apm-release=archive:apm/share/skills/apm-release
# Skill distributed as a separate signed release asset
resources: |
skill/apm-release=asset:dist/apm-release-skill.tar.gz
# Skill read from the source repository at the signed release commit
resources: |
skill/apm-release=repo:.agents/skills/apm-release
Archive and asset sources are covered by signed digests; repository sources are pinned to the release commit. Generated exec skills should be a later, explicitly reviewed option because their output is not separately signed.
Additional context
Packslip is a signed release manifest format for artifacts, platform selection, executable paths, host requirements, provenance links, and resources such as agent skills and SBOMs. Here it would describe the distribution of the APM CLI, while APM continues to manage agent packages and their dependencies.
Relevant references:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the APM CLI release workflow and the step that publishes final native artifacts, then read the Packslip release and publishing specifications. Define how the manifest is generated, signed, verified, and uploaded without changing installation paths or executing generated resource commands. Done means a consumer can verify the release identity and digest and select the correct platform artifact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, release
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100