Organisation Capabilities

The Capabilities page under Admin → Organisation → Settings is where you control which external integrations and PebbleFlows assets are available to users in your organisation.

Find it at Admin → Organisation → Settings → Capabilities.

Don’t confuse this with User Settings → Capabilities. This page is organisation-level provisioning — what’s available to be enabled by users. The User Settings page is where individual users actually toggle them on for their own sessions.

What a capability is

A capability is anything that extends what PebbleChat or PebbleFlows can do beyond the base model. Capabilities are grouped into tabs:

The page header banner reads “View enabled capability instances across all categories and enable additional capabilities from the catalog.”

The Enabled Instances table

The table on the page lists capability instances that are currently enabled for your organisation. Each row shows:

• Integration — the provider name
• Tools — a brief summary of what tools the integration exposes
• Status — the on/off toggle for the instance plus a status label: Requires User Configuration (each user must complete OAuth themselves), Enabled, Disabled, or Connected (shown after a successful connection test)
• Actions — configure, re-authenticate, remove

Above the table is an Enable a Capability button (top-right) for adding new capability instances from the platform catalogue.

Step-by-step: enabling Microsoft 365

1. Click Enable a Capability
2. Browse the catalogue and pick Microsoft 365
3. The integration is added to the Enabled Instances table with status Requires User Configuration
4. Configure the OAuth client — paste the Microsoft Entra ID app’s Client ID and Tenant ID into the integration’s settings
5. Save
6. Tell your users they can now connect their Microsoft accounts via User Settings → Capabilities
7. Each user authenticates with their own Microsoft account; the org-level config provides the OAuth shell, the user-level config provides the per-user identity

For full setup details, see the Microsoft 365 integration guide.

Step-by-step: enabling Jira

1. Click Enable a Capability
2. Pick Jira from the catalogue
3. Configure the Jira instance URL and OAuth credentials
4. Save
5. Users connect their personal Jira accounts via User Settings → Capabilities

Tabs explained in detail

Integrations

Top-level connections to third-party platforms via MCP (Model Context Protocol). One integration provides many tools — Microsoft 365, for example, provides email, calendar, files, Teams, OneNote, and SharePoint tools.

Tools

Individual tools, including the integration tools (one row per Microsoft 365 sub-tool, etc.) plus standalone tools like Brave Search, Tavily Search, Calculator, Code Interpreter.

This is where you’d disable a specific tool from a capable integration — for example, leaving Microsoft 365 enabled but disabling the “send email” tool to prevent PebbleChat from sending email on users’ behalf.

Skills

Skills are Claude Code-compatible prompt templates — a Persona plus optional supporting files and code — that PebbleChat loads on demand when they match a user’s task. They’re a major capability with their own documentation at PebbleChat → Skills. This tab is where you manage them at organisation level.

What you see in this tab

Every skill that’s been imported or created at platform, organisation, workspace, or user scope. The table has six columns:

• Skill — the skill’s name
• Description — what it does
• Scope — a chip reading Platform, Org, Workspace, or User
• Status — the enable/disable toggle with its status label
• Deploy to all users — admin-only toggle; on deploys the skill to everyone, off undeploys it (see Rolling out a skill)
• Actions — open, edit, remove

Details such as the skill’s runtime (none for prose-only, python, or node — deferred), its security scan result, and its source are shown in the skill’s detail dialog rather than in the table.

Above the list are a shared search box and a Create or Import dropdown button (create a new skill, import a skill from the library, or import a plugin from a repository), alongside the Enable a Capability button.

Rolling out a skill: Off, Available, Deployed

Open a skill’s catalogue detail dialog as an org admin and you’ll see a Rollout section — a plain-language ladder instead of a single deploy button:

Two toggle rows control the ladder independently: Organisation (Off / Available / Deployed) and This workspace (Off / Available). Each stage shows a one-line consequence description, so you always know exactly what you’re switching on.

