SKILL MARKETPLACE. ONE CATALOGUE, NOT THIRTY FORKS.
Curated library for your organisation's AI knowledge. See which engineers use which skill, stop thirty Claude Code installs drifting, and publish without reviewing every commit.
The Canonical Catalogue
A CTO with thirty engineers on Claude Code usually has thirty slightly different skill folders. The senior engineer's private review checklist lives in one fork, the SRE's deploy runbook in another, and the new hire starts from an empty directory because nobody can point them at the canonical version. The question "which skills do my people actually use?" has no answer because the skills are not in one place.
systemprompt.io stores every published skill as a single row in the database, not as a file scattered across laptops. Each skill record carries a stable identifier, its markdown instructions, an enabled flag, a tag set, and a source pointer, so the same skill referenced from a plugin bundle, a git export, and the HTTP API is provably the same content. A query against the skill catalogue answers "who has which skill installed" from one place, which is the audit artefact a CTO takes into a governance review.
Department-scoped catalogues filter the same library by team. Engineering sees engineering skills, design sees design skills, and finance never sees either. A new hire on the engineering team lands on day one with the same curated set the rest of the team is on, pulled from the marketplace rather than copy-pasted from a Slack thread. The build-vs-buy answer for a CTO is one catalogue per department instead of a shared drive nobody owns.
- Searchable Library, Not Thirty Laptops — Every skill lives in one catalogue with a stable identifier, markdown instructions, and tags. A CTO can answer 'which skills does my org use' from one query, not by grep-ing thirty developer laptops.
- Department Catalogues Cut the Surface Area — Engineering, design, and finance each see a filtered catalogue. A finance analyst never accidentally installs a deploy-to-production skill, because the skill is absent from their view, not hidden behind a 403.
- Day-One Onboarding That Isn't A Slack Hunt — A new hire installs the team's curated skill set on their first day, pulled from the marketplace. The tribal knowledge that lived in one senior engineer's head now lives in a versioned library the team owns.
Browser-Native Authoring
If publishing a skill requires a clean working tree and a Rust build, only the engineers who already maintain the skills fork ever publish. The marketing ops lead who knows the brand-voice rules better than anyone ships nothing, because there is no path from their knowledge into the shared library that does not route through engineering review. The knowledge stays trapped, and the library never reflects what the org actually knows.
systemprompt.io separates the skill's content from its config. The on-disk shape carries an id, a name, a description, an enabled flag, tags, and a pointer to a markdown file, while the instructions themselves are markdown that renders cleanly in a browser editor. A non-engineer can write a skill, preview it against a sample prompt, and publish it without touching YAML, without opening an IDE, and without waiting on a code review queue.
A CTO reviewing every skill commit does not scale past ten contributors. Admins control which skills are enabled and visible in the marketplace, so contribution is open but distribution is governed. A new skill becomes a row in the catalogue with an enabled flag the admin toggles, which is the governance hook the CTO actually needs, not pre-commit gatekeeping on every edit.
- Markdown Instructions, Not YAML — The skill's instructions are markdown, separated from its config. A non-engineer writes the skill in a browser editor and publishes without touching YAML or opening an IDE.
- Preview Before The Whole Team Inherits It — The editor previews the skill against a sample prompt before the admin flips the enabled flag. A misfire is caught at draft time, not after thirty engineers have already installed the broken version.
- Contribute Open, Distribute Governed — Anyone with write access can draft a skill. Only admins flip the enabled flag that publishes it to the marketplace, so a CTO reviews the on/off decision, not every markdown edit.
Atomic Plugin Bundles
An engineer who gets halfway through installing a capability and then loses access to the MCP server but keeps the skill that calls it is in a worse state than before they installed anything. The skill expects a tool that now 403s. Permissions drift like this quietly, a bundle half-installed, half-revoked, and nobody sure which components the user actually holds. An auditor asking "what does this user have" gets five different answers from five different subsystems.
systemprompt.io groups skills, agents, MCP servers, hooks, and scripts into a single plugin record with one version string, one author, and one validated id. The plugin config treats its component references as one validated unit, so an approval writes the whole bundle, a revocation removes the whole bundle, and a half-installed state is not representable by the model.
Plugin variables marked as secret at definition time are scoped at the plugin boundary, so a revoked plugin drops its credentials along with its tools. A CTO's governance question "what does this user hold right now, after last week's offboarding pass" collapses to a single query against the plugin catalogue, joined to the user. One record, one answer, not a join across agents, skills, MCP servers, and hooks.
- One Bundle, One Approval, One Revocation — Skills, agents, MCP servers, hooks, and scripts are one plugin record with one version. Approving the plugin grants the whole capability set. Revoking it removes the set. A half-installed plugin is not a state the model allows.
- Secrets Scoped At The Plugin Boundary — Plugin variables marked secret at definition time are released when the plugin is revoked. An offboarded user does not keep a credential behind because the skill that called it survived the cleanup.
- One Query Answers Who Holds What — A CTO's entitlement review runs against the plugin catalogue joined to the user, not across five subsystems. The audit row names the bundle, the version, and the author, so an auditor can reconstruct the capability surface on any date.
Content-Addressed History
A shipped skill that introduces a prompt regression at 5pm on a Friday, without history, costs the team a weekend. Someone has to reconstruct the previous version from Slack screenshots and local editor buffers. The rollback is not one click, because there is no previous version on record. Every edit overwrites the prior state and the only artefact of change is a git blame on the markdown file, which nobody updates.
systemprompt.io stores a content record per piece of managed text with a version hash, an updated timestamp, a source pointer, and a body. A skill edit writes a new content row rather than overwriting the previous one, so the previous version is a select query away. A rollback is "set the enabled flag on version N, clear the flag on version N+1", which a CTO can do from the admin UI without a redeploy.
For a team that wants to try an edit without forcing it on everyone, the same version hash makes non-destructive forking cheap. A fork is a new content row with a new id and a pointer back to the original, the organisation baseline keeps receiving upstream updates, and the forked skill can merge or reject them. Experimentation is a new row, not a git branch nobody rebases.
- Every Edit Is A New Row — A skill edit writes a new content record with a version hash and a timestamp. Rolling back is flipping the enabled flag on the previous row. The previous version is never overwritten.
- Team Workspaces With Admin-Published Skills — Admins publish official skills by toggling the enabled flag. Team members create personal skills without affecting the organisation baseline, so a contributor can draft without the admin reviewing every keystroke.
- Forks That Track Upstream — A fork is a new content row with a pointer back to the original. The organisation baseline keeps receiving edits, and the fork can merge or reject them. Experimentation costs one row, not a git branch.
Single-Source Distribution
If the marketplace publishes skills to one channel, exactly one workflow benefits. An engineer who wants the skills in their CI pipeline cannot get them, a script that needs to pull the current catalogue cannot hit an endpoint, and a Claude Code user cannot install through the native plugin format. The library ends up duplicated across three places, each stale in its own way, and a "which version is live?" question has three answers.
systemprompt.io runs one ingestion service that publishes the same skill record to every channel. The service takes a skill config, validates it, and writes a single row into the catalogue. The downstream channels (git repository export, JSON over HTTP, Claude Code plugin format) all render from the same row. A skill updated through the browser editor shows up in all three channels on the next ingestion pass, without a second publish step.
Override semantics handle the update case without silently clobbering a fork. The ingestion call carries an explicit override flag, false creates only new skills and true also updates existing ones. A CTO running a bulk import can dry-run first, see which rows would be created and which would be updated, and decide which edits propagate. The ingestion report names every file and every error, so a failed import is a diffable artefact, not a wall of log output.
- One Row, Three Channels — Git repository, JSON over HTTP, and Claude Code native plugin format all render from the same skill record. A browser edit propagates to all three on the next ingestion pass, so the library stays in sync without a second publish.
- Dry-Run Before A Bulk Import — The ingestion service returns a report listing which skills would be created and which would be updated before anything lands. A CTO running a quarterly catalogue sync sees the delta first, then decides whether to apply it.
- Override Explicit, Not Implicit — The override flag is explicit on the ingestion call. A false value creates only new skills. A true value also updates existing ones. A drift into a team's custom skill does not happen by accident.
Founder-led. Self-service first.
No sales team. No demo theatre. The template is free to evaluate — if it solves your problem, we talk.
Who we are
One founder, one binary, full IP ownership. Every line of Rust, every governance rule, every MCP integration — written in-house. Two years of building AI governance infrastructure from first principles. No venture capital dictating roadmap. No advisory board approving features.
How to engage
Evaluate
Clone the template from GitHub. Run it locally with Docker or compile from source. Full governance pipeline.
Talk
Once you have seen the governance pipeline running, book a meeting to discuss your specific requirements — technical implementation, enterprise licensing, or custom integrations.
Deploy
The binary and extension code run on your infrastructure. Perpetual licence, source-available under BSL-1.1, with support and update agreements tailored to your compliance requirements.