Skills and Playbooks

Trinity syncs from one or more GitHub repositories: a bundled public community catalog that ships pre-configured on fresh installs, plus any custom repositories your admin adds.

Manage sources in Settings → Agents → Skills Library sources. Each source has a name, a repository URL (github.com only), a ref (branch or tag), an enabled flag, and a priority.

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, deliberately different jobs:

On the Skills tab you see two lists: Assigned to this agent (with each skill's version short-SHA, description, and the outcome of the last sync) and Library (everything available). Select, save, and — if the agent is running — click Sync now to copy the packages in immediately. If the agent is stopped, assignment still saves; the files arrive on next start.

Per-skill outcomes are shown honestly. A skill that landed but is missing a declared binary or environment variable is flagged with a warning, not reported as a clean success.

The Library's Skills tab answers the fleet-wide question the per-agent tab cannot: which agents already have this skill? Each skill card carries an Assigned to N agents line with chips linking straight to /agents/{name}?tab=skills. The list is bounded — the first four agents, then +N more— so a widely-assigned skill doesn't swamp the card.

The three states 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”. You also see only what you can access: an admin gets the whole fleet, everyone else gets their own and shared agents, and the empty wording says which.

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 from that agent's own Skills tab.

The Library gained a read, not a second write path: assignment is still a per-agent action.

When an agent starts, 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 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.

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.