Skip to content
Back to skills

Capabilities

ASecurity

Ask the owner, on a card in chat, to connect a capability the task needs (a connector, an account, Docker, a server, a device), to change a setting on one, or to replace a refused credential, via the `capabilities` CLI. Use whenever a task hits something this sandbox isn't connected to: check what's connectable, then raise the ask instead of describing manual setup steps.

  • 69 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 3, 2026
developmentgodockerawsgitdatabase

Works with

  • cli

Security analysis

A100/100

Scanned October 2, 2026

npx -y skills add intentic/intentic --skill capabilities --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Capabilities?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Capabilities
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/intentic-capabilities/badge)](https://www.skillsdirectory.com/skills/intentic-capabilities)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: capabilities
description: Ask the owner, on a card in chat, to connect a capability the task needs (a connector, an account, Docker, a server, a device), to change a setting on one, or to replace a refused credential, via the `capabilities` CLI. Use whenever a task hits something this sandbox isn't connected to: check what's connectable, then raise the ask instead of describing manual setup steps.
---

# Missing capabilities

The sandbox connects to outside things through capability cards: connectors (GitHub, Notion, Stripe…),
browser accounts, databases, Docker, servers over SSH, the owner's own devices. When a task needs one that
isn't connected, **raise the ask in chat** with the `capabilities` command rather than telling the owner to go
set something up by hand. The card carries the setup: for a server, a CLI or an endpoint the connection's own
form sits inside the card, filled in with everything you passed, so the owner adds only the credential (or,
for SSH, keeps the key the sandbox generates and runs one command on the server).

## Commands

```sh
capabilities list                          # every connectable card, what is connected, and what this
                                           # workspace looks like it wants (read from its files)
capabilities request <card> --why "…"      # ask on a card in the owner's chat
    --target <site|host>                   # the site or host it is for, when the card holds several
    --set key=value                        # settings you know (a host, a user, a region); never a credential
capabilities request <connection> --set key=value --why "…"
                                           # change a setting on a connected one: a device switch, a Docker option
capabilities request <connection> --reconnect --why "…"
                                           # it is connected, but its credential is being refused
```

Every ask answers the same way:

- **exit 0: met.** The capability is live now (or already was, and the sentence says so): use it.
- **exit 1: refused or declined.** Nothing was raised (the sentence says why and what to do instead), or the
  owner said no. Carry on without it and say plainly what it would have enabled.
- **exit 2: no verdict.** Read the error on stdout; correct the command or restore the daemon before retrying.
- **exit 3: still waiting.** The card is up and stays up after your turn ends. Carry on with everything that
  does not need it; when the owner finishes, the sandbox continues this conversation with the answer. Do not
  poll, and do not ask again: `needs` lists what is still waiting, and `needs cancel <id>` withdraws an ask the
  task no longer needs.

The call holds up to 90 seconds for a quick answer (`--wait <0..100>` changes that); a setup that takes the
owner longer (finding a token, signing in) simply answers later, in the conversation.

## How consent works: enforced, not promised

`request` connects nothing. It raises a card in the owner's chat, titled with the catalog's own words, with
your `--why` as the one line that is yours, and everything that happens next is the owner's: their click,
their credential, their setup flow. You never see a credential; the daemon watches for the connection and
answers you. What saving it does beyond storing a credential (a rebuild, a restart, a privileged runtime) is
said on the card before the press.

What that leaves you:

1. **Ask as soon as you know the task needs it**, ideally before you present a plan, so the owner answers
   everything at once instead of being interrupted step by step. Check `capabilities list` first.
2. **Say what you know.** `--target` and `--set` fill the card's form; an owner who only has to paste a token
   finishes in seconds. A credential never goes in `--set`: the card collects it.
3. **"Already connected" is checked against this turn.** A connection your persona leaves out, one for a
   different host, or one whose credential is refused is not "use it": the answer says which, and the next
   step (`grants request capability <id>`, a new connection for that host, `--reconnect`).
4. **One ask per capability.** A decline means continue without it. The daemon refuses a repeat ask for a card
   the owner already declined in this conversation.
5. **Nobody at the keyboard is not a no.** An unattended turn's ask waits in **Needs you** for the owner: finish
   what you can and note what is blocked on it.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.