docs/solutions/workflow-issues/2026-03-28-skiller-plugin-conflicts-should-skip-local-skills.md
plate has local skills in .agents/skills with names like ce-plan and document-review, while the globally enabled compound-engineering plugin ships the same skills from the marketplace.
skiller apply treated every conflict as "namespace the plugin copy," so .agents/skills kept getting duplicate plugin-managed folders like compound-engineering-ce-plan even though the local skill already owned the canonical name.
skiller only had one conflict strategy for plugin-managed skills: keep the local folder and install the plugin item under a namespaced destination.
That is reasonable for plugin-vs-plugin collisions, but it is the wrong behavior for local/manual skills that already intentionally shadow plugin content. There was no config surface to say "if a local skill already exists, skip the plugin copy entirely."
Add a skills.plugin_conflict_strategy setting to skiller.toml with:
namespace as the default behaviorskip to drop plugin items when their base name is already reserved by a local or other non-managed folderThe implementation changes were:
plugin_conflict_strategy from [skills]propagateSkills into ClaudePluginSyncskipplate then opted into the new behavior:
[skills]
enabled = true
plugin_conflict_strategy = "skip"
The duplicate folders only existed because plugin sync had no "local wins, plugin skips" mode.
Once skip is enabled, skiller stops assigning namespaced destinations for plugin items whose base names are already taken by local/manual skills. Existing namespaced plugin folders also get cleaned up on the next sync because they are no longer expected manifest entries.
skills.plugin_conflict_strategy = "skip" in repos that intentionally keep local/manual skills checked in alongside globally enabled marketplace plugins.namespace as the default in skiller so plugin-vs-plugin collisions still remain visible instead of disappearing silently.skiller apply produces dirty compound-engineering-* skill folders, check whether the repo already has the same base skill names locally before blaming the rename logic.