Skills and Playbooks

Trinity syncs from one or more GitHub repositories: a bundled public community catalog (github.com/abilityai/trinity-skills, shown as Trinity Community Skills) that is seeded on fresh installs, plus any custom repositories your admin adds.

Manage sources in Settings → Agents → Skills Library. The panel lists sources in resolution order — the first row is marked wins conflicts, the seeded catalog bundled, and each row shows whether it tracks a branch or is pinned to a tag, with the ref. Per source you can Sync, Disable/Enable, or Remove; Sync all pulls every enabled source. + Add a skills repository asks for a Name, a Repository URL (github.com only), what to Track — Branch (follows new commits) or Tag (pinned — a moved tag is refused)— and the branch or tag name. Errors are shown verbatim under the source, so a refused tag names the tag and says what to do.

A private source repository authenticates with the platform GitHub PAT. Trinity offers that token only to github.com and hands it to git with each request, so it is not written into the library's checkout in the platform data directory. A checkout cloned by an earlier release can still hold the token in its remote URL — one more reason to rotate the platform token after upgrading (see Upgrading).

When two sources ship the same skill name, resolution is by priority (lower wins), then by age. Custom sources default to priority 100 and the bundled community source to 1000 — so your own repository always wins a name clash, and a source you add later needs no reordering.

Nothing is overwritten silently. The winning skill carries a shadowed_by marker naming the sources whose copy is unreachable, shown in the library listing, on the source status, and as a warning at injection time. Skill names stay bare (pdf-export, never community/pdf-export), so an agent's /skill-name invocation never changes because a source was added.

Deleting a source does notunassign its skills — they keep resolving through whatever source still provides them.

Two surfaces, two starting points:

Both surfaces write the same per-agent assignment, so there is one skill model whichever way you come at it.

Each skill card on the Library's Skills tab carries an Assigned to N agents line with chips linking straight to that agent's Skills tab — the first four, then +N more. Under it:

The three states of the holder list are kept distinct rather than collapsed into a zero. If the assignment data hasn't loaded yet you see a dash; if it couldn't be read you get an explicit failure with a retry; only a real, successful read reports “no agents yet” (admin) or “none of your agents” (everyone else). You see only what you can access: an admin gets the whole fleet, everyone else gets their own and shared agents.

Below the library listing sits Assigned but no longer in the library — assignments whose skill has since been removed upstream. This matters because revocation works by cutting a new tag withoutthe offending skill, after which a page keyed on the library listing would answer “who still has it?” with silence. The package stays on each agent until it is unassigned — with the × on the chip here, or from that agent's Skills tab.

Each assigned skill's whole package is written to ~/.claude/skills/<name>/, and a Platform Skills section is written into the agent's CLAUDE.md listing what was injected and what is still missing. Injection runs when you assign (running agents), when the agent starts, on a manual Sync now, and — if enabled — as a fleet sweep after a library sync.

Injection is:

On an older agent image that predates package support, a multi-file skill degrades to SKILL.md onlywith an honest warning — the skill still works.

Unassigning a skill — whether you remove one skill or drop names from a bulk save — deletes the injected package from the agent, using the same manifest the injection recorded. Only paths a previous injection wrote are removed; directories left empty are cleaned up; anything else in the directory survives. The skill's .gitignore line is stripped too.

The unassignment itself always succeeds. If the agent is stopped, busy, or unreachable, removal is reported as deferred rather than failing the unassign — and the agent reconciles on next start, removing any platform-managed skill that is no longer assigned.

A reconcile that would remove an unusually large number of skills from one agent refuses wholesale and raises an operator alert instead, so a database problem cannot silently strip a fleet.

Both settings default OFF — a zero-config installation behaves exactly as it always did. Configure them in Settings → Agents → Skills Library → Automation:

Key properties:

Sync failures are never silent, and a sync contended by another worker reports busy rather than claiming failure.

A skill's SKILL.md frontmatter can declare:

At injection, Trinity runs a declaration-only dependency check and produces per-skill warnings (a missing binary, a missing environment variable) instead of failing. Declared package installs are surfaced but not performed. Environment checks report variable namesonly — values are never read.

A skill whose frontmatter fails to parse gets a named warning and a description falling back to its first paragraph. It is never silently dropped.

Inside the agent, the Playbooks tab, the / popup, and the chat empty state read each frontmatter field on its own. A field the agent cannot use — a list or mapping where text belongs, or an allowed-tools value that is a bare yes, a number, or has unbalanced parentheses — is dropped by itself, and the agent log warns once, naming the file and field. The skill keeps its description and every other field. Agents on an older base image instead lost the whole record over one such field, most often a comma-separated allowed-tools, and showed “No description available”. The fix ships in the agent base image, so an existing agent picks it up after the base image is rebuilt (or re-pulled) and the agent is started cold — see Upgrading → Base Image Upgrade.

Two MCP tools let an agent run a permitted self-contained skill without assigning it:

The runner uses a separate workspace — it cannot see the calling agent's files. Use it for self-contained skills (call an API, generate an artifact from the inputyou pass). A skill that must operate on the caller's own files goes through assignment and injection instead.

The Skill Runner is an entitled surface. In a community build, run_skill and list_runnable_skillsreturn a “disabled” result.

MCP tools for skills and playbooks:

REST endpoints — see Backend API Docs for full schemas.

Source management is REST-only and human-only— there is no MCP tool for it, and agent-scoped keys are rejected. Registering or syncing a source decides which repository your fleet executes code from, so it is an operator action regardless of the caller's role.