Skip to main content
A skill hub is a catalog of skills your users browse and install from inside the app. A skill is a folder, a SKILL.md telling the agent how to do something plus any scripts it needs, so a hub is how users get one without cloning a repository or knowing where the files belong. Installing does not equip an agent. It adds the skill to the user’s own pool of installed skills, and equipping an agent is a separate step:
1

Install into the pool

The user reads a skill’s SKILL.md on its card and installs it, with nothing to fill in. Every hub feeds the same pool, so what came from which registry stops mattering once it is installed.
2

Equip an agent's workspace

In a chat, the user picks from the pool to unpack the skill into that agent’s workspace. The agent can follow it from that point on.
The pool belongs to the user rather than to any chat, so one install is equipped in as many workspaces as they like. A local folder can also be uploaded straight into a workspace, whether or not it came from a hub.

Available Skill Hubs

AgentScope ships one skill hub today, and any other catalog can be wrapped with a custom hub: ClawSkillHub works with no arguments, and every field below has a default:
Configure ClawSkillHub

Quickstart

1

Start the Agent Service

Skill hubs are a feature of Agent Service, so you need a running service and a frontend to browse from. Follow the Agent Service quickstart to boot the bundled examples/agent_service backend together with the examples/web_ui frontend.
2

Register the hub

Pass your hubs to create_app through skill_hubs. That one argument brings the routes, the store page, and the install flow with it:
Register a skill hub
Register several to give users a choice of catalogs, each with its own hub_id.
Registering two skill hubs under the same hub_id fails at startup rather than silently shadowing one.
3

Browse and install

Restart the service and open the Skill page. The sidebar lists your registered hubs plus Mine, the user’s own collection. Pick a hub, search, and open a card to read its SKILL.md before deciding.
Browsing a skill registry

Browsing a skill registry from the Skill page.

Install adds it to the user’s collection right away, with nothing to fill in. Everything installed shows up under Installed skills:
Installed skills

The skills a user has installed.

4

Equip an agent

Open a chat, expand the Skill panel, and choose Add. Two tabs cover both sources:
Equipping an agent with a skill

Equipping an agent with a skill, from the collection or a local folder.

Uploads are bounded so one user cannot fill a workspace: at most 100 files, 50 MB per file, and 500 MB in total. A folder whose name is taken installs under a numbered suffix instead of overwriting.
Equipping an installed skill fetches its files from the hub at that moment, because an install keeps the skill’s description rather than a copy of its files. If the hub is unreachable, that skill is reported as failed with the reason, and the others in the same request are still equipped.

Custom Skill Hub

Any catalog of skill folders becomes a hub by subclassing SkillHubBase. Three methods are required, one to browse, one to fetch a single listing, and one to serve its archive:
A hub over an internal catalog
Three more things shape how a hub behaves: The archive should hold the skill’s folder with a SKILL.md at its root, either as a single top-level directory or as the files directly. Both layouts work, and the folder is renamed to the installed skill’s name.

Control Visibility Per User

All three methods receive user_id as their first argument, so a catalog does not have to look the same to everybody. Filter on it to run a per-team allowlist, gate paid listings on entitlements from your billing system, or keep a draft skill visible only to its authors:
A catalog that differs per user
download takes user_id for exactly this reason, so apply the same filter there too. Hiding a card from the listing alone is not access control: both get_skill and download are reachable with any id the caller cares to guess.

Reuse One HTTP Client

A hub lives for the whole lifetime of the service, so it can hold a connection pool instead of opening one per request. Implement the async context manager methods and the service enters every hub on startup, closing them on shutdown:
Open and close a shared client

Further Reading

MCP Hub

The same idea for MCP servers.

Skill

How the agent discovers and follows a skill.