Spec-compliant skill name and metadata-nested scalar fields

[LadyBluenotes]

What

Generated SKILL.md frontmatter is rejected by the canonical Agent Skills validator (skills-ref). Two separate problems:

1. Non-spec top-level keys. The validator allows exactly six top-level frontmatter keys — name, description, license, compatibility, metadata, allowed-tools — and treats any other top-level key as an error. Intent emits type, library, library_version, and framework at the top level. These are scalars and belong under the spec's metadata map (a string→string mapping for client-specific data).

2. The name value is itself invalid. Intent emits names like routing/file-based. The spec requires name to contain only lowercase alphanumerics and hyphens (so a / is "invalid characters") and to equal the parent directory name (which a multi-segment value cannot). So the slash name fails validation two different ways.

Where this comes from

• Reported in discussions Generated skill frontmatter compliance. #116 (generated frontmatter not spec-compliant) and Intent-specific fields in skill #140 (Intent-specific fields should move under metadata). In Intent-specific fields in skill #140, the top-level fields are flagged as invalid by the Agent Skills schema in VS Code, and moving them under metadata makes validation pass.
• The slash-name problem is the specific error in Skill name is invalid with slash reduxjs/redux-toolkit#5303 — that project copied Intent's name pattern and now has the same validation errors, and is waiting on Intent to change the pattern before they do.

Scope

This covers the frontmatter changes for the scalar fields and the name:

• name becomes the spec-legal leaf segment matching its parent directory; the namespace it used to encode is carried by the skill's directory path instead.
• type, library, library_version, framework move under metadata.
• The generator templates (generate-skill) emit the new shape; validate errors on non-spec scalar keys, on a non-string metadata map, and on a slash/non-leaf name.

The array fields (sources, requires) are not part of this — they can't live in the string-only metadata map and move to a separate structured surface, tracked in its own issue.