• Deployment is scope-level. People who join the organisation (or a deployed workspace) later automatically inherit the skill — you never re-deploy for new starters.
• The Email users when I deploy switch (on by default) notifies affected users when you choose Deployed. The notice is titled Skill installed and includes the skill’s name and description — users don’t need to take any action; the skill is immediately discoverable in their next chat.

For a quicker path, the Skills tab also has an admin-only per-row Deploy to all users toggle — switch it on to deploy, off to undeploy. It stays disabled until the skill’s Status toggle is on (tooltip: “Enable Status first to deploy”).

Skills use this single Off → Available → Deployed ladder. Plugins get a more flexible two-axis control — see Plugins below.

Step-by-step: scoping a skill to one workspace

1. Import or create the skill with workspace scope
2. Pick the target workspace in the import dialog
3. Save
4. The skill is visible only to users in that workspace
5. Users in other workspaces won’t see it in their Skills management page or discover it at chat time

Use this for team-specific patterns — e.g. a cyber-incident-response skill that should only be available to your security team.

Step-by-step: importing from the Anthropic official catalogue

Anthropic’s public skills repository (github.com/anthropics/skills) offers ready-made skills — such as pdf, docx, xlsx, and pptx — that you can import via the steps below.

To import skills from public sources:

1. Click Create or Import → Import skill from library
2. Paste a GitHub tree URL (e.g. github.com/anthropics/skills/tree/main/pdf) or a raw SKILL.md URL
3. Pick the Target scope — User (only me), Workspace, or Organization. A Platform (managed catalog) option appears only for platform administrators
4. The security scanner runs automatically. Any block findings fail the import; warn findings require your acknowledgement before proceeding
5. Confirm
6. The skill is now available at the chosen scope

Skill imports accept a GitHub tree URL or a raw SKILL.md URL only. ZIP upload is a plugin feature — to import a ZIP package, use Import Plugin instead.

Security scanner

Every import, regardless of source, runs through a 13-rule security scanner before it’s stored. The scanner has three severity levels:

• Block — rejected immediately. Rules: shell injection in SKILL.md body, allowed-tools: Bash(...) in frontmatter, binary executables, files > 2 MB or aggregate > 8 MB, body > 256 KB
• Warn — requires acknowledgement. Rules: prompt injection phrases, exfiltration URLs to non-allow-listed domains, hidden Unicode / bidi overrides
• Info — logged for context. Rules: Python runtime required (auto-adds pebbleRuntimes: python), Node runtime required (auto-adds node — execution deferred), shell scripts present (reference text only, not executed)

See PebbleChat → Skills → Security scanner for the user-facing detail.

Skills that execute code

Skills declaring pebbleRuntimes: ['python'] need the code execution sandbox to be available in the target workspace. The sandbox runs Python 3.12 in a gVisor-isolated Kubernetes pod with 1 vCPU, 1 GiB RAM, a 120-second wall-clock timeout, and default-deny network egress. Output files (PDFs, images, spreadsheets) are uploaded to the user’s file store automatically.

If the sandbox isn’t enabled in your deployment, Python skills will still import successfully but won’t run. The Runtime availability gate in the discovery pipeline hides them from users whose workspace can’t execute their code. See Code Execution Sandbox for deployment details.

Plugins

Plugins are packages that bundle several capabilities — skills, agents, flows, and tools — so you can import, roll out, and remove them as one unit. A plugin might ship a customer-onboarding skill, the agent that runs it, and the flow it orchestrates, all versioned together.

Importing a plugin

1. Click Create or Import → Import plugin from repository
2. On the Import Plugin page, pick a Source type: GitHub repo or tree URL, Official marketplace entry URL, or Zip file upload
3. Choose the Target scope — your own account, a workspace, or the organisation
4. Click Scan Plugin — the scan preview lists every component in the package (skills, agents, flows) with its security scan result
5. Block-level findings stop the import; warnings require you to tick “I reviewed the warnings and trust this plugin source.”
6. Click Import Plugin

After the import you land straight on the plugin’s detail dialog in the capabilities catalogue, ready to roll it out.

The Plugins tab

Each imported plugin appears as a row on the Plugins tab, showing the plugin name and key, a components chip (how many of its bundled components are supported), the provider, a Status toggle, and actions including Uninstall plugin.

Plugins have full management parity with skills: enable or disable with the Status toggle, deploy and undeploy from the detail dialog, and uninstall when you’re done. Uninstalling a plugin also removes the flows, skills, and agents it brought with it, so deleting and re-importing never leaves duplicates behind.

Rolling out a plugin: Availability vs Deployment

Open a plugin’s detail dialog as an org admin and you get two independent controls — the key difference from the skills ladder:

Because the two axes are independent, you can:

• Deploy quietly — switch a capability on for one team without listing it in anyone else’s picker
• Offer without forcing — list it in the catalogue for self-serve opt-in without turning it on for anyone

Availability saves with Save availability; Deployment saves with Save deployment and has its own Email people when I deploy switch (off by default) that notifies affected users.

One shared copy, inherited by later joiners

Deployment creates one shared copy per scope, not a private copy per person. Deploy a plugin containing a flow to a workspace of forty people and everyone sees one shared flow — not forty clones. Two consequences:

• Later joiners inherit automatically. Anyone who joins a deployed workspace or organisation after the fact receives the same shared capability without you re-deploying.
• Edits fork safely. When a team member who isn’t the owner or an admin saves changes to a shared deployed flow, they’re prompted with “Save as your own copy?” — their edits become a private copy while the shared version stays unchanged for everyone else. Owners and org admins save in place.

What non-admins see

Users without org admin access see Install for Me and Uninstall buttons in the catalogue detail dialog instead of rollout controls — self-serve opt-in for anything you’ve made Available.

Flows

Chatflows and Agentflows that have been promoted to organisation-level capabilities. A flow listed here can be @-mentioned by anyone in the org — it’s not just available within its source workspace.

Agents

Multi-agent definitions from PebbleFlows Agentflow V2. An agent listed here is an organisation-level agent any user can invoke.

Disabling a capability instance

Flip the toggle in the Status column off for any row to temporarily disable a capability without removing it. The integration’s stored OAuth tokens, configuration, and connection state are all preserved — flip it back on when you want to use it again.

When to disable temporarily:

• Provider outage — disable so PebbleChat doesn’t keep retrying broken calls
• Security incident response — disable an integration whose credentials may have leaked while you investigate
• Cost control — disable expensive tools (e.g. paid web search) until budget refresh

Removing a capability instance

Click the delete icon to fully remove. Removal:

• Revokes any stored OAuth tokens
• Clears configuration
• Removes the capability from every user’s available list (forces users to re-authenticate if you re-add it later)

Capabilities and asset discovery

Every capability you provision here is eligible for asset discovery — when a user sends a PebbleChat message, the discovery system can match it against any provisioned capability and pull the relevant ones into context automatically.

For asset discovery to work well:

1. Capability instances need clear descriptions
2. Users need access to the capability (i.e. they’ve completed any per-user OAuth)
3. The capability needs to be marked as discoverable in PebbleFlows (for flows and agents — see Asset Sharing)

See PebbleChat → @Mentions & Tools for the user-side view.

Tips

• Provision integrations early. Users see the integration in their Settings → Capabilities page only after you’ve enabled it here. Get the common ones provisioned before you announce PebbleAI to the team.
• Disable rather than delete when you might come back. Deletion forces every user to re-authenticate, which is a hassle.
• Match scope to actual need. Don’t enable every integration just because you can — each one is a security surface and a thing to keep updated.
• Watch usage in PebbleObserve → Logs to see which capabilities your team actually uses. Cull the unused ones quarterly.

Related

• User Settings → Capabilities — the user-side view; where individual users toggle their own access
• PebbleChat → @Mentions & Tools — how users invoke capabilities from chat
• Asset Sharing — how flow/agent/document store sharing works at asset level
• PebbleFlows Integrations — the catalogue of integrations and their setup details