Prompt files are dependencies. Why aren't we versioning them?

Divya kumar BAID — Wed, 28 Oct 2026 19:36:11 +0000

If you use Claude Code, Cursor, or any agent that reads Markdown instructions, you probably have a folder of "skills": a deploy checklist, a code-review playbook, a set of rules someone shared on X.

Look at where they came from. One is a gist, one was copied out of a GitHub repo three months ago, and one was pasted from Discord. You don't know which version you have, whether the author has fixed anything since, or what changed if you pull it again.

We solved this for code decades ago with package managers. Prompt files change what your agent does just as much as a library changes what your program does, yet we still manage them by copy-paste.

So I built Amitte, an open registry for agent skills, agents and MCP servers. Here's what it does, the design decisions behind it, and what's still missing.

1. Versions are immutable

You publish a skill as publisher/name@version, and once a version is published it never changes. Each one is content-hashed (SHA-256), so a given @1.2.0 always refers to the same bytes. To change anything, you publish a new version.

npm i -g @amitte-ai/cli

skills init acme/deploy-checklist
$EDITOR skill.md
skills eval        # sanity-check the skill before publishing
skills login       # GitHub login; you always publish as yourself
skills publish

Installing for Claude Code writes a proper .claude/skills/<name>/SKILL.md:

skills install acme/deploy-checklist@1.2.0 --claude

2. Bundles: pin the whole set, not each file

This part came from a real user. A maintainer of a multi-skill project told me that versioning each skill separately wasn't enough. Their skills are designed to work together, and users ended up with mismatched combinations: skill A at v3 with skill B at v1, which was never tested and breaks in strange ways.

What they wanted was the guarantee a lockfile gives you: a known-good snapshot of the whole set that you can roll back to.

So a bundle release is an immutable record that pins exact versions of every member skill, plus the upstream git commit it was cut from. The maintainer adds an amitte-bundle.json to their repo and runs:

skills release     # refuses a dirty tree, records git HEAD,
                   # publishes missing member versions, cuts the release

Users install the whole set at once:

skills install acme/toolkit --claude         # latest release
skills install acme/toolkit@1.0.0 --claude   # exact snapshot (also how you roll back)
skills bundle status --check                 # what's installed, from which commit, is there a newer release?

Installs are recorded in amitte.lock.json. Installing a different release replaces the set as a unit and removes members the new release doesn't include, so you never end up with a mix of two releases.

When someone files a bug, skills bundle status --json tells the maintainer exactly which release and commit they're on.

3. Knowing who published it

Anyone can claim the name "acme". So publishers can prove they own a domain, and verified publishers get a badge on everything they publish. It's the same idea as verified domains on npm or GitHub organisations: it doesn't make the content good, but it tells you who stands behind it.

4. Agents can search the registry themselves

Search is semantic (Postgres + pgvector embeddings), so "something to help me ship an iOS app" finds the App Store submission checklist even though the words don't match.

There's also an MCP server, so an agent can do the lookup itself: amitte_search to find skills, amitte_fetch to pull one, and amitte_compose to combine several for a task. Instead of you pasting a playbook into the context, the agent finds the right one when it needs it.

The stack

Registry: Hono + Drizzle on Postgres/pgvector
Site: Next.js 15
CLI: TypeScript (@amitte-ai/cli)
Guide: a small RAG assistant called Folio lives in the corner of the site. It answers "where do I…?" questions and points at the right element on the page. It runs on a cheap open model with hybrid BM25 + embedding retrieval over a hand-written knowledge base.

It's Apache-2.0.

What's not done yet

Cryptographic signing. Today integrity relies on content hashes and immutability. Sigstore-based signing, so you can check who produced a version and not just that it hasn't changed, is the next big item.
More content. A registry is only as useful as what's in it, and it's early.
Rough edges across the site. I'm one person.

I'd love your take

Do you actually hit the "which version of this prompt do I have?" problem, or is copy-paste fine for you?
If you maintain a set of skills or rules, what would get you to publish them to a registry instead of only keeping them in a repo?

If you have a skill you use every day, try publishing it. I'll personally help anyone who hits a snag. Comments are open below, or find me at https://amitte.com.

DEV Community: Divya kumar BAID