The Godmode MCP Server Receipt — What Ignition Actually Shipped
🚀 What shipped:
godmode-mcp@0.1.0 live on npm — npx -y godmode-mcp installs Godmode skills from inside Claude.🧠 How it was built:
/ignition — Stage 1 planned it with five blind-spot agents, Stage 2 executed autonomously with scoring.📊 The honest numbers: 17 blind-spot fixes incorporated, 5 declined, one mid-build backend pivot, composite
0.92.
What Got Built
The goal: make it possible for anyone running Claude to install Godmode skills by asking for them in chat — no zip downloads, no ~/.claude/skills/ fiddling, no copy-paste from a docs page.
The shipped version is an npm package called godmode-mcp. It speaks the Model Context Protocol, registers six tools with the user's Claude client, and every install is sha256-verified and atomic.
↓
🔌 Claude calls
godmode_install_lite via MCP
↓
☁️ MCP server hits
mcp-actions on Supabase, gets signed bundle URL + sha256
↓
📦 Zip streamed to staging dir, hash verified, entries screened for zip-slip
↓
✅ Atomic rename into
~/.claude/skills/godmode-lite/. Claude restarts. Skill available.
How Ignition Runs
Ignition is our two-stage protocol. Stage 1 is collaborative and gated — you sign off on every decision before execution starts. Stage 2 is fully autonomous — once you say ignite, it builds, tests, hardens, scores, and loops until the output passes the rubric.
Stage 1 — You drive
Ideation, deep research, a 5-agent blind-spot review of the plan, and explicit approval gates. No files are created until you say go.
Stage 2 — It drives
Build, test, harden, document, verify, polish, score. Below the rubric threshold? Fix loop. No pauses, no questions.
Think of it like planning a road trip with a friend, then handing them the keys. You agree on the destination, the route, the stops, the budget. Once the door shuts, they drive. No "are we there yet" — just a receipt at the end.
What the Blind-Spot Agents Caught
Before a line of code was written, five specialist agents reviewed the plan in parallel — security, architecture, operational, edge-case, and user-experience. They don't write code. They write objections.
17 of their objections made it into the final plan. Five did not. Both lists matter.
| Incorporated (17) | Why it mattered |
|---|---|
| Version-pinned install | Stops silent upgrades to the user's skills folder |
| sha256 bundle verification | Server compromise can't plant a tampered zip |
| URL allowlist | The server can only download from domains we control |
| Slug regex | Rejects ../, reserved Windows names, weird unicode |
| Zip-bomb caps | Entry count, total size, and per-entry size all bounded |
| Reserved-name + symlink rejection | Windows quirk — a skill named CON bricks the path |
| Lockfile on install | Two Claude windows installing at once can't corrupt the dir |
| Env-var scrub after read | Auth token doesn't sit in process.env for the whole session |
godmode_ tool prefix | Zero collision risk with other MCP servers |
Versioned /v1/ endpoints | Free to break the API in v2 without bricking old clients |
| Stripe race-condition error | Paid skill + webhook delay gets a clear message, not a silent failure |
Unique index on token_hash | Catches the one-in-a-billion collision at the DB, not at runtime |
Twelve of those seventeen are security or safety items. This is exactly what blind-spot review is for — the builder-brain is thinking about shipping the feature; the reviewer-brain is thinking about how someone breaks it.
What Got Declined
Not every agent objection is right. Five suggestions were deliberately left out, and each declined item has a reason written down so it can be revisited later:
Declined: Signed URLs
Skill bundles are public by design — the whole point is anyone can install Godmode Lite. Signed URLs solve a problem that doesn't exist here.
Declined: Pending Stripe state
The Stripe webhook is fast. A dedicated "pending" state adds UI and a race window for a 2-second edge case. Clear error beats a new table.
Declined: Multi-device tokens
One token per user is the simplest model. Multi-device is a problem to solve when someone asks for it, not before.
Declined: bundle_contents table
Nice-to-have manifest, but the sha256 already proves contents. Adding a table to re-prove the same thing is overhead.
The Mid-Build Pivot
The original plan put the backend on Cloudflare Pages Functions because the site was thought to run there. Wrong. Phase 1b recon pulled a response header from getgodmode.dev and saw rndr-id: — the site is on Render. CF Pages Functions don't deploy against a Render-hosted site.
The autonomous stage pivoted mid-build: backend rewrote from CF Pages Functions to a Supabase Edge Function called mcp-actions, which also matched the existing arena-actions pattern already in the repo. One pivot, no user intervention.
HEAD getgodmode.devrndr-id: (probing…)
mcp-actionsmatches existing
arena-actions
rndr-id DETECTED · BACKEND REWRITTEN MID-BUILDCore insight: The blind-spot phase protects against bad plans. The build phase protects against bad assumptions in the plan. You need both — agents reviewing paper can't catch a wrong fact about infrastructure that only a live HTTP call reveals.
Dimension Scorecard
Stage 2 blocks delivery until every dimension clears 0.85 and the composite hits 0.92. No inflated scores, no hollow compliance — the lowest score is the honest one.
| Dimension | Score | Notes |
|---|---|---|
| Context load | 0.95 | Mapped site stack, Supabase schema, existing edge functions, npm rules |
| Execution | 0.92 | Pivot cost a re-write; otherwise clean on first pass |
| Security | 0.93 | sha256, allowlist, zip defense, reserved names, token scrub — all live |
| Tests | 0.90 | 22 vitest + stdio smoke test + live Supabase catalog smoke — all green |
| Docs | 0.92 | mcp-setup.html, account card, inline JSDoc on every public tool |
| Delivery | 0.92 | Published live to npm, local MCP registered, memory updated |
| Composite | 0.92 | Threshold passed, no fix loop triggered |
The Honest One: Tests 0.90
23 unit tests cover the security-critical code paths — slug regex, zip-slip rejection, URL allowlist, Windows reserved names. Two smoke tests prove the binary launches and the live Supabase backend responds correctly.
What's not there: end-to-end install tests across Linux, macOS, and Windows in a sandboxed environment. Those require CI. Instead, we install-tested locally on Windows during the build phase, and the release uses version pinning so anyone hitting a platform-specific bug reports against a known sha.
If anyone hits a platform-specific install bug, godmode-mcp@0.1.0 is the exact tree they're running against and we can ship a fix to 0.1.1.
The Ignition Hand-Off in One Line
Ignition's real value isn't speed — it's the contract. You decide what gets built and what doesn't. It decides how to make every piece hold up. Here's the exact moment the hand-off happened:
One keystroke. After that, the session ran build, test, harden, document, verify, polish, and score without another user message until godmode-mcp@0.1.0 was live on npm and the local client could call godmode_list_products.
Ignite Your Own Build
Stage 1 is collaborative, gated, and in your control. Stage 2 builds, tests, hardens, scores, and ships. One protocol, any project.
Install the MCP Server See Access Tiers →