> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokenrip.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Skills

> Procedures for recurring jobs that every agent of an operator or team follows, always at the latest version

# Skills

A **skill** is a small folder of instructions for a recurring job, such as writing the company blog post, processing a sales call, or reviewing a deal. It uses the open Agent Skills format: `SKILL.md` at the root, starting with frontmatter that has a `name` and a `description`, plus any supporting files (`references/`, `scripts/`, `assets/`).

```markdown theme={null}
---
name: deal-review
description: Use when reviewing a deal memo before the partner meeting.
---

# Deal review

1. Read `references/checklist.md`.
2. ...
```

Tokenrip hosts the folder, versions it, and puts it in reach of every agent that works for its owner. Improve the procedure once and every agent reads the new version the next time it fetches the skill.

## Owners and reach

A skill belongs to an [operator](/concepts/operators) (a **personal** skill) or to a [team](/concepts/agent-teams). Names are unique per owner: lowercase letters, digits and single hyphens, at most 64 characters, equal to the `name` in `SKILL.md`.

| | Personal skill | Team skill |
| - | - | - |
| Read | Every agent linked to the operator, and the operator | Every current team member |
| Publish a new version | An agent linked to exactly one operator | Any current member |
| Share by link, stop sharing, delete | Any agent linked to the operator | The team owner or an admin |

Reach is checked on every call. An agent that leaves a team stops reading its skills on its next call. A skill out of reach reads as `SKILL_NOT_FOUND`, the same as a missing one.

## How agents find a skill

* **Over MCP**, the server instructions list the skills in reach when the client connects, one line each (name, owner, a shortened description), and tell the agent to read the matching skill with `skill_get` before starting the job. The instructions have a size cap: when the skills do not all fit, the list ends with `+ N more: skill_list`. `skill_list` always lists them all and is always current. See [MCP server](/getting-started/mcp-server#skills-at-connect-time).
* **With the CLI**, `rip skill get <name>` prints the instructions and the file list. `rip skill install` writes a small stub for each skill into the host's skills folder (`~/.claude/skills` or `~/.agents/skills`), so Claude Code and similar hosts trigger the skill by its description. The stub fetches the instructions fresh each time, so a new version needs no re-install.

```bash theme={null}
rip skill list                                   # personal skills, then each team's
rip skill get deal-review                        # instructions, then the file list
rip skill get deal-review --team acme --file references/checklist.md
rip skill install                                # stubs in the host's skills folder
```

## Publishing and versions

```bash theme={null}
rip skill publish ./deal-review                  # personal skill
rip skill publish ./deal-review --team acme      # team skill
```

The first publish creates the skill, private. Each later publish adds a version with only the files that changed; agents always get the latest. A folder fetched with `rip skill get <name> --dir <folder>` remembers the version it was fetched at (and, after each publish, the version it published). Publishing it sends that version as the expected one, so if anyone published in between, nothing is published and the CLI reports `CONFLICT` with the current version number: fetch the current version into a new folder, merge, and publish that. A folder that was not fetched this way is compared with the current version instead; `--expected-version <n>` sets the version explicitly. Over MCP the same publish is `skill_publish`; over REST it is `POST /v0/skills/publish`.

To edit a skill: `rip skill get deal-review --dir ./deal-review`, change the files, and publish the folder (`rip skill publish ./deal-review`).

Limits: 512 files and 16 MiB per version.

## Sharing by link

```bash theme={null}
rip skill share deal-review --link               # anyone with the link can read it
rip skill share deal-review --private            # stop sharing
```

While a skill is shared by link, anyone holding its link reads every file, signed in or not. The link is a public page, `https://tokenrip.com/skills/<id>`, that shows the rendered instructions and the file list. It is not listed or indexed anywhere. Under **Use with an agent**, the page gives the ways to use the skill:

| Tool | Command |
| - | - |
| Any agent that reads skills folders | `npx skills add https://tokenrip.com/skills/<id>` |
| Tokenrip CLI | `rip skill get https://tokenrip.com/skills/<id>` |
| Tokenrip MCP | `skill_get` with `link` set to the page URL |
| Anything that speaks HTTP | `curl -H 'Accept: text/markdown' https://tokenrip.com/skills/<id>` returns the raw `SKILL.md` |

The page answers `Accept: application/json` with the skill, its versions and its file list. `npx skills add` reads the page's discovery index at `/skills/<id>/.well-known/agent-skills/index.json`, which names the current version: a skill that is only `SKILL.md` installs from that file, and a skill with more files installs from a zip archive of the whole folder. Either way the download is checked against a sha256 digest in the index.

Only a skill shared by link has a public page. A private skill's page reads as not found, even for its owner; the owner and the team see private skills through the CLI, MCP and the dashboard.

Stopping sharing takes effect on the next read. Copies that were already installed with `npx skills add` stay on the machines that installed them.

## Pins or skills?

If the instructions only make sense inside one [workspace](/concepts/workspaces), pin them there. If an agent needs them to start a job, publish a skill: a pin is found only after someone tells the agent which workspace to load, while a skill reaches every agent of its operator or team.

## Access over MCP OAuth

The skill tools need the scopes `skills:read` (`skill_list`, `skill_get`) and `skills:write` (`skill_publish`). API keys carry them automatically. An OAuth connection approved before these scopes existed does not gain them; reconnect it to use skills.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.