Skip to content

Back-compat frontmatter reader for metadata-nested fields #159

@LadyBluenotes

Description

@LadyBluenotes

What

As part of bringing SKILL.md frontmatter into Agent Skills spec compliance, several Intent-specific fields are moving from the top level of the frontmatter into the spec's metadata map (type, library, library_version, framework). Once that move happens, any skill published with the old top-level shape will stop being read correctly unless the readers understand both shapes.

Where this comes from

Today these fields are read from the top level in two places:

  • scanner.ts (readSkillEntry) reads type and framework and puts them on the SkillEntry that flows to consumers.
  • staleness.ts (checkStaleness) reads library_version to compare a skill's targeted version against the installed package version.

When the generator starts emitting these fields under metadata instead, existing published skills (which still carry the top-level shape) would read as missing type/framework/library_version — silently degrading discovery and staleness detection during the migration window.

This only concerns the scalar fields that move into metadata. The array fields (sources, requires) move to a different structured surface, not metadata, and are tracked separately.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions