{"version":"2.1.222","anchor":"commands-skills-and-plugin-manifests-accept-a-free-form-meta","canonical_anchor":"commands-skills-and-plugin-manifests-accept-a-free-form-meta","heading":"Commands, skills and plugin manifests accept a free-form metadata object","tier":"use","area":"Plugins","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.222\/e\/commands-skills-and-plugin-manifests-accept-a-free-form-meta","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.222","markdown":"### Commands, skills and plugin manifests accept a free-form metadata object\n\nYou can add a free-form metadata block to command, skill and plugin files that Claude Code keeps but ignores.\n\n**What**\n\nAuthors can attach an arbitrary `metadata` object to command and skill frontmatter and to plugin manifests; it is preserved through parsing but never interpreted by Claude Code.\n\n**Details**\n\n- Frontmatter parsing keeps `metadata` when the value is an object; the parsed command shape and its serialization allowlist both include \"metadata\".\n- Plugin manifest validation warns with the fragment \"'metadata' must be a free-form object\" and states the value will be ignored at load time when it is not an object.\n- Both the plugin manifest schema and the skill schema document the field as a free-form map for the author's own use, for example entitlement or catalog fields.\n- Metadata keys are no longer folded into the computed `declaredFields` set.\n\n**Evidence**\n\n`Free-form metadata for the plugin author's own use (e.g. entitlement or catalog fields). Preserved on the parsed manifest but not read by Claude Code.`, `'metadata' must be a free-form object`\n\n- Area: Plugins\n- Names: `metadata`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 0\/5"}