RFC Feedback Changelog — What changed and why

[johnlindquist]

Feedback received during the RFC period and how each item was addressed in v1.0.0.

TL;DR: Design principles for v1.0

These principles emerged from the feedback and guided all decisions:

1. Define the plugin format, not host behavior. The spec covers what a plugin contains and how to parse it. How hosts present plugins to users is not prescribed.
2. Defer to existing open standards. Skills use the Agent Skills spec (agentskills.io). MCP servers use the MCP spec (modelcontextprotocol.io). No need to redefine what's already defined.
3. Remove rather than add. When in doubt, cut it. Anything not essential for v1.0 consensus goes to an appendix or a future version.
4. Host decisions stay with hosts. Installation, scoping, caching, namespacing format, and CLI design are all host-specific.

---

Feedback that shaped v1.0

Plugin structure and manifest

Feedback	Resolution
The additive/replacement path mode distinction is too complex. It adds roughly 20% to the spec length for little usability gain.	Removed. All path fields use a single model: manifest paths override defaults. Include the default explicitly to keep it.
The manifest should be required for v1.0. No basename derivation fallback.	Done. plugin.json is required with name as the only required field.
The Root SKILL.md fallback breaks cross-host compatibility.	Removed. Skills must use the standard skills/name/SKILL.md layout.
Multiple manifest search paths create ambiguous precedence for developers and host implementers.	.plugin/plugin.json is the canonical required location. Vendor-prefixed manifests are supplemental and host-defined.

Component types and prescriptiveness

Feedback	Resolution
The spec shouldn't standardize sub-components that aren't already open standards. Skills and MCP should reference their respective specs as the source of truth.	The core spec (Sections 1-12) normatively defines only skills (referencing agentskills.io) and MCP servers (referencing modelcontextprotocol.io). All other component types (commands, agents, rules, hooks, LSP, output styles) moved to non-normative Appendix D. Supplemental file extensions (.txt, .markdown) removed entirely.

Namespacing and host behavior

Feedback	Resolution
Requiring both plugin name and server name in tool identifiers is too strict for platforms with 128-character tool name limits.	Downgraded from MUST to SHOULD. Hosts can adapt the format.
Too many implementation MUSTs. The spec should define what a plugin contains, not how hosts present it.	Namespacing downgraded to SHOULD. Installation, scoping, and host UX decisions left to hosts.

Installation and host implementation

Feedback	Resolution
Loading, installation, and resolution order are product decisions and too prescriptive for cloud-based hosts.	Removed entirely. The spec does not define installation scopes, caching, storage paths, CLI flags, or resolution strategies.

Environment variables and expansion

Feedback	Resolution
It's unclear whether generic ${ENV} interpolation is supported.	Clarified. Generic environment variable interpolation (e.g., ${HOME}) is not required. Hosts may support it.
${PLUGIN_ROOT} expansion conflicts with manifest path rules that require paths to start with ./.	Resolved. Expansion applies only to runtime config (MCP server command, args, env, cwd), not to manifest discovery paths, which are always relative ./ paths.
Vendor-prefixed environment variables lead to host-specific plugin code.	Removed entirely. Only PLUGIN_ROOT and PLUGIN_DATA are defined. Hosts define their own equivalents in their own docs.

User configuration and secrets

Feedback	Resolution
User configuration (prompting for API keys, keychain storage) is too complex for v1.0.	Removed entirely. No userConfig field in the spec. Deferred to a future RFC.

Manifest metadata

Feedback	Resolution
The version field was described inconsistently (required SemVer vs. recommended).	Aligned. Section 6.3 says "Version string (Semantic Versioning recommended)" and Section 11 says plugins should use Semantic Versioning.

[connor4312]

Great work on the spec and I appreciate your responsiveness to feedback 👏 I'll implement this to ship in VS Code's April 15th release!