godmode

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
└── LICENSE

That'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:

FieldWhy
exports."./manifest"How godmode ext install finds the manifest. Required.
filesWhat 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 registry

That's it. Test the install path immediately:

godmode ext install @yourscope/godmode-stripe
godmode stripe --help

Slug resolution

When users run godmode ext install <name>, the resolution order is:

  1. Local folder path (starts with . or /) → reads manifest.yaml from disk.
  2. Scoped npm package (@scope/name) → installs as-is.
  3. 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:

ChangeBump
Pointed spec: at a new upstream URLmajor
New manifest field usedminor (older godmode CLIs will warn)
Description tweak, README update, no behavior changepatch
Auth type change (bearerapi-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

On this page