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](/Folders/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.

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. 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. 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. 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](/resellers/credentials) 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](/resellers/credentials) 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.

| Action | Effect on a live agent | Reversible | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------ | | Enable | Makes the skill available to load the next time a trigger phrase matches. No effect on runs already in progress. | Yes, disable it whenever you like | | Disable | Does not interrupt a run that has already loaded the skill. It only stops the agent from loading it again on the next trigger match. | Yes, re-enable it whenever you like | | Remove (uninstall) | Deletes the skill folder from the workspace entirely. An agent still referencing it simply stops matching, there's nothing left to load. | Only by reinstalling it from scratch |
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 Dashboard Signup 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.

The full reference: SKILL.md fields, trigger design, and how the skill creator works. Where the per-agent Skills tab lives, and what else needs prompts and instructions. The Apps section skills sits inside, and how it splits from tools and MCP servers. Why binding references a stored secret instead of ever showing you one.

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

What a skill is, quickly.

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

Where skills come from.

Adding a skill for a client.

Skills that need a secret.

Maintaining them.

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

Next steps.