Open a public "open source" and "open contribution" Packmind for truly public Agent package management

[a-scolan]

I feel like a public "open source" and "open contribution" Packmind website for agent package distribution, just like NPM, Maven, etc. would be very helpful and connect better with the wider developer community

Right now Packmind requires auth, organizations and sometimes hosting, which makes it kind of closed to the open source community as you have to enroll new users to the org, which is not really how things get done there.

Having a truly open contribution Packmind repo for wider, unauthenticated access and distribution would get adoption from open source communities trying to structure and reuse their agent packages (agent.md, skills, hooks, etc.)
This would be make it able to reach a bigger market and share the concept outside of close-sourced enterprise settings.

[MaloPromyze]

Thanks for raising this ! The current auth/org model is definitely a barrier for open-source contributors, and a public registry for packmind packages in the vein of NPM or PyPI is something we find genuinely compelling.

We can't commit to a timeline right now, but we'd love to use this issue to sharpen the idea before we get there. A few things worth discussing:

• Consumption: fully unauthenticated browsing and pulling?
• Publishing: CLI-based (packmind publish)? PR-based?
• Namespacing & trust: how should packages be organized and quality-signaled?

What does the ideal experience look like for you?

[a-scolan]

I think the best similar experience is NPM, as it is lightweight and pretty robust. Maven and such get a bit too complicated for an MVP set of features.

1. Consumption: Fully unauthenticated
   Exactly like NPM and others, willfully publishing packages to the broader community fosters growth. Anyone would be able to browse the web directory to read an agent.md or package details without logging in.
   Also, pulling packages via the CLI (e.g., packmind install @my-user/cool-agent) should be completely unauthenticated.
   If someone has to create an account just to try an open-source agent package, we might lose their attempt at using open-sourced packages and contributing to community.

2. Publishing: CLI-based (packmind publish). A PR-based registry (like DefinitelyTyped or Homebrew core) creates an immediate bottleneck for maintainers and slows down the community. Self-serve publishing is much more scalable.
   A CLI-based approach is the way to go IMO.

   • The flow: A contributor creates a free Packmind account (auth is required to publish, not to consume), runs packmind login, and then uses packmind publish from their directory.
   • Automation: By allowing users to generate access tokens, publishing can be easily hooked into CI/CD pipelines (like GitHub Actions) so packages automatically update when a release is tagged on GitHub.

3. Namespacing & Trust:
   Namespacing: NPM’s scoping system is nice enough. Packages should be tied to a user or org namespace (e.g., @username/agent-package or @orgname/skill). This prevents name squatting on generic terms and makes it clear who authored the package.

   Trust: Instead of Packmind having to manually curate or vet packages, trust should be crowd-sourced and transparent. The registry page for a package should surface:

   • The README.md (and/or agent.md).
   • A link back to the public GitHub/GitLab repository.
   • Basic metrics (e.g., weekly downloads, version history, github stars ?).
   • If possible, a badge if the package is published directly from a verified GitHub Actions workflow (similar to how NPM handles provenance).

[MaloPromyze]

Thanks for your input !

We're capturing this carefully however we can't commit to a timeline on our end right now. We'll keep this open and revisit when bandwidth allows.

That said, feel free to draft a PR 😄

[a-scolan]

Today I realized most of the feature I asked for here is handled through IDE Plugins:

• Copilot : https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/plugins-creating
• Claude : https://code.claude.com/docs/en/plugin-marketplaces

These are pretty good but not very standardized and one could challenge the versioning, dependency chaining and marketplace functionnalities I think.
I guess having a Packmind support for plugins, with public distribution could be useful still.

[a-scolan]

Also, there is now Microsoft's APM that would possibly check all the functionnalities I expect, although it is not interoperable cross-tooling (Claude, Cursor, Copilot...) it seems.

[MaloPromyze]

Indeed it looks like the industry is moving toward marketplaces as the new standard for distribution.

We are actively working on a way to integrate the major players of the ecosystem in Packmind while keeping the advantages Packmind offers.

Hopefully that would answer your needs for the distribution part (you will still need to be authenticated to author your Packmind playbook)