Proposal: Add Agent Facets as a community-maintained ecosystem

[eXamadeus]

Hi Dependabot team!

I'm the maintainer of Agent Facets. I'd love to discuss adding "facets" to Dependabot as a community-maintained ecosystem. For context, Agent Facets is a package manager for agent capabilities such as skills, commands, agents, and MCP servers. It's very analogous to NPM. We provide an open-source CLI tool (facet) and provide a free registry for hosting (https://agentfacets.io).

We have users that would love to use Dependabot to manage their facets. To that end, we are more than happy to build the integration ourselves and maintain it perpetually. I scanned through how Julia, OpenTofu, Deno, and a few other newer ecosystems were added, and having us maintain it seems to be the preference. Let me know if that's not the case.

For Dependabot purposes, the project model is pretty straightforward and very similar to NPM, which I'll use as a reference/comparison:

• facets.json (≈ package.json): declares the facets a project depends on
• facets.lock (≈ package-lock.json): records the resolved versions, source information, and integrity hashes
• Agent Facet registry (≈ npm registry): facets are versioned and immutable
• facet install (≈ bun/npm install): resolves and installs the declared dependencies
• facet update (≈ bun/npm update): checks for newer registry releases and updates the project state

Both facets.json and facets.lock are meant to be committed, just like their analogs package.json and package-lock.json.

One thing I do want to clarify up front is the beta status of the project. The CLI itself is about to exit the beta stage. We are ready to lock the manifest and lockfile format versions down to 1.0 as part of this work.

The hosted registry is still labeled beta, but that is mostly around things like pricing and team management for the private side of the registry. The registry API, package/version model, public publishing, and file formats are already stable and generally available.

For a first Dependabot implementation (assuming we make the cut), I was thinking we could keep the scope tight:

• public registry-based facets only
  • defer private registry authentication to a follow-up
  • ignore local and Git-backed facets for update purposes
• facets.json and facets.lock are the only files that need parsing/modification
  • manifest bumps/adjustments (when required)
  • lockfile regeneration, including integrity metadata
• version updates only
  • transients are not fully supported yet, so out of scope
• release timestamps and Dependabot cooldown support

I'd like feedback on this, but we assume it would be preferable to rely on facet's own resolver where practical rather than reimplementing package resolution semantics in Ruby. We can expose a stable machine-readable CLI interface for Dependabot if that is preferable, for example, JSON output for update planning and lockfile generation (a la facet update --dry-run --json).

Our main goal is to determine if this approach aligns with how you'd like new community-maintained ecosystems handled. We're new as a platform, but have more than enough desire and time to curate and maintain the ecosystem. I hope you see fit to include us.

If you think there's a path forward, we'd appreciate guidance on:

1. Would you prefer agent-facets or facets for the ecosystem identifier?
2. Is invoking the upstream CLI for resolution the preferred approach, or would you rather see the resolution logic implemented directly in Ruby?
3. Is the public-registry-only scope above appropriate for an initial beta?
4. Are there any service-side or release requirements we should account for before opening an implementation PR?

We're prepared to build and maintain this on our side, and we're happy to work within the beta ecosystem process before moving toward general availability. Again, this is a lot of detail (wanted to make it clear we're ready to commit), but the goal is to discuss the possibility and get feedback/thoughts.

Thanks for taking a look and building such a fantastic platform!

[eXamadeus]

I created #16365 to track this in Issues, which I believe is the maintainers' preferred way to discuss this.

I'll move our discussion to whichever format is preferred.