Summary
SkillCustomization and AgentCustomization are ChildCustomizations, so they must live under a top-level container. But the only container variants are Plugin and Directory. A host that surfaces customizations it discovered itself — grouped by a logical source/scope that is not a real watched directory and not an Open Plugins plugin — has no honest container to put them in. Please add a generic grouping container variant.
Current state in the spec (0.4.0)
Customization (top-level) is one of Plugin / Directory / McpServer. (Skill, Agent, Prompt, Rule, Hook are ChildCustomizations only — they can't be top-level.)DirectoryCustomization is documented as a directory the host watches; it carries writable and a file://-style uri, and a load state.- There is no neutral "labeled group of children" container.
The problem
To surface, say, skills/agents grouped by origin (project vs. user vs. some other logical scope) that don't correspond 1:1 to a watched directory, a host has to reuse DirectoryCustomization with writable: false and a synthesized, non-file:// uri standing in for the logical source. That's a semantic stretch: it claims a filesystem directory exists where one doesn't, and it overloads a uri that consumers may reasonably expect to be a real path.
Proposal
Add a Customization::Group (GroupCustomization) top-level variant: a labeled, non-filesystem collection of ChildCustomizations. Suggested fields:
id — stable container id (for toggling / addressing).name — human label for the group/source.children — the contained ChildCustomizations.enabled — container enable/disable (consistent with Plugin / Directory).load — a load/diagnostic state (consistent with Directory), so a group can report its own load health, errors, and warnings.icons / range — optional, for parity with the other customizations.- optionally an
origin / source descriptor for the logical scope.
This models host-discovered, non-file-backed groupings honestly, and is generally useful to any host that surfaces customizations it found itself rather than from a plugin or a watched directory.
Backwards compatibility
A new top-level enum variant is additive; existing producers and consumers are unaffected until they emit or read it. (Consumers that exhaustively match on the Customization variants will need to handle the new case — standard for any new variant.)
Relationship to other proposals
All three are independent; this one is purely about the container a host groups children under, so any combination can land in any order.
Summary
SkillCustomizationandAgentCustomizationareChildCustomizations, so they must live under a top-level container. But the only container variants arePluginandDirectory. A host that surfaces customizations it discovered itself — grouped by a logical source/scope that is not a real watched directory and not an Open Plugins plugin — has no honest container to put them in. Please add a generic grouping container variant.Current state in the spec (0.4.0)
Customization(top-level) is one ofPlugin/Directory/McpServer. (Skill,Agent,Prompt,Rule,HookareChildCustomizations only — they can't be top-level.)DirectoryCustomizationis documented as a directory the host watches; it carrieswritableand afile://-style uri, and aloadstate.The problem
To surface, say, skills/agents grouped by origin (project vs. user vs. some other logical scope) that don't correspond 1:1 to a watched directory, a host has to reuse
DirectoryCustomizationwithwritable: falseand a synthesized, non-file://uri standing in for the logical source. That's a semantic stretch: it claims a filesystem directory exists where one doesn't, and it overloads a uri that consumers may reasonably expect to be a real path.Proposal
Add a
Customization::Group(GroupCustomization) top-level variant: a labeled, non-filesystem collection ofChildCustomizations. Suggested fields:id— stable container id (for toggling / addressing).name— human label for the group/source.children— the containedChildCustomizations.enabled— container enable/disable (consistent withPlugin/Directory).load— a load/diagnostic state (consistent withDirectory), so a group can report its own load health, errors, and warnings.icons/range— optional, for parity with the other customizations.origin/sourcedescriptor for the logical scope.This models host-discovered, non-file-backed groupings honestly, and is generally useful to any host that surfaces customizations it found itself rather than from a plugin or a watched directory.
Backwards compatibility
A new top-level enum variant is additive; existing producers and consumers are unaffected until they emit or read it. (Consumers that exhaustively match on the
Customizationvariants will need to handle the new case — standard for any new variant.)Relationship to other proposals
modelandtoolsfields toAgentCustomization— agent behavior configuration.All three are independent; this one is purely about the container a host groups children under, so any combination can land in any order.