registry-broker-skills: instruction files for the HOL Universal Agentic Registry
AI agent skills for the Universal Registry - search, chat, and register 72,000+ agents across 14+ protocols. Works with Claude, Codex, Cursor, OpenClaw, and any AI assistant.
At a glance
- What is it?
- This repository ships skill definition files, not a runtime. It teaches an AI assistant how to call the Registry Broker API for agent search, chat and registration, and the value you get depends entirely on whether you want that API as your discovery layer.
- Who is it for?
- Adopt it if you already want the HOL Universal Agentic Registry as your discovery surface and you use an assistant that loads markdown instructions, because the CLI path (npx @hol-org/registry search, resolve, chat, skills lint) needs no build step. Do not adopt it if you need an offline index or a self-hosted broker: every command in the README resolves against hol.org.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What this repository actually contains
The README states plainly that the repository holds skill definitions: instruction files that teach an AI coding assistant how to interact with the Registry Broker API. That framing matters because the name invites the assumption that this is an SDK or a server. It is neither. The TypeScript in the repository supports the skill packaging and validation tooling, while the artifact most consumers will load is SKILL.md, a markdown file the README says can be consumed by Claude Code and Claude Desktop via MCP or direct skill loading, by OpenAI Codex and ChatGPT as context instructions, by Cursor as project instructions, and by OpenClaw and ClawHub in their native skill format. The problem it addresses is narrow and real: an assistant that has never seen the Registry Broker API cannot construct a valid UAID, cannot tell a search call from a resolve call, and will guess at parameter names. A skill file removes that guessing by putting the API surface in the model's context. Who it is for follows from that. If you are building an agent directory workflow and you want your assistant to do the discovery work, this is the piece that makes the assistant competent. If you want a library you import into a service, you are looking at the wrong repository.
The registry it points at, and the fourteen protocols behind it
The Universal Registry is described as one standards-compliant API over live agent inventory drawn from fourteen protocols: AgentVerse (Fetch.ai), Virtuals, A2A, MCP, ERC-8004, x402 Bazaar, OpenRouter, NANDA, Near AI, OpenConvAI, XMTP, ANS, PulseMCP and HCS-10. Those are not fourteen interchangeable sources. A2A and MCP describe how agents are invoked, ERC-8004 concerns on-chain verification, x402 covers payment rails, XMTP is a messaging transport, and ANS is a naming layer. Flattening them into one search index is the actual product claim, and it is the part worth scrutinising. The repository does not document a normalisation schema for cross-protocol records, so how a Fetch.ai agent and an MCP server are reconciled into a comparable result set is not visible from the material here. The README does point to a live stats endpoint at hol.org/registry/api/v1/dashboard/stats, which is the honest way to check current inventory rather than trusting the figure in the project description. Treat the aggregation as the broker's responsibility, not something this repository implements.
The CLI is the real interface, and it is where the workflow lives
Everything runnable in the README goes through npx @hol-org/registry, which means no clone and no build. Discovery starts with a natural-language query: npx @hol-org/registry search "trading bot". Platform-wide counts come from npx @hol-org/registry stats. A UAID resolves to agent detail with npx @hol-org/registry resolve uaid:aid:fetchai:agent123, and the UAID format in that example is uaid:aid:<source>:<identifier>, which is the shape an assistant has to produce correctly. Chat is the first command that needs credentials: export REGISTRY_BROKER_API_KEY="your-key" followed by npx @hol-org/registry chat uaid:aid:fetchai:agent123 "Hello!", with the README noting XMTP as the default transport. Two commands sit outside the broker key. Claiming a Moltbook agent requires MOLTBOOK_API_KEY="mb_xxxxx" npx @hol-org/registry claim, and the README says that verification is required to send as an agent and also unlocks broker registration. Registering a verified agent is a separate step: npx @hol-org/registry register uaid:aid:moltbook:yourAgent --description "Updated description". Balance checks use npx @hol-org/registry balance, which tells you the chat and registration paths are metered against credits rather than free. The split between discovery commands that need no key and write or send commands that do is the most useful thing to internalise before wiring this into anything.
Publishing your own skill: init, lint, list
The second half of the CLI targets the skill registry itself, and it is the part that makes this repository a two-way tool rather than a read-only client. After exporting REGISTRY_BROKER_API_KEY, the README shows npx @hol-org/registry skills config, then npx @hol-org/registry skills init --dir ./my-skill --name "my-skill" --version 0.1.0 to scaffold a manifest, npx @hol-org/registry skills lint --dir ./my-skill to validate it, and npx @hol-org/registry skills list --name "my-skill" --limit 5 to confirm it is findable. Validation is anchored to a published schema at schemas/skill.schema.json, which the README also links as a JSON Schema badge. That is a concrete constraint rather than a suggestion: a manifest that fails the schema will not lint clean, and the schema is the authority on required fields. The lint step is also the cheapest way to find out whether your skill is structured the way the registry expects before you spend credits on publishing. Note that the README excerpt ends mid-command after skills list, so the full publish path is not visible in the supplied material and should be read from the product docs at hol.org/docs/registry-broker/ before you rely on it.
Where this is the wrong tool
The dependency on a hosted service is the limitation that decides most adoption questions. Every command in the README resolves against hol.org. There is no documented self-hosted broker, no local index, and no offline mode, so an air-gapped environment or a deployment that cannot call an external HTTPS endpoint is out of scope. The second constraint is credential surface: search and resolve work without a key, but chat, register, skills config and skills list all sit behind REGISTRY_BROKER_API_KEY, and claim sits behind a different MOLTBOOK_API_KEY entirely. Two key types with different scopes is a small thing to get wrong in CI and a confusing thing to debug when a command fails for authentication rather than syntax. Third, the release history in the repository is dominated by metadata and DOI plumbing, with tags such as zenodo-seo-2026-02-23-1144 and zenodo-bootstrap-2026-02-23. That tells you the project invests in citation and syndication infrastructure. It does not tell you how often the skill definitions themselves change when a protocol's API shifts, and the material does not answer that question. If your assistant's context is pinned to an old SKILL.md and a protocol changes underneath it, the failure will look like a malformed request rather than a stale instruction file.
The alternative: call the OpenAPI surface directly
The obvious comparison is skipping the skill layer and generating a client from the spec. The README links an OpenAPI 3.1.0 document at hol.org/registry/api/v1/openapi.json, plus a Postman collection and an Insomnia import URI pointing at the same file. A generated client and a SKILL.md solve different problems. Generated code gives you typed request and response objects, compile-time checking against the current spec, and a build step that breaks loudly when the schema changes. A skill file gives you nothing typed, but it works in contexts where you cannot run a build: a chat session, a Cursor project, a Codex prompt. The difference in failure mode is the deciding factor. A generated client fails at compile time. A skill file fails at request time, when the model emits a plausible but wrong UAID or an outdated parameter. If you are writing a service, generate from the OpenAPI spec. If you are handing an assistant the ability to explore agent inventory interactively, the skill file is the only one of the two that fits.
Licence, maintenance and what you are signing up for
Apache-2.0 covers the repository contents, which in practice means the skill definitions, the schema and the tooling. It does not cover the Registry Broker service, and the README gives no separate terms for the API. That distinction matters if you plan to redistribute the skill files inside a commercial product: the licence text governs the files, while your use of hol.org endpoints is a separate question the repository does not answer. On maintenance, the honest position is that the material shows active pushes and a steady release cadence, but the releases visible here are Zenodo and DOI oriented rather than API oriented, so you cannot infer from them how quickly skill definitions track protocol changes. The repository does include .zenodo.json and CITATION.cff for citation metadata, and a syndication kit at references/SYNDICATION-KIT.md, which suggests the maintainers treat the skill definitions as a citable artifact. That is a reasonable signal about intent and no signal at all about response time when A2A or MCP changes. Pin the version you load, and re-run npx @hol-org/registry skills lint against your own manifests after any upgrade rather than assuming compatibility.
Editorial conclusion
Adopt it if you already want the HOL Universal Agentic Registry as your discovery surface and you use an assistant that loads markdown instructions, because the CLI path (npx @hol-org/registry search, resolve, chat, skills lint) needs no build step. Do not adopt it if you need an offline index or a self-hosted broker: every command in the README resolves against hol.org. Before committing, read schemas/skill.schema.json, run npx @hol-org/registry skills lint --dir ./my-skill against your own manifest, and check whether your use case requires the REGISTRY_BROKER_API_KEY or the separate MOLTBOOK_API_KEY for claim.
Community notes