The next step for agent tooling is an open skills marketplace: a place where people can publish, review, and install composable skills with transparent behavior. A marketplace only works if discovery and trust are first-class. Every skill should clearly show what tools it can call, whether it makes remote HTTP requests, and what credentials it needs. That turns skills from opaque prompt blobs into auditable software units.
The model I want is simple. Local skills should be installable with minimal risk and run offline when possible. Remote skills should be explicitly marked, versioned, and permission-scoped so users understand blast radius before enabling them. Publishing should include checks like declared dependencies, human-readable docs, and a security profile. Consumption should include one-click install, reproducible versions, and rollback.
If we get this right, we unlock a healthy ecosystem: builders can ship focused capabilities, teams can curate trusted bundles, and users can mix local automation with service integrations safely. Open beats closed here because no single vendor can cover every workflow. A good open skills marketplace becomes the app store for agents, but with stronger introspection, tighter permissions, and community-driven quality.
Openclaw is all the rage currently and its still early. I went through the install process and wanted to make a notification system. After several hours I gave up because I didn't want to start debugging a 1.3 million lines of code repository for something I can do myself. Then I discovered the core of Openclaw which is Pi. I have built smaller similar systems myself over the last years automating prompts but not much tool calling. Pi is much more bare bones. With zeno the idea is to focus down the comms channel to Telegram and using Openrouter as a default. Agentic skills aren't well defined in terms of their security. My conception is that skills are either well known and trusted (linux/git as a skill). If it touches foreign APIs it needs to be audited and adjusted. I want a repository of skills that are relevant to me and with code that I can audit quickly. In my view it is important to distinguish between skills that are local and those that call HTTP for various reasons. One is that services need credential and version management. Also it means that are inherently less trustworthy and needs auditing. It will be much more powerful combining both local and remote calls, currently this isn't cleanly separated. In openclaw the assumption is that people want to call agents only locally and don't interact with services. The much more powerful case is calling services. Pi avoids MCP and thats a good thing. The world is built on HTTPs APIs and we want to wrap them first. Whats missing is a good way to combine them locally.