Generate every official and community Skill inventory

[webrdaniel]

Note

This issue was AI-generated based on an AI analysis of Apify’s agent-facing contracts.

Current problem

The official Skill registry contains five Skills, while agents.md and agent onboarding list four. The awesome-skills repository has 12 non-template Skill files but fewer README and marketplace entries. Agents therefore discover different capabilities depending on which official surface they read, and downstream plugins cannot reliably determine ownership, freshness, compatibility, or evaluation status.

Why this reduces adoption and usage

• Agents miss shipped capabilities when they read an incomplete inventory and may choose another provider or build unnecessary custom logic.
• Orphaned or stale entries reduce confidence that installing a Skill will produce a maintained, compatible workflow.
• Plugin and documentation teams cannot safely automate distribution without stable ownership, version, and freshness metadata.
• Fragmented discovery weakens both initial Skill installation and repeat use after Skills evolve.

Desired state

Every inventory is generated from explicit official/community/experimental metadata with owner, version, digest, freshness, compatibility, and evaluation status.

Acceptance criteria

• Define the canonical Skill metadata needed by registry, docs, plugins, README, badges, and marketplaces.
• Generate official downstream lists so all five Skills are present.
• Resolve awesome-skills filesystem, README, badge, and marketplace mismatches through a linked follow-up.
• Fail CI on orphaned, missing, or stale inventory entries.
• Remove hard-coded official Skill names from downstream docs and generated plugins.

Priority: P0. Estimated effort: M.

[webrdaniel]

Assigned @birosrichard

[birosrichard]

Generate official downstream lists so all five Skills are present: done.
agents.md is now served from a route that builds its table from the same bundle as index.json, so they can't disagree: apify/apify-web#6408. agent-onboarding.md was one of six docs pages with a hard-coded table, two of them stale; those are fixed.

Define the canonical Skill metadata: suggest dropping.
The Agent Skills spec already defines the frontmatter set, and it's closed: name, description, license, compatibility, metadata, allowed-tools. owner, version, and freshness aren't valid fields, and index.json's entry is a fixed five, so defining them means inventing a parallel standard for five Skills we author ourselves. Maybe we can discuss with @patrikbraborec if we can use the license, compatibility, metadata, and allowed-tools in our skills.

The rest doesn't need it:

• Fail CI on stale entries — skills-ref validate as one workflow step, plus an assert that plugin.json / gemini-extension.json / marketplace.json versions agree. They don't: 2.0.0 vs 1.0.0.
• Remove hard-coded names — README table + badge and 4 docs pages can come from the filesystem walk generate_agents.py already does.