Skip to content

Accommodate allowed-tools type ambiguity in spec #1

@dacharyc

Description

@dacharyc

Analysis of ~200+ Agent Skills produced many failures related to a specific issue: some skills declare allowed-tools as a YAML list (e.g. allowed-tools: [Read, Write, Bash] or as an expanded YAML sequence), but skill-validator types that field as a string. When the YAML parser hits a list where it expects a string, it fails immediately and can’t validate anything else about the skill.

This is an open question about the spec. The Agent Skills specification defines allowed-tools as follows:

  • A space-delimited list of tools that are pre-approved to run
  • Experimental. Support for this field may vary between agent implementations

In practice, a list makes more semantic sense (it is a list of tools), and several Skills independently chose to implement it that way. Many other skills implement as YAML. For now, skill-validator should probably permit both due to the type ambiguity, instead of flagging valid YAML as a warning or error.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions