The Plugin Pattern: How the K-12 Skills Are Packaged

When you install the open K-12 teaching skills, you don't install two skills. You install one plugin that happens to contain two skills plus a set of teacher-focused third-party MCP servers you can enable. That distinction is easy to skate past, and it's exactly the part builders should slow down and study — because the packaging is as reusable as the skills themselves.

The repo at github.com/anthropics/k12-teacher-skills splits cleanly into two top-level directories: plugin/, which bundles the skills as a Claude Code plugin alongside those MCP servers, and evals/, which holds the evaluation framework and rubrics. This piece is about the first one — how the plugin/ directory turns loose skills into a single installable unit, and why that pattern is the right default for anyone shipping teaching tools of their own.

One install, a whole toolkit

Recall the three commands that put the skills on your machine:

git clone https://github.com/anthropics/k12-teacher-skills
claude plugin marketplace add ./k12-teacher-skills/plugin
claude plugin install k12-teacher-skills@k12-teacher-skills

Look closely at what those middle and last commands are actually manipulating. plugin marketplace add points Claude Code at the plugin/ directory as a marketplace — a catalog of installable plugins. plugin install k12-teacher-skills@k12-teacher-skills then reads "install the k12-teacher-skills plugin from the k12-teacher-skills marketplace." Two names, one on each side of the @: the plugin, and the marketplace it lives in. That's the pattern in miniature — a plugin is a shippable bundle, and a marketplace is how it's discovered and installed.

The payoff for the user is that a single install brings the whole toolkit: k12-lesson-planning, k12-lesson-differentiation, and the MCP servers, all versioned and enabled together. No hunting for individual skill files, no manual wiring. One command, a coherent set.

The three manifests that make it work

A Claude Code plugin is defined by a small number of JSON manifests, and the K-12 repo uses the standard three. Understanding what each declares is most of what you need to build your own:

• marketplace.json — declares the marketplace itself: the catalog that claude plugin marketplace add reads when you point it at the plugin/ directory. It's the front door — the thing that lists which plugins are available to install from this source.
• plugin.json — the plugin manifest. It names the plugin, describes it, and declares what it bundles: the skills it ships and the metadata Claude Code needs to install and run them as one unit. This is the file that makes "two skills" into "one plugin."
• .mcp.json — declares the third-party MCP servers the plugin makes available. These are the teacher-focused connectors a user can enable — Claude Code knows they exist because the plugin ships this manifest, and the user opts in rather than configuring servers by hand.

Three files, three jobs: what marketplace this is, what plugin it offers, and what external tools that plugin can turn on. Get those right and Claude Code handles discovery, install, and enablement for you.

The clever move isn't any single skill — it's that skills, subject references, render scripts, and MCP servers all ship as one versioned, installable unit. Packaging is what turns "some files that work on my machine" into "a tool other people can actually install."

Why bundle MCP servers with the skills

The most instructive design decision is that the plugin carries MCP servers at all. A skill tells Claude how to do a task; an MCP server gives Claude a tool or data source to do it with. The teaching skills were designed to reason over standards, curricula, and classroom tools — so bundling teacher-focused MCP servers alongside them means the skill and the capability it needs travel together.

That's a meaningful convenience. Instead of telling a teacher "install this skill, then separately go configure these four servers," the plugin ships them as enable-able options. The user flips them on when they want them. It keeps the skill's assumptions and the tools that satisfy those assumptions in one place, versioned as a set, which is precisely what you want when a non-technical educator is the one doing the installing.

It's worth being precise about scope, though. Inside Claude for Teachers, the standards grounding comes through the Learning Commons Knowledge Graph connector, and the broader partner ecosystem — ASSISTments, Brisk, Canva Education, Diffit, and the rest — arrives through Anthropic's connector directory. The MCP servers bundled in the open plugin/ are the teacher-focused third-party servers users can enable there. Either way, the lesson is the same: a plugin is the unit that lets you ship capabilities plus instructions together.

The reusable pattern for your own skills

Strip away the K-12 specifics and you're left with a template any skill author can copy. If you're building teaching tools — or any skills meant to be installed by people who won't read your source — this structure is the one to imitate:

Keep your skills as directories with their own references/ and scripts/, the way k12-lesson-planning does. Wrap them in a plugin/ directory with a plugin.json that declares the bundle. Add a marketplace.json so the directory can be added as a marketplace and installed with the same git clone → marketplace add → plugin install flow. If your skills need external tools or data, declare those in .mcp.json so users can enable them rather than configure servers themselves. And keep your evals/ beside the plugin/, not inside it — tests are for builders, not for the install bundle.

The result is a repo a stranger can install in three commands and a repo you can iterate on with confidence, because the manifests pin down exactly what ships. That separation — evaluation on one side, installable package on the other — is a big part of why the K-12 repo reads as production-grade rather than a demo.

Packaging is a feature, not an afterthought

It's tempting to treat packaging as the boring bit you do after the "real" work of writing the skill. The K-12 repo argues the opposite. The reason a teacher without a terminal habit can adopt these skills at all is that packaging did its job: one install, coherent bundle, opt-in tools, versioned together. A brilliant skill that's hard to install reaches no one; a good skill packaged well reaches everyone who runs three commands.

If you're going to build in this space, learn the manifests before you write a line of skill logic — then read the SKILL.md design that fills the bundle with something worth installing. And if you just want to try the K-12 skills first, the install walkthrough has the exact commands. For finished, no-assembly-required tools, marketplace skills like Education Agent Skills and Lesson Plan Studio show what a polished, installable teaching bundle can feel like.

---

Part of the Claude for Teachers series. Related: No CfT Account? Install the K-12 Teacher Skills in Claude Code · Build Your Own Teaching Skill: Lessons from Anthropic's SKILL.md Design. Browse AI tutoring skills or more builder insights.