SkillPack: packaging AI skills into local agents your team can reach from Slack
Pack and deploy local AI agents for your team in minutes
At a glance
- What is it?
- SkillPack is a TypeScript CLI and local runtime that bundles agent skills, prompts and persona files into a zip you can hand to a teammate. The trade-off is that every pack still needs its own LLM API key and a machine to run on.
- Who is it for?
- Adopt SkillPack if you already have skills scattered across GitHub repos and want a repeatable way to hand a working agent to a colleague without them rebuilding your prompt setup. Skip it if you need a hosted service with a shared credential vault, or if your team cannot run Node.js 22.19.0 or newer on the machines that will host the agents.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 34 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SkillPack targets: skills that never leave the author's laptop
Most teams accumulate agent skills as loose material. A prompt lives in a Notion page, a script sits in someone's dotfiles, a skill folder is cloned from GitHub and never updated. The README frames this directly: instead of juggling prompts, scripts, docs, and one-off automations, SkillPack packages AI skills into reusable agents that run locally and stay in your own environment. The intended audience is a team rather than a solo tinkerer. The distribution unit is a zip file, and the consumption surface is Slack or Telegram, which means a non-technical colleague can talk to the agent without touching a terminal. The README also states the privacy motivation plainly: agents operate entirely on the machine to keep team data local. That is the whole pitch. If your skills already live in a shared repo with a CI pipeline that runs them, SkillPack is solving a problem you do not have.
What is actually inside the zip
The README documents the archive layout precisely, and it is deliberately small. A pack contains skillpack.json for configuration, an optional job.json for scheduled jobs, optional AGENTS.md and SOUL.md files, an installed skills/ directory, and two launcher scripts. There is no bundled server. The start scripts call npx @cremini/skillpack run ., so the runtime is fetched on demand and Node.js 22.19.0 or newer is the only stated prerequisite. That design choice keeps the archive lightweight but pushes a network dependency onto first launch. The AGENTS.md and SOUL.md handling is the more interesting detail: the README says SkillPack reads them itself when a new chat session starts and injects them into the runtime system prompt as pack-level policy and persona, explicitly without depending on the host machine's AGENTS.md, .pi/SYSTEM.md, or APPEND_SYSTEM.md. That is a deliberate isolation boundary. It means a pack carries its own instructions rather than inheriting whatever the host has configured, which is what you want when you ship an agent to someone else's machine.
Installing, creating and packaging a pack
The create flow is interactive. Running npx @cremini/skillpack create walks through setting a pack name and description, adding skills from GitHub repos, URLs or local paths, adding prompts that tell the agent how to orchestrate those skills, and optionally zipping the result immediately. Skill sources accept three formats per the README: a GitHub shorthand such as vercel-labs/agent-skills --skill frontend-design, a full GitHub URL pointing at a tree path with --skill, or a local path like ./skills/my-local-skill. Multiple skill names from one source can be comma-separated. For repeatable setups you can skip the prompts entirely and pass a config: npx @cremini/skillpack create --config ./skillpack.json for a local file, or npx @cremini/skillpack create comic-explainer --config https://raw.githubusercontent.com/CreminiAI/skillpack/refs/heads/main/examples/comic-explainer.json for a remote one, where omitting the directory name uses the current directory. Packaging is a separate step: npx @cremini/skillpack zip writes <pack-name>.zip into the current directory. The --skip-skill-install flag skips reinstalling skills already present in skills/ and, according to the README, still syncs skill descriptions from the existing SKILL.md files before packaging. That flag is the one to reach for in a loop where skills are already vendored.
Running a pack and wiring it to Slack or Telegram
The end-user path is intentionally dumb. Download a pack zip, unzip it, run ./start.sh on macOS or Linux, or double-click start.bat on Windows. The README states the server starts and opens http://127.0.0.1:26313 in the browser. From there you enter an LLM API key (OpenAI or Claude) in the left menu and try the prompt example. Note what that implies: the API key is entered per machine, in the UI, by whoever runs the pack. There is no mention of a shared secret store, a proxy, or a team-level key management story. For a five-person team that means five keys, or one key passed around. The Slack and Telegram integrations are documented outside the README, in a GitBook, with the README claiming roughly five minutes to obtain a Slack App Token and Bot Token and about one minute for a Telegram Bot Token. Those time estimates are the project's own, not measured. The README does not describe how tokens are stored on disk, which is worth checking before you hand a pack to anyone outside your immediate team.
Where SkillPack is the wrong tool
The binding constraint is Node.js 22.19.0 or newer on the machine that runs the agent. Because the zip ships no server and the start script invokes npx, first launch also needs network access to the npm registry. On a locked-down corporate laptop with an old Node or a restricted registry, the one-click promise breaks. The second constraint is that local means local. If the person who needs the agent is asleep, the agent is offline. There is no documented always-on deployment target, no container image, no serverless path. The README's own framing is machine-scoped. Third, the project is young: there are no retrieved releases, so there is no version history to reason about upgrade paths from. Fourth, the documentation for the runtime internals is thin. The README explains the file layout and the CLI surface but says almost nothing about how skills are executed, what sandboxing exists, or what happens when a skill from a third-party GitHub repo misbehaves. If your threat model includes untrusted skill sources, the README gives you nothing to work with.
How this differs from a hosted agent platform
The obvious alternative is a hosted agent builder, where you define an agent in a web console and the vendor runs it. The difference is not feature depth, it is where the state and the credentials live. A hosted platform keeps the agent running when your laptop is closed and centralises API keys, which is exactly what a team with non-technical users usually wants. SkillPack inverts that: the pack is a file, the runtime is your machine, the key is your key. You get data locality and a distribution artifact you can inspect, diff and archive. You give up availability and central credential management. A second alternative is simply a shared git repo of prompts plus a chat client. That is cheaper and has no new dependency, but it has no packaging step, no persona injection, and no launcher, so every consumer has to reconstruct the environment. SkillPack's contribution is the zip plus the two start scripts plus the system-prompt injection, not the skills themselves.
Licence, maintenance and what to check before rollout
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive position and it is the right fit for a tool meant to be zipped and handed around. It is not legal advice; if you redistribute packs that bundle third-party skills, the licence of each bundled skill is a separate question and the README does not address it. On maintenance, the material shows a push in August 2026 and no retrieved releases, so there is no published changelog to plan upgrades against. The upgrade path is implicit: because the start scripts call npx @cremini/skillpack run ., a new runtime version can arrive without anyone editing the pack, which cuts both ways. You get fixes for free and you also get behaviour changes on a machine you did not touch. If you need version pinning, the README does not document a flag for it. Verify that before you standardise on this for a team.
Editorial conclusion
Adopt SkillPack if you already have skills scattered across GitHub repos and want a repeatable way to hand a working agent to a colleague without them rebuilding your prompt setup. Skip it if you need a hosted service with a shared credential vault, or if your team cannot run Node.js 22.19.0 or newer on the machines that will host the agents. Before committing, verify three things yourself: that the zip produced by npx @cremini/skillpack zip actually starts on a clean machine with only Node installed, that the Slack and Telegram token flows documented in the GitBook work against your workspace, and whether AGENTS.md and SOUL.md injection behaves the way you expect when a pack is loaded next to a host machine that already has its own agent config.
Community notes