PromptHub: a local-first workbench for prompts, SKILL.md files and agent assets

The problem PromptHub targets: the same prompt living in five tools

If you use more than one AI coding tool, you already have this problem. A prompt that works in Claude Code is pasted again into Cursor. A SKILL.md file that you refined in one project gets copied by hand into another. There is no single place that knows which version is current, and no way to push a corrected skill to every tool at once. PromptHub's stated scope is exactly that: put prompts, SKILL.md files and project-level AI coding assets into one local workspace, then install the same skill into Claude Code, Cursor, Codex, Windsurf, Antigravity, Cline and, per the README, a dozen or so other tools with one click. The audience is narrow and identifiable. It is not for someone who writes the occasional prompt in a chat window. It is for engineers who treat prompts and skills as versioned artifacts, who work across several agent tools, and who want the source of truth to sit on their own disk rather than in someone else's account. The README's first line after the tagline is blunt about that: data lives on your computer by default.

What the architecture implies: Electron shell, SQLite store, WebDAV and a self-hosted web target

The badge row names the stack: TypeScript, Electron, React, TailwindCSS, SQLite. That combination tells you most of what you need about the shape of the thing. It is a desktop application, not a service, and SQLite means the local workspace is a file on disk you can copy, inspect or delete. The README describes three separate movement paths for that data, and they are worth keeping distinct. One-click skill distribution writes a skill into the config directory of each target tool. WebDAV sync moves the workspace to your other devices. A full snapshot backup goes to a self-hosted web instance, which is why the repository ships a self-hosted web section alongside the desktop download. Prompt versioning and multi-model testing sit on top of the same store. The README does not describe the SQLite schema, the sync conflict resolution rules, or how a skill install is rolled back if the target tool's directory layout changes between versions. Those are the parts I would want documented before trusting the tool with a library I care about, and the supplied material does not cover them.

Getting it running: desktop binary first, source build second

The fastest path is the desktop release. The README points at GitHub Releases for the current stable v0.5.9 and offers a direct download link that resolves to the latest stable asset, with a note that the link falls back to a fixed CDN filename once mirror sync completes. macOS, Windows and Linux are all listed in the platform badges. If you would rather build it, the repository has a section titled 从源码运行 (running from source) and a 仓库结构 (repository structure) section, which is where the actual build commands live; the cleaned README I have does not include their contents, so I cannot quote the exact npm or pnpm invocation here. The CLI is a separate surface: the README has a 命令行 CLI section, which means PromptHub is not purely a GUI. Configuration keys are also not enumerated in the material I have. What is confirmed is that model providers are configured through an OpenAI-compatible interface, since the README states that a sponsor's API is compatible with the OpenAI standard interface and can be used to complete provider and model configuration inside PromptHub. Treat the provider setup as an OpenAI-compatible base URL plus key until you read the CLI section in full.

The beta gap: 0.6.0-beta.2 is ahead of the advertised stable release

This is the detail that should shape your adoption decision. The README badge says v0.5.9 stable, and the install section repeats it: the latest stable version v0.5.9 has been released. But the release list shows v0.6.0-beta.1 in mid-August and v0.6.0-beta.2 in early September, with v0.5.9 sitting in July. So the project is actively moving on a 0.6 line that has not been promoted to stable. That is normal for a young tool, but it has a practical consequence: any feature described in the README might have landed in 0.6.0-beta and not be present in the 0.5.9 binary you download from the stable link. If you install stable and a documented capability is missing, the README is not wrong, you are just on the wrong track. The mitigation is to read the release notes for the specific beta before installing it, which the README itself points at when it notes that GitHub Releases carries historical versions, signatures and full release notes. There is no separate LTS branch described in the material, and no stated support window for older versions.

Where PromptHub is the wrong tool

Three cases where I would not reach for it. First, team collaboration with access control. The design is local-first with WebDAV sync and self-hosted snapshot backup. That is a personal or small-group model. Nothing in the README describes roles, permissions, review flows or an audit trail, and a snapshot backup is not a collaborative editing system. If your requirement is that five people edit one shared prompt library with approvals, this is the wrong shape. Second, tooling that must be scripted inside CI. The CLI exists, but the README treats it as one surface among several and the material gives no exit codes, no non-interactive flags and no headless guarantee. Third, anyone who needs a signed, stable release with a support commitment. The current newest line is a beta, and the stable line is a version behind it. That is a reasonable state for an actively developed project, and an unreasonable state for a dependency you cannot upgrade on someone else's schedule. There is also an unresolved question about what happens when a target tool changes its skill directory layout. PromptHub distributes into a dozen tools by writing files into their expected locations; each of those tools controls its own layout. The README does not say how PromptHub handles that drift.

How it differs from a plain git repository of prompts

The obvious alternative is a git repo containing your prompts and SKILL.md files, plus a shell script that copies them into each tool's directory. That approach is boring and it works. The difference is what PromptHub adds on top. A git repo gives you version history for the text; it does not give you a multi-model test surface, which PromptHub does through its OpenAI-compatible provider configuration, so you can run the same prompt against different models and compare. A git repo does not give you a one-click install into Cursor, Windsurf, Antigravity and Cline; your script has to know each tool's path and keep knowing it. A git repo does not give you a desktop UI for browsing a prompt library, and it does not give you WebDAV sync to a phone or a second machine without you setting up a remote. Where git wins is transparency and durability: plain files, any editor, no Electron runtime, no SQLite database whose schema you have not seen. PromptHub's bet is that the convenience of one-click distribution and in-app model testing is worth the extra machinery. That bet is reasonable for someone juggling six agent tools. It is a poor bet for someone who uses one tool and is comfortable with a Makefile.

Licence and maintenance cost under AGPL-3.0

PromptHub is AGPL-3.0. For an individual running the desktop app, that is unremarkable. For a company, the network clause is the part to read carefully: if you modify PromptHub and let users interact with it over a network, the AGPL's source-disclosure obligation can attach to your modified version. The self-hosted web mode described in the README is exactly the kind of deployment that clause was written for, so a team planning to run a modified self-hosted instance internally should get its own legal read rather than assume the desktop-app intuition carries over. I am not giving legal advice here; I am flagging that the self-hosted web path and the AGPL are not independent facts. On maintenance: the release cadence visible in the material is roughly monthly on the stable line with betas in between, and the last push to the default branch is dated the same week as the 0.6.0-beta.2 release. That is an actively maintained project, not an abandoned one. The cost you carry is upgrade churn across a beta boundary and the need to re-verify that your target tools' skill directories still match what PromptHub writes. Budget for reading release notes before each upgrade, because the README and the stable binary can disagree during a beta cycle.

Editorial conclusion

PromptHub fits engineers who already keep SKILL.md files and prompt libraries scattered across Claude Code, Cursor and Codex and want one local store with version history and WebDAV sync. It does not fit anyone who needs a stable, signed, long-term-supported tool today: the newest line is 0.6.0-beta.2 while the README still advertises v0.5.9 stable. Before adopting, check the AGPL-3.0 implications for your distribution model, confirm which providers you can register against the OpenAI-compatible endpoint, and read the release notes for the beta you intend to install.

Official sources

1. legeling/PromptHub on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases