Publishing
Ship an extension to npm so anyone can `godmode ext install <slug>`.
A godmode extension becomes installable when it's published as an npm package with a manifest.yaml exposed via the package's exports map. No central registry — npm IS the registry.
Package layout
my-extension/
├── package.json
├── manifest.yaml
├── README.md
└── LICENSEThat's the whole thing. No build step, no JS, no TypeScript — unless you're shipping a package-based extension with its own MCP server implementation.
package.json shape
{
"name": "@yourscope/godmode-stripe",
"version": "0.1.0",
"description": "Stripe API as a godmode extension",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/yourscope/godmode-stripe"
},
"exports": {
"./manifest": "./manifest.yaml"
},
"files": [
"manifest.yaml",
"README.md",
"LICENSE"
],
"keywords": ["godmode", "godmode-extension", "stripe"]
}Three things godmode looks at:
| Field | Why |
|---|---|
exports."./manifest" | How godmode ext install finds the manifest. Required. |
files | What npm packs into the tarball. Keep it minimal — no node_modules, no source code, no build artifacts. |
keywords: ["godmode-extension"] | How extension catalogs/search tools discover your package. Recommended. |
Publish
npm publish --access=public # for scoped packages on the public registryThat's it. Test the install path immediately:
godmode ext install @yourscope/godmode-stripe
godmode stripe --helpSlug resolution
When users run godmode ext install <name>, the resolution order is:
- Local folder path (starts with
.or/) → readsmanifest.yamlfrom disk. - Scoped npm package (
@scope/name) → installs as-is. - Bare slug (
stripe) → resolves to@godmode-cli/stripe.
So godmode ext install stripe only finds your extension if you publish under the reserved @godmode-cli namespace (first-party). For everyone else, use a scope.
Versioning
Extensions follow semver. Bump rules we recommend:
| Change | Bump |
|---|---|
Pointed spec: at a new upstream URL | major |
| New manifest field used | minor (older godmode CLIs will warn) |
| Description tweak, README update, no behavior change | patch |
Auth type change (bearer → api-key) | major — env var name probably changes too |
godmode CLI itself does not pin extensions to a specific version; it always installs the latest matching the user's range. If you ship a breaking change, bump major and document the migration in your README.
Ship the skill alongside (optional)
If you also want to publish a godmode skill so agent harnesses can install service-specific guidance, place a skills/godmode-<slug>/SKILL.md in the same git repo. Users run:
npx skills add yourscope/godmode-stripe…to install the skill into Claude Code, Cursor, Codex, etc. Independent of npm publish — Vercel's skills CLI walks the GitHub repo directly.
See also
- Submit an extension — naming conventions, reserved slugs, getting into
@godmode-cli/*. - Local development — iterate before publishing.
- Manifest schema — every field reference.