Reference

Two different things that both make an agent more capable, and they answer different questions.

A toolkit answers what may this agent do? It's a list of actions: read a ticket, post to Slack, look up a calendar.

A skill answers how should it handle this kind of task? It's a set of instructions the agent pulls in when relevant, like a runbook.

Toolkits are capability. Skills are technique.

Toolkits: the list of what it may do

Triage needs to read tickets, add a label, and post to one Slack channel. That's three actions, and that's the toolkit. Scout needs to read a few things and nothing else, so its toolkit is smaller still.

Keep them short. This is the advice everyone ignores and then wonders why the agent picks the wrong tool. Four actions and the choice is obvious. Forty and it's a guess. A short toolkit also makes each turn cheaper, since the list of tools goes to the model every time.

Grant a whole family of provider actions only when the role really needs the whole family. "Read all of GitHub" is rarely what you meant.

A toolkit is not a security boundary

Worth being precise about, because it looks like one.

The toolkit says what the job needs. The role says what is actually permitted. Both apply, and the stricter one wins. An agent whose toolkit contains an action its role forbids simply cannot call it.

Which gives you two useful dials. Change the toolkit when you're shaping what the agent is for. Change the role when you're deciding what it's allowed to reach.

Skills: instructions for a kind of task

A skill is reusable guidance for work that shows up in more than one place.

Things Northwind IT keeps as skills:

• How to write up an incident so a client can read it.
• The offboarding checklist, in order, with the bits people forget.
• How to phrase a "we can't reproduce this" reply without sounding dismissive.
• How to format a monthly report so it matches the last eleven.

The point of a skill is that it's specific enough to be worth loading only sometimes. Standing instructions describe the enduring job. Skills describe how to handle a particular kind of task when it comes up.

A skill can narrow the tools used for that task. It can't hand the agent something it wasn't granted.

Sharing skills across clients

Skills have two scopes:

• Project skills live in one project and are edited there.
• Organization skills are written once and available to every project.

If you run one project per client, organization skills are how you keep your house style consistent. Write the incident write-up skill once; every client's agents can use it.

Being available isn't the same as being assigned. Somebody still has to give an agent the skill. When an organization admin edits a shared skill, every agent using it picks up the change on its next turn. And a shared skill can't be deleted while an agent still has it assigned, so nothing disappears from under you.

How this fits with everything else

The tool manifest is the one to look at when an action you expected isn't there. It's the result of combining the agent's assignments, its role, whether the provider is connected, and any narrowing for that session. You don't manage it directly; you read it when something's missing.

In the app

Open Build > Agents, pick an agent, then edit Skills and Toolkits from Configure.

Organization owners and admins manage shared skills under Organization > Skills, including seeing which agents use each one. Inside a project, shared skills show as read-only. Copy one into the project when a client needs a variant that shouldn't follow the shared version.

From the terminal:

mobius skills list
mobius org-skills list
mobius org-skills usage <skill-id>

Start with the smallest set that can finish one real task. Run it. Look at which tools the agent actually used. Add something only when a missing action blocked real work.

Some shapes that work:

Exact assignment fields are in the interactive API reference. Terminal use is in the CLI command reference.

Next

• Write the standing job description in agent definitions.
• See what goes in a toolkit: actions.
• Set the hard boundary with roles.
• Share structured data through tables.