Skip to main content
REUSABLE PLAYBOOKS

​
A skill is a playbook an agent reaches for on its own. You stock the shelf, the agent picks the book.

With the skills permission granted, you can install, upload, enable, disable and remove skills for a client’s workspace from the Apps section. This page covers how to pick the right ones, add them safely, wire up any secret they need, and keep a live client’s skill set healthy. It also covers the single most confusing part of this permission: what skills unlocks on its own, and what it silently doesn’t.

The basics

​
What a skill is, quickly.

A skill is a portable behaviour pack an agent loads at runtime. Physically it’s a folder containing a SKILL.md file: YAML frontmatter on top, a Markdown body underneath holding the actual instructions. Nobody invokes a skill by hand. The agent reads the incoming request, matches it against every enabled skill’s trigger phrases, and loads whichever playbook wins. That matching happens the same way in chat, inside a workflow, and on an unattended schedule or trigger, so a skill you set up once keeps firing everywhere the agent runs.Because a skill is just a folder, it isn’t tied to the workspace it was built in. A skill you wrote for one client’s recurring task can be uploaded as an archive into a different client’s workspace, provided that client has actually granted you skills.

skills/refund-request-handler/SKILL.md
name:refund-request-handler
title:Refund Request Handler
description:Confirms an order, checks refund eligibility, then issues the refund in Stripe.
version:1.3.0
triggers:“process a refund for order”, “customer wants their money back”
credentials:stripe_api_key
context:fork
# Refund Request Handler
1.Confirm the order number and the stated reason before touching Stripe.
A few frontmatter fields matter more than the rest once you’re the one adding skills for a client:
name and title. The internal identifier and the human-readable label you see in the catalogue and in an agent’s Skills tab.
description and version. What the skill is for, and which build of it is currently installed.
triggers. The natural-language phrases that make an agent reach for this skill instead of another one.
credentials. Any secret the skill declares it needs. Covered in full further down this page.
context. inline runs the skill in the main conversation. fork runs it in a sub-agent with its own context budget, useful for a long or noisy task you don’t want cluttering the main chat.
What makes a skill worth adding is that it fires the same way everywhere. Once a skill is enabled and an agent is watching for its triggers, a chat message, a workflow step, and an unattended schedule run all match against the same phrases the same way. You aren’t configuring three separate behaviours for three surfaces, you’re configuring one.This page is about choosing, adding and maintaining skills in a delegated session, not the field-by-field mechanics of authoring one. For the full reference on SKILL.md, triggers, and everything else a skill can declare, see Skills.Keep that page open alongside this one if you’re drafting a new skill’s frontmatter for the first time. It’s the place to check a field you’re unsure about before you save.
Read this before you touch anything

​
One permission runs the shelf. A second runs the agent.

skills unlocks the Skills sub-page under Apps, plus a Skills tab inside Agent Studio. Those are two different surfaces, and only one of them actually responds to your clicks with skills alone.

The client sees this as a single toggle: “Allow reseller to manage Skills”, described to them as “Install, enable, disable, or remove skills from the skill marketplace.” That “skill marketplace” wording is older client-facing copy. The Apps section itself calls the same collection the catalogue today, which is the term used throughout this page.
With Skills alone
Browse and search the catalogue from Apps → Skills.
Install a skill, or upload one as an archive.
Enable or disable a skill at the workspace level.
Remove a skill from the workspace entirely.
Author a new skill conversationally with the built-in skill creator.
Needs Agents too
Turn a skill on or off for one specific agent, in that agent’s Skills tab.
Open the credential binding drawer for a skill that needs a secret.
Any other control inside Agent Studio, for any tab, not just Skills.
skills alone does not give you working per-agent controls. It gives you the workspace-level skill set: install, upload, enable, disable, remove, all from Apps. But the per-agent Skills tab lives inside Agent Studio, and the whole studio is wrapped in a disabled fieldset unless the session also holds prompts_and_instructions. With skills alone, you can open an agent’s Skills tab and see which skills it has enabled, but every control on it is disabled. You cannot toggle a skill on or off for that agent, and you cannot open its credential binding drawer. This is the single most confusing thing on this page, and it catches people who assume “manage Skills” means the whole skills story end to end.
In practice: with only skills granted, you’re stocking and maintaining the shelf. Whether a given agent actually picks a skill up, and whether it’s wired to the secret it needs, is a decision made from Agent Studio, which needs prompts_and_instructions as well. If a client wants you fully hands-on with skills, tell them both toggles need to be on, not just the one labelled Skills.It’s worth saying plainly why this split exists rather than treating it as an inconsistency. A skill installed at the workspace level is still just sitting on the shelf. Deciding which agent picks it up, and whether it’s allowed to touch a paid API on the client’s behalf, is closer to editing that agent’s actual configuration than it is to app management, which is exactly the boundary prompts_and_instructions already draws for prompts and instructions. Skills sits on both sides of that line, which is why it needs a partner scope to be fully usable.The same shape shows up one level up, too. Apps itself unlocks with either tools_and_integrations or skills, so a client can grant you access to install and enable skills without handing over anything else in Apps. That’s a deliberate, narrow grant, and the Agent Studio lock is the same idea applied one layer deeper.
Sourcing

​
Where skills come from.

Every skill in a workspace arrived by one of four routes. All four land in the same place: the workspace’s own skill catalogue, visible from Apps → Skills.

BundledShips with the app by default. Nothing to install.
Catalogue installPulled in from the shared skill catalogue.
Uploaded archiveA packaged skill folder, dropped in from outside Actionist.
Skill creatorAuthored conversationally, by describing what you want to an agent.
Workspace catalogueWhere every skill lives once it’s in, regardless of how it got there.
“Catalogue install” above means browsing the shared catalogue and pulling a single skill into this specific workspace. Once it’s in, it sits in that workspace’s own catalogue view alongside anything that arrived by the other three routes, that’s the “Workspace catalogue” node the pipe ends on. Two different things share the word catalogue here: the shared source you install from, and the workspace’s own list of what’s currently installed.With skills granted, you can drive three of those four routes yourself: installing from the catalogue, uploading an archive, and running the conversational skill creator to author something new. The fourth, bundled skills, needs no action from anyone.
Publishing to the community catalogue is off, categorically, in a delegated session. This applies to every kind of listing, whether you authored it yourself in that session or are trying to push up something built earlier. Authoring and publishing on someone else’s behalf isn’t something the reseller programme allows. You can build a skill for a client and use it in their workspace. You cannot put it out for other workspaces to install.
Once a skill lands in the workspace catalogue, Apps → Skills treats it the same regardless of which of the four routes brought it in. There’s no separate “uploaded” or “bundled” tab to check later, install, enable, disable and remove all work identically no matter where the skill originally came from.
Walkthrough

​
Adding a skill for a client.

Everything up to the last step happens with skills alone. The last step needs prompts_and_instructions too, so read it as a checkpoint rather than something you can always finish yourself.

1

Open Apps → Skills

A session holding only skills lands directly on the Skills sub-page, not on Browse. The Apps container itself opens with either tools_and_integrations or skills, whichever the session has.
2

Search the catalogue, or upload an archive

Look for a skill that matches a task the client actually does repeatedly. If nothing in the catalogue fits and you have a packaged skill folder, upload it as an archive instead.
3

Install it, then enable it

Installing adds the skill to the workspace. Enabling makes it available for an agent to load the next time a trigger phrase matches. Both steps happen from Apps, and both work with skills alone.
4

Confirm it's actually turned on for the agent that needs it

Open that agent’s Skills tab in Agent Studio. If the session also holds prompts_and_instructions, flip the per-agent toggle on there. If it doesn’t, the tab is view-only for you, so ask the client to flip it, or confirm with them that both scopes should be granted going forward.
Install for what the client’s team actually does over and over, not for everything that looks useful. A workspace full of enabled skills gives an agent more trigger phrases to weigh against every incoming request, which makes it slower to find the right one and easier to mismatch. Start from a real recurring task, add the one skill that covers it, and confirm it fires correctly before you add the next.If you’re not sure a task is recurring yet, wait. A skill installed for a one-off request is one more thing to review later, for no ongoing benefit.
Priya · Agency ops lead
A client’s support team keeps asking their agent to handle the same kind of refund request by hand. Priya installs a refund-handling skill from the catalogue, enables it workspace wide, then confirms with the client that the agent should also have it turned on directly.
setup in about 10 minutes
Priya · weekly reporting
A different client wants a weekly summary sent every Friday. Priya uploads a skill built for a previous client’s near-identical reporting format, enables it, and leaves the per-agent assignment and any credential binding to the client’s admin since this session only holds skills.
upload in under 5 minutes
Priya · quarterly cleanup
Reviewing a long-running client’s Apps → Skills list, Priya finds two skills nobody has referenced in months. She disables both rather than removing them straight away, in case they’re still bound somewhere she hasn’t checked, then removes them for good once a few weeks pass with no complaints.
review in about 15 minutes
Credentials

​
Skills that need a secret.

Some skills declare a credentials requirement in their frontmatter, the refund-handling example above needed stripe_api_key. That requirement has to be satisfied before the skill can actually run.

A skill’s credential requirement is wired up in a binding drawer, opened from that skill’s row in an agent’s Skills tab, which puts it squarely inside the two-scope catch above. To open it at all, the session needs both skills and prompts_and_instructions. Once it’s open:
You can reference an existing stored credential. Pick one already saved in the client’s Credentials Vault and bind it to the skill, without ever seeing the plaintext value.
You cannot create or reveal a secret. Pasting in a brand-new value, or viewing what’s already stored, is permanently off-limits, no matter what else is enabled.
If a skill needs a secret the client hasn’t stored yet, the honest answer is to ask them to add it to the Credentials Vault first. Once it exists, you can bind it. See Credentials and API keys for the full boundary, including why there’s no reveal button anywhere in a delegated session.
Check whether the session also holds prompts_and_instructions. The binding drawer lives inside an agent’s Skills tab in Agent Studio, and that whole studio is disabled without it. skills alone gets you to the workspace-level install and enable, not the drawer.
No. Creating or revealing a secret is off-limits regardless of what else is enabled, including for testing. Bind an existing stored credential, or ask the client to add the one you need.
That’s a conversation for the client, not a workaround on your end. Point them at Credentials and API keys so they know what the vault expects, then bind it once it’s stored.
No. Rotating a stored credential doesn’t touch existing bindings. The skill picks up the new secret automatically the next time it resolves the credential, so a rotation on the client’s side doesn’t require you to redo the binding.
None of this is a workaround to route around. It’s the same hard limit that applies everywhere else in a delegated session: reference what’s stored, never see or set the value underneath it.
Keeping the shelf healthy

​
Maintaining them.

Enable, disable and remove sound like three flavours of the same action. They aren’t. Each one behaves differently against a run that’s already using the skill, and picking the wrong one on a client that’s mid-workday is the fastest way to turn a routine cleanup into a support ticket.

Enable. Turns availability back on for the next matching trigger. The fastest way to undo a disable.
Disable. Pauses future loads without touching a run already in progress. The safe default when you’re unsure.
Remove. Deletes the skill folder outright. Undoing it means reinstalling, not flipping a switch back.
Read that middle row twice if you’re about to disable something on a client that’s mid-workday. Disabling is the gentle option: nothing currently running gets cut off, it just won’t be picked up again. Removing is the blunt one: the skill is gone, and any agent that used to reach for it quietly stops reaching for anything at all, with no error to flag it.
Changing a client’s skill set while their team is actively working on it can produce confusing behaviour even when nothing technically breaks. A disabled skill still finishes its current run, but the very next request that would have matched it now falls through to something else, or to nothing. If you’re removing a skill rather than just disabling it, do it outside the client’s active hours when you can, or tell them beforehand so a sudden change in an agent’s behaviour doesn’t read as a bug.
When you’re not sure which action is appropriate, disable first. It costs nothing to reverse, it never interrupts a run already underway, and it buys you time to confirm with the client before you commit to something that needs a fresh install to undo. Save removal for a skill you’re confident the client’s workspace genuinely doesn’t need anymore.That single habit, disable before you remove, covers most of the situations that would otherwise turn into an awkward conversation with a client mid-workday.
Skills, for a client workspace

​
Stock the shelf. Let the client wire the last mile.

Install, enable and maintain from Apps with skills alone. Per-agent assignment and credential binding need prompts_and_instructions alongside it.

Open the DashboardSignup as a Partner

Publishing to the community catalogue is never available in a delegated session, for any listing.
Credential binding references stored secrets only, and never reveals or creates one.

Keep going

​
Next steps.

Skills

The full reference: SKILL.md fields, trigger design, and how the skill creator works.

Agents

Where the per-agent Skills tab lives, and what else needs prompts and instructions.

Apps, tools and integrations

The Apps section skills sits inside, and how it splits from tools and MCP servers.

Credentials and API keys

Why binding references a stored secret instead of ever showing you one.