Install and manage skills

This guide shows you how to fill a workspace with skills from GitHub: add a repository as a source, install the skills you want from it, and keep them current over time. You can also evaluate a saved revision against a matched baseline before deciding whether to keep it.

The important thing to know before you start: a source repository is untrusted. Its name, description and star count are written by whoever owns it. Every install passes through the antivirus scan gate before anything reaches disk or an agent prompt. That verdict is an admission check, not proof that a skill is safe or useful. Read the agent model’s skills section for the installation model and Evals and quality for how behavioral evidence differs from a scan.

Skills live at Settings → Workspace → Skills (/workspaces/<id>/settings/workspace/skills). They are workspace-scoped: the skills you install here belong to this workspace only. The page has two tabs: Installed (local skills, including a New skill editor) and Sources (GitHub catalogs). Both writes pass the same scan gate.

Add a skill repository

Open Settings → Workspace → Skills and switch to the Sources tab.
Press Add repository.
Paste a GitHub repository URL, e.g. https://github.com/anthropics/skills, and confirm.

The server checks that the repository exists and is visible with its credentials, then adds it to the left rail. There is no curated store in the middle: any GitHub repository works, which also means reputation is yours to judge — a star count is evidence, never a guarantee.

A repository’s skills are the directories that contain a SKILL.md (up to three levels deep, plus the Claude plugin-marketplace layout plugins/<plugin>/skills/<skill>, with dependency and vendor trees skipped). If the grid later says the repository has no skills, that is what it means: no directory in it matches the skill convention.

Inspect a skill before installing

Select a repository in the rail; its skills appear as a grid on the right, with a filter field above it that narrows the catalog by name, description or slug. Click a card to open the detail view. It shows three things:

The README, rendered as markdown — the skill directory’s README.md, or the SKILL.md body when there is no README.
The scan preview — the verdict (pass, warn or quarantine), the capabilities the skill’s content declares (runs shell, writes files, network access…) and every finding the scanner recorded.
The file count — an install writes the skill’s whole directory, not just its SKILL.md.

The preview scans the exact bytes an install would write, so the verdict you see is the verdict the install gets; nothing is re-judged behind your back.

Install a skill

Open the skill’s detail view.
Read the scan verdict. For a warn or pass verdict, press Install.
For a quarantine verdict, install stays disabled until you tick I understand the risk — install anyway. That override is recorded, not assumed.

The install writes the skill’s directory into the workspace, records a pin in skills-lock.json (source repository, path, the commit it came from and a content hash), and the skill becomes available to agents in the workspace. A card marked Name in use means a different skill already owns that name locally — uninstall that one first.

Update skills over time

Cards for installed skills carry badges: Installed, or Update available when the repository has moved past the commit you pinned. Open the detail view and press Update to re-fetch at the new commit. An update passes through the same scan gate as an install — a skill whose new version quarantines is refused and the version you had stays put. The old version’s hash is kept as a rollback reference in the lock.

Evaluate a skill

Open Settings → Workspace → Skills, select the installed skill and save any edits. In Skill evaluation, check the package hash.
Select Start evaluation. Choose a Task corpus matching the skill’s purpose and an Adapter. The built-in harness uses a configured provider and tool-capable model. Claude Code uses the default managed Claude account and a concrete model identifier; sign in under Settings → Adapters first. It does not borrow the server operator’s personal login.
Choose a Comparison from the table below.
Set Repeats per task (1–20) and Budget (US cents). For example, 100 means US$1. Select Start evaluation to authorize paid provider work.
Follow the campaign in Observability → Quality, or return through Open Quality in the skill panel.

For Claude Code and Codex OAuth subscriptions, the budget is an API-equivalent usage stopping threshold, not an invoice limit or a measure of subscription quota. 100 admits a US$1 threshold: an in-flight call may exceed it, but no further calls start once reported usage reaches it. Unknown usage also stops further calls. A small budget can leave the comparison partial; it does not promise completion of the selected corpus.

API-key providers retain conservative per-call reservations from documented token limits and pricing. They can reject 100 before spending when one safely reserved call needs more. The error identifies the selected model and minimum reservation; choose a lower-cost model or increase that budget.

Comparison	Use it to answer
Absent vs available	Does normal discovery and use of this skill improve the result compared with not having it?
Previous vs current	Does the update preserve or improve behavior against a previously captured revision?
Forced load vs absent	Can the content help when loaded explicitly? This diagnoses loading problems; it does not demonstrate normal discovery.
Composition	Does adding the candidate help or conflict with the selected ambient skills? The baseline keeps that same ambient inventory without the candidate.

Previous vs current needs a package hash from campaign history. Evaluate a revision before replacing it if you want to use it as a baseline; arbitrary Git history is not imported.

Unsaved edits, an unavailable hash and read-only demo mode disable launch. The server also checks workspace/repository access, scan quarantine, action policy, model support, pricing and execution containment. Resolve a failed check rather than bypassing it. Provider/model identity is recorded, but a remote model alias does not freeze the provider’s underlying weights.

Inspect, cancel and export

Read coverage and spend alongside per-task outcomes and regressions. Open individual attempts to inspect observed skill loads, tool events, errors and verifier evidence. Partial, stale and inconclusive results are not recommendations to adopt a revision. A report’s hash identifies the captured package, not necessarily the package currently installed.

Use Cancel run for queued or active work. Completed attempts remain visible; cancellation does not refund provider work already performed. Copy redacted JSON copies a bounded evidence export to the clipboard, not a complete private-source replay bundle. See Evals and quality for evidence and platform limits.

Reevaluate after updates

Automatic paid reevaluation is off by default. After evaluating the current revision, choose a campaign under Update policy configuration and select Enable update evaluations. Changing this policy requires workspace administrator permission. The selected campaign supplies the corpus, adapter, provider/model, comparison, repetitions and budget.

Subsequent admitted content changes schedule budgeted work; unchanged hashes are deduplicated. Disable update evaluations prevents future automatic admissions. Use Cancel run for an already admitted campaign. Historical reports stay attached to their original package hashes; reevaluation does not publish, enable or rewrite a skill.

Uninstall a skill, remove a repository

Uninstall (on an installed skill’s detail view, or delete in the Installed tab) removes the skill’s directory and its lock pin together — an uninstalled skill leaves nothing behind.

Removing a repository from the rail removes only the catalog: skills you installed from it stay installed and still update, because a pin records the repository by name rather than by reference to the source entry. Add the repository back if you want to browse it again.

Invoke a skill

Skills are invoked under their own namespace, so they never collide with built-in slash commands (/plan, /goal, /loop, /compact):

/skill:<name> — a skill installed in this workspace, or attached to the agent
/skill:<repo>:<name> — a skill shipped by a repo checked out in this space

A bare non-builtin name still resolves, for messages written before the namespace existed. /skill:plan is what reaches a skill named plan; /plan is always the builtin.

Repo-scoped skills

A checked-out repo can ship skills of its own, in .agents/skills/, .agent/skills/, .claude/skills/, .opencode/skills/ or skills/. Those are not installed through this page. An agent carries only the skills of the repo it is currently working in; they swap when it moves. The composer is not scoped that way: /skill:<repo>:<name> reaches any repo in the space.

Repo skills pass the same fail-closed scan (pass / warn / quarantine) before their frontmatter reaches a prompt. warn is admitted; quarantine is withheld, with no operator override on that path.

See Repo-scoped skills and Slash commands.