[FEATURE] Extend per-dependency subsetting to agents (parallel to skills:)

[normandev92]

Problem

Installed richlander/dotnet-inspect with a skill subset:

apm install richlander/dotnet-inspect --skill dotnet-inspect --skill compatibility --skill signals --force

The three skills deployed as asked -- but the package's four agents (burndown-curator, burndown-discovery, burndown-runner, ladder-tester) all deployed too, translated into every target dialect: 12 files across .claude/agents/, .github/agents/, and .codex/agents/. Those agents are the upstream repo's own development workflow (issue burndown bots, a test-ladder runner) and mean nothing to a consumer of the package.

Looking at models/dependency/subsets.py, only a skills: subset exists -- there is no agents: equivalent, so a package's agents are all-or-nothing. #1894 asks for the same thing for hooks; this is the agents leg of that family.

Deleting the files by hand works for one commit, but every subsequent apm install re-deploys them, and the audit's deployed-files tracking then disagrees with the working tree.

Proposal

Support an agents: list in the object-form dependency (and a repeatable --agent flag), mirroring the skills: semantics: subset persisted in apm.yml and apm.lock.yaml, deterministic on bare installs, empty list invalid, absence means all. Same shape would presumably extend to prompts and hooks (#1894) so consumers can take exactly the primitives they want from a package.

Environment

• apm 0.27.0 (winget, Windows 11)
• Package: richlander/dotnet-inspect (plugin package with skills + agents)

---

Disclosure: this report was drafted with AI assistance; the install behavior and code reference were verified on the environment described.

[github-actions]

Triage Panel Verdict

Issue #2491: [FEATURE] Extend per-dependency subsetting to agents (parallel to skills: list)

DevX UX Expert:
The asymmetry is jarring: --skill flags work, but --agent does nothing, and the package's internal CI bots deploy into the user's workspace on every install. Re-deploys actively fighting manual deletions is a trust-eroding loop. The fix has a clear, already-established UX pattern in the skills: subset; users will immediately understand --agent and agents: by analogy. The feature directly addresses the "I got files I didn't want and can't keep them out" class of complaint.

Supply Chain Security Expert:
Agent subsetting reduces the deployed footprint to exactly what the consumer declared, which is strictly better from a supply chain perspective. Fewer deployed agent files = smaller prompt-injection surface. No new trust boundary is introduced; the existing subset-validation and lockfile-recording machinery already handles the pattern.

Python Architect:
The subsets.py parse_skill_subset / skill_subset_filter_tokens pair is the clean template. An agents: leg needs parse_agent_subset, agent_subset_filter_tokens, propagation through DependencyReference, the _apm_yml_writer, the install command's CLI flags, and the agent integrator's deploy filter -- roughly the same surface as skills but without the leaf-flattening complication (agents are flat by convention). This is bounded and well-precedented; no architectural ambiguity.

APM CEO Synthesis:
This is a natural, well-scoped extension of an existing first-class feature, reported by a real user with a concrete broken workflow. The code path is understood, the pattern is established, and the user is currently working around it with manual deletions that break audit tracking -- a data-integrity problem, not just inconvenience. Accept for 0.9.4 alongside #1894 (hooks subsetting) to close the whole primitive-subsetting family in one milestone.

---

Decision: ACCEPT

Labels proposed: type/feature, area/cli, area/lockfile, priority/high, status/accepted

Milestone: 0.9.4

Suggested next action: Add parse_agent_subset / agent_subset_filter_tokens to models/dependency/subsets.py, wire --agent CLI flag, propagate through DependencyReference, lockfile, and agent integrator deploy filter, mirroring the skills: implementation.

---

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 · 132 AIC · ⌖ 8.72 AIC · ⊞ 9.2K · ◷