Import Any Anthropic Agent Skill From a GitHub URL

There's a growing open ecosystem of Anthropic Agent Skills — folders that bundle a SKILL.md with YAML frontmatter, a prompt body, and supporting scripts and templates. People publish them on GitHub. Community marketplaces index them. Someone has already written the skill you were about to write: a PDF toolkit, a spreadsheet wrangler, a slide-deck generator.

The usual catch is that "import" means "read someone's repo, copy the prompt into your system message by hand, recreate their helper scripts in your codebase, and hope you got the file paths right." That's not importing. That's re-implementing with extra steps.

Matrix speaks the Anthropic Agent Skills format natively. Any GitHub repo — or any community marketplace that publishes the same format — is one POST away from being a reusable Skill on your agents. The prompt becomes a prompt block, the bundled files become real files in the agent's sandbox, and the whole thing composes into the agent's tool surface alongside everything else it already has.

One POST, one Skill

Here's the entire import:

curl -X POST https://your-workspace/api/orgs/{slug}/skills/import \
  -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://github.com/anthropics/skills/tree/main/skills/pdf" }'

SkillImporter does the rest. It fetches the SKILL.md, parses the YAML frontmatter, and writes a Skill row plus one SkillFile row per bundled file. There's a UI button for it too — /admin/skills → Import from URL… — but the API is the thing, because it means you can script the import of a whole shelf of community skills.

What gets parsed

The frontmatter maps cleanly onto a Skill:

• name → the skill's key (unique per org).
• description → the skill's description, shown in the picker and used for provenance.
• metadata.version → the skill's version.

The markdown body — everything below the frontmatter — becomes the skill's systemPromptBlock. That's the augmentor that gets concatenated into the system prompt of every agent that adopts the skill. The skill author's instructions become your agent's instructions, verbatim, with no copy-paste.

The skill also records a source of OSS:<url> so you always know where an imported skill came from. Provenance is free.

What gets bundled

Every file in the skill folder other than SKILL.md becomes a SkillFile row, capturing:

• path — the file's path relative to the skill folder
• content — the file body
• binary — whether it's a binary blob
• executable — whether the file is marked executable

SkillImporter walks the rest of the directory via the GitHub Contents API to find these. So a skill that ships a scripts/extract.py and a templates/report.md arrives intact — the prompt and the machinery it references.

Three URL shapes that all work

Skill repos aren't laid out consistently, so the importer accepts three URL shapes:

1. Directory tree — github.com/owner/repo/tree/<ref>/<path>. The importer treats the path as the skill folder, reads SKILL.md, and walks every other file in the directory.
2. Single file — github.com/owner/repo/blob/<ref>/<path>/SKILL.md. Points straight at the manifest; the importer reads it and then walks the parent directory for the bundled files.
3. Any direct .md URL — a one-file skill with no bundled files. Just the prompt block, no scripts.

You don't have to normalize the link you copied out of someone's README. Paste the tree URL, the blob URL, or a raw markdown URL — the importer figures out which one it's holding.

Bundled files become real files in the sandbox

This is the part that makes imported skills do something instead of just say something.

A skill's systemPromptBlock can tell the model "run scripts/extract.py on the uploaded PDF." But that instruction is worthless unless scripts/extract.py actually exists somewhere the agent can run it. In Matrix it does.

Before every agent turn, SkillSandboxMaterializer writes every SkillFile for the agent's attached skills into the agent's sandbox:

/tmp/matrix-sandbox/{orgId}/{agentId}/skills/{skillKey}/<path>

So when the agent calls the built-in bash tool, the skill's scripts and templates are sitting right there — as if the folder had been checked out locally. The materializer runs per turn and is intentionally a cache: the durable copy lives in Neo4j as SkillFile rows, and the sandbox is re-materialized from them each time. (That matters because sandbox storage is ephemeral; the source of truth is the graph.)

If you want the full picture of that sandbox — bash, file_read, file_write, grep, and the per-(org, agent) isolation around them — see the built-in toolbox post. Imported skills lean on exactly those tools to put their bundled files to work.

A Skill is more than a prompt

The Anthropic Agent Skills format gives you the prompt and the files. Matrix's Skill primitive wraps a bit more around them, so an imported skill can compose with the rest of the platform:

• tools — references to Tool entities (HTTP endpoints, MCP methods, or built-ins) that merge into the agent's tool surface when the skill is attached.
• mcpServers — references to external MCP servers, unioned in the same way.
• requiredContactFields — a CSV that folds into the agent's requiredCallerFields, so the agent's "what you still need to learn about the contact" checklist grows when the skill needs more context.
• builtinTools — a CSV selecting which of the memory built-ins to expose (for example, set_contact_birth_place).

When you attach a skill to an agent, all of that gets unioned into the agent's capabilities in one place — AgentToolSurface.composeForCaller, the single composition path that assembles every turn for text chat, real-time voice, and autonomous tasks. No per-skill wiring on the agent end. Attach it; the runtime does the rest.

A Skill is one of the four composable primitives an agent is built from — alongside a single Tool, a Knowledge corpus, and the built-in toolbox. If you haven't seen how those four mix and match, start with composing agents from four primitives; this post is the deep dive on the Skill corner of that picture.

One caveat: the GitHub rate limit

There's a real-world constraint worth knowing before you script a bulk import.

SkillImporter walks bundled files through the GitHub Contents API, unauthenticated. Unauthenticated, GitHub allows 60 requests per hour. For importing one skill at a time — even a skill with a handful of scripts and templates — that's plenty. The full directory walk for a normal skill is a few requests.

It bites when you point the importer at a directory with 50-plus files, or when you try to import a shelf of skills back to back. Each file in the walk is a request, and they add up against that hourly budget fast. If you're doing bulk imports, space them out, or import the heavyweight skills one at a time so a single oversized directory doesn't burn the whole hour.

Why this matters

The Anthropic Agent Skills format is becoming a lingua franca for packaged agent behaviour. A platform that speaks that format gets to inherit the whole ecosystem instead of rebuilding it.

Concretely, this means:

• Reuse, not reimplementation. Someone's published a skill? It's a POST, not a porting project.
• The prompt and the machinery travel together. The body becomes the augmentor; the scripts become files in the sandbox. Nothing is left on the cutting-room floor.
• It composes. An imported skill drops into the same four-primitive model as everything else — it can pull in tools, MCP servers, contact-field requirements, and memory built-ins, all unioned automatically.
• It's portable across your agents. Import once; attach to any number of agents. Each one materializes the bundled files into its own isolated sandbox.

Takeaway: If a behaviour is packaged as a SKILL.md on GitHub, it's already a Matrix Skill — you just haven't run the POST yet. The prompt becomes a prompt block, the files become sandbox files, and the whole thing composes onto any agent in your org.

Build it: spin up a workspace, find a skill you like in the open ecosystem, and POST /api/orgs/{slug}/skills/import { "url": … }. Then attach it to an agent in /admin/skills and watch the skill's scripts show up in the sandbox on the very next turn.