Skip to content

Consider adopting agentskills.io skill.json package manifest #52

@mathieubellon

Description

@mathieubellon

Context

The cross-vendor Agent Skills standard (agentskills.io) is proposing an optional
skill.json package manifest (agentskills/agentskills#214). We should decide
whether — and how — this repo participates as a package.

skill.json lives at the repo root and provides publisher-side metadata that
tooling can consume without walking the tree or parsing individual SKILL.md
files:

  • package metadata (name, version, license, repository)
  • the skill list with paths, descriptions, SRI digests, categories, tags
  • runtime requirements (requires.tools, requires.min_agent_versions)
  • intra- and cross-package skill dependencies

Singular skill.json (publisher declaration) is deliberately distinct from
plural skills.json (consumer-side requirements). When the two disagree,
skill.json is authoritative for tooling; SKILL.md stays authoritative for
runtime agents.

Why this matters for us

A root skill.json would declare our four skills (scan-secrets,
create-honeytokens, scan-machine, check-hmsl) with digests and
requires.tools: ["ggshield"], so package managers (skmr, skillman, skillbox, …)
stop re-deriving our skill list by walking the directory tree. It is low-cost
and low-risk relative to standing up a hosted endpoint — potentially worth
shipping first.

Open questions

  • Is the spec stable enough to adopt, or do we wait? (PR/spec still in flux.)
  • How do digest values get generated and kept in sync in CI so the
    manifest can't drift from disk? (ties into our existing duplicated-reference
    drift concern)
  • What goes in requires? At minimum ggshield; do we pin a min version?
  • Does skill.json duplicate anything already in our per-vendor manifests
    in a way that could drift? How do we keep them aligned?

Non-goals (for now)

  • Not committing to ship skill.json yet — this issue is to decide direction.
  • Not replacing the existing Claude/Cursor/Codex manifests or SKILL.md
    frontmatter; this would sit alongside them.

Related

Links

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

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