[BUG] `apm pack` ignores the declared `skills:` subset filter on git dependencies — bundles the entire upstream repo, or silently bundles nothing

[desaiuditd]

Describe the bug

When an apm.yml dependency declares a skills: subset filter on a git dependency, apm install correctly deploys
only the named skills to harness directories (.agents/skills/, .claude/skills/, etc.). apm pack (default
--format plugin) does not respect the same filter: depending on local cache state, it either bundles the entire
upstream repository for that dependency, or silently omits the dependency's skills entirely.

To Reproduce

Manifest (apm.yml):

dependencies:
  apm:
    - git: mattpocock/skills
      ref: bc4cf90
      skills:
        - productivity/grill-me
        - productivity/grilling

Steps and results, all run against the same manifest:

1. apm install — correct. Only .agents/skills/grill-me and .agents/skills/grilling deployed (verified by listing
   .agents/skills/ directly; also matches apm.lock.yaml's skill_subset field).
2. apm pack (no other commands in between) — bundles the entire mattpocock/skills repository under
   build/<pkg>/skills/: every top-level category in the upstream repo (tdd, teach, deprecated, zoom-out,
   writing-great-skills, handoff, triage, and roughly 20 others), not just the 2 declared skills.
3. apm install → manually rm -rf apm_modules → apm pack — bundles zero skills from mattpocock/skills. No
   warning or error is emitted; the bundle is simply missing that dependency's content.
4. apm install → apm prune → apm pack — same result as step 2. apm prune does not remove or touch the cache for
   this dependency, since it's still referenced in apm.yml (just with a narrower skills: list).

Expected behavior

apm pack should bundle exactly the skills recorded as deployed for the active target (matching what apm install
already deploys and what apm.lock.yaml's skill_subset / deployed_files record), regardless of whether the raw
apm_modules/<owner>/<repo>/ cache happens to be present.

Actual behavior

apm pack reads directly from the raw, unfiltered apm_modules/<owner>/<repo>/skills/ cache directory rather than from
the filtered, already-deployed output. When that cache is missing, there is no fallback, and the bundle silently omits
the dependency instead of erroring or re-resolving it.

Environment (please complete the following information):

• apm --version reported 0.23.1
• pyhton --version reported 3.14.6
• macOS, zsh.

Impact

Any package that declares a filtered skills: subset on a git dependency cannot produce a correct plugin bundle via
apm pack today. This blocks using apm pack as a distribution path for packages with OSS skill dependencies scoped to
a subset of a larger upstream repo.

[github-actions]

Triage Panel Verdict -- Issue #1999

Title: apm pack ignores the declared skills: subset filter on git dependencies

Triage Decision: ACCEPT (confirmed bug, high priority)

---

Panel Review

DevX UX Expert

Clear regression between apm install and apm pack. The skills: subset filter is correctly honored by apm install (and reflected in apm.lock.yaml's skill_subset / deployed_files fields) but bypassed by apm pack, which reads directly from the raw, unfiltered apm_modules/ cache directory.

Two distinct failure modes are reproduced:

• Over-bundling: when the module cache is present, apm pack ships the entire upstream repository, not just the declared skills.
• Silent under-bundling: when the cache is absent (e.g. after rm -rf apm_modules), apm pack emits no warning and produces a bundle missing the dependency entirely.

Neither failure mode surfaces a diagnostic. This breaks the distribution contract: a user who relies on apm install to scope dependencies cannot produce a correct plugin artifact via apm pack.

Supply Chain Security Expert

Silent over-bundling is a supply-chain integrity failure. An apm pack artifact may ship upstream code the author never audited or intended to distribute. The deployed_files field in the lockfile already encodes the canonical intent; apm pack must consult that record rather than the raw cache. Shipping unreviewed upstream content to downstream consumers undermines the trust model of the package ecosystem.

APM CEO (Arbiter)

This directly blocks the packaging and distribution use case, which is one of APM's core value propositions. The fix is bounded: make apm pack consult apm.lock.yaml's skill_subset / deployed_files records (or replicate the same subset-filtering logic already present in the apm install path) rather than reading from the raw module cache. Accept for next patch release.

---

Decision

Dimension	Value
Decision	ACCEPT
Type	bug
Area	distribution, lockfile
Priority	high
Suggested milestone	next patch (maintainer to confirm)

Suggested next action:

Fix apm pack to source skills from apm.lock.yaml's skill_subset / deployed_files rather than the raw apm_modules/ cache. Add a regression test that verifies pack output matches install output for a manifest with a skills: filter, covering both the cache-present and cache-absent scenarios.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · 91.2 AIC · ⌖ 13.1 AIC · ⊞ 9.2K · ◷