Skill packs: shipping an outcome, not just a skill

A single skill answers one question: can it do this specific thing well? A pack answers a different one: does this get me all the way through a task I actually have? Those are not the same question, and conflating them is how you end up either publishing a skill that quietly tries to do five jobs, or asking someone to hunt down five separate skills and hope they compose.

What a pack actually is

A pack is a curated bundle of skills aimed at one real-world outcome, not a folder of loosely related tools. Browse /packs and you’ll see two kinds side by side: official packs, assembled and curated directly, and community packs, put together by whoever needed that exact combination and decided to share it. Both show up the same way: a name, a short description of the outcome, an item count, and the list of skills inside.

The distinction between official and community isn’t a quality gate baked into the word “official.” It’s provenance. An official pack is a bet SkillMD is making about a common enough outcome that it’s worth curating directly. A community pack is evidence that someone already needed that combination badly enough to name it and publish it. Both are worth browsing for different reasons: official packs for the outcomes common enough to warrant curation, community packs for the long tail of specific, real workflows nobody centrally planned for.

Why not just write one bigger skill

The instinct to solve this with a single, more capable skill is understandable and usually wrong. Take a “process an incoming invoice” workflow: extract text and tables from a PDF, validate the numbers against a schema, and write a summary row into a spreadheet. You could write one skill that does all three. You’d also be writing a skill that fails in one of three unrelated ways, that can’t be reused if someone only needs the extraction step, and whose description has to somehow signal three different capabilities to search and to an agent deciding whether it’s relevant.

A pack gets you the same end-to-end outcome without collapsing three jobs into one. Each skill inside stays narrow: PDF extraction stays PDF extraction, schema validation stays schema validation, spreadsheet writing stays spreadsheet writing. Each one can be found, installed, and reused independently of the pack. The pack just names the combination and gives it a single, discoverable entry point for the person who wants the whole outcome without assembling it themselves.

This is the same principle behind picking one job per skill, applied at a different altitude. A well-scoped skill composes cleanly with other well-scoped skills. A pack is where that composition becomes visible and nameable, instead of staying implicit in someone’s head every time they reach for the same three skills together.

Building one worth publishing

A pack earns its place when the combination is specific enough to name and common enough that other people will hit the same need. “PDF tools” is not a pack, it’s a category, and it doesn’t tell anyone what outcome they’ll walk away with. “Turn a scanned invoice into a validated spreadsheet row” is a pack: it names the outcome in one sentence, and anyone who reads it knows immediately whether it matches their task.

A few things worth checking before you publish one:

• Name the outcome, not the ingredients. The pack’s description should read like the sentence someone would say out loud when explaining what they needed, not a list of the skills inside.
• Keep every skill in the pack independently useful. If a skill only makes sense bundled and can’t stand on its own, that’s a sign it should be a step inside one of the other skills, not a separate entry.
• Order matters less than completeness. A pack isn’t a pipeline definition, it’s a curated set. Don’t leave out the boring middle step, schema validation in the invoice example, just because it’s less interesting to write than the extraction or the output.
• Don’t pad it. A pack with one relevant skill and three loosely-related ones to make it look substantial is worse than a tight pack of two that actually get used together.

Finding the right one

If you’re the one looking, filtering by category on /packs narrows things fast, and the filter box on that page matches against name, slug, and description together, so searching by the outcome you want, “invoice,” “onboarding,” “changelog,” works as well as searching by category. If nothing existing matches your exact combination, that’s the signal to assemble your own from skills already in the registry and publish it as a community pack. The next person with your exact workflow won’t have to reassemble it from scratch.