Add --add flag to preserve existing skills during install

[romivol]

Is your feature request related to a problem? Please describe.
Every time I run apm install with a --skill flag, it removes previously
installed skills from the target directory. This makes it impossible to
build up a set of skills incrementally - each new install silently wipes
out everything that was installed before.

Describe the solution you'd like
Add an --add flag that installs a skill additively, without removing
existing skills in the target directory.

Example workflow that should work:
apm install repo.git --skill grill-me --target claude
apm install repo.git --skill qa --target claude --add
← both grill-me AND qa should now be present

Without --add, the current behavior removes grill-me when qa is installed.

Describe alternatives you've considered
Declaring all skills upfront in apm.yml works as a workaround, but it
defeats the purpose of having a CLI -sometimes you just want to quickly
add one more skill without editing a config file.

Additional context
This behavior is especially surprising because most package managers
(npm, pip, cargo) are additive by default -installing a new package
never removes existing ones. APM doing the opposite is unintuitive and
easy to miss, since there's no warning when skills are deleted.

[github-actions]

Triage Panel Verdict

Issue #1771: "Add --add flag to preserve existing skills during install"

Thank you for this well-articulated feature request, @romivol.

---

Panel Review

DevX UX Expert
This issue surfaces a genuine usability gap. The current behavior -- silently removing all previously installed skills when a new apm install --skill is run -- violates the principle of least surprise. Every major package manager (npm, pip, cargo, brew) is additive by default: installing a new package does not remove existing ones. The proposed --add flag is minimal, clear, and consistent with established CLI conventions. The workflow example in the issue makes the desired behavior unambiguous and easy to spec.

Supply Chain Security Expert
Additive install is sound in principle. Implementation will need to handle: (1) namespace collision detection when two skill repos define the same skill name, (2) ensuring existing integrity checks are applied to each newly added skill independently. These are implementation constraints, not blockers for accepting the feature.

OSS Growth Hacker
The "silent deletion" framing is accurate. This is a sharp edge that generates negative first impressions for power users experimenting with multi-skill workflows. Closing this gap improves APM's ergonomic parity with npm/pip/cargo and reduces support friction for new adopters trying to compose skill sets incrementally.

APM CEO Arbiter -- Verdict: Accept
The current destructive-by-default behavior is a legitimate friction point inconsistent with package-manager conventions. The fix is bounded (one new flag, existing behavior preserved as default), non-breaking, and well-scoped. The workaround (declaring all skills upfront in apm.yml) exists but defeats the purpose of a CLI-first workflow. This belongs in the backlog as a lower-priority enhancement.

---

Triage Decision

Dimension	Value
Classification	Feature request -- CLI install ergonomics
Scope	Bounded: add --add flag to apm install; preserve destructive behavior as default
Blocking?	No -- workaround: declare all skills in apm.yml
Suggested next action	Accept for backlog. When implementing, define conflict-detection behavior (what happens when --add encounters a skill name already installed from a different repo?).

Labels Applied

• area/cli -- install command, new CLI flag
• theme/portability -- aligns APM install semantics with standard package-manager conventions
• priority/low -- quality-of-life improvement; non-blocking workaround exists
• status/triaged -- consumed by scheduled sweep

---

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 · sonnet46 1.2M · ◷

[PreethamNoelP]

Hi! I'd like to contribute this feature. Before I start, a couple of questions to make sure I'm aligned with the intended design:

1. Should --add be the flag name, or would --no-clean / --preserve be more consistent with existing CLI conventions in APM?
2. Should the additive behavior eventually become the default (matching npm/pip semantics), with a --clean flag for the current overwrite behavior? Or is the current default intentional for reproducibility reasons?
3. Is there a preferred test location I should follow for new CLI flag tests?
   Happy to take this on once the design direction is confirmed. Thanks!

[romivol]

Hi @PreethamNoelP :) heads up that a maintainer (@sergio-sisternes-epam) has
already opened a PR for this in #1786, so the feature is being handled there.
Thanks for offering to take it on!

[PreethamNoelP]

Thanks for letting me know!