Skip to main content

SpiderPublish Extension

Edit your CMS like code. A headless CMS that lives in your IDE.

The SpiderPublish extension brings every SpiderPublish primitive — pages, posts, components, templates, deploy — into VSCode, Cursor, and Antigravity. Pull your tenant's content onto disk, edit it as files, see exactly what changed with the native VSCode diff editor, push with snapshot-bound preview→confirm, and deploy to the Cloudflare edge in seconds.

Same workflow whether you're a developer, an AI agent in chat, or an agency managing fifty client sites.

Get started​

1. Install

VSCode 1.85+, Cursor, or Antigravity. One install, fourteen commands, zero new credentials beyond the PAT you already have.
Install guide →

2. Commands

Pull, Stage, Push Content, Deploy Site, Audit Internal Links, Accept Proposed Redirect — plus the diagnostic helpers.
Command reference →

3. Link audit

Pre-push hook scans every page and nav menu for broken internal links. One-click "Accept redirect" Code Action.
Link audit →

4. Troubleshooting

Show Diagnostic Info, common issues, support reports, log levels.
Troubleshooting →

In one screen​

$ spideriq auth request --email admin@your-company.com    # admin approves via email
$ cd ~/clients/acme-corp
$ spideriq use acme-corp                                  # binds folder ↔ tenant
$ code .                                                  # or cursor / antigravity

  Cmd+Shift+P → SpiderPublish: Pull
    pages/, posts/, components/, templates/  land on disk

  Edit pages/home.json
    Status bar:  📁 acme-corp · 1 changed · 0 undeployed
    Click the file in the Changes view → native VSCode diff opens

  Cmd+Shift+P → SpiderPublish: Push Content
    pre-push link audit  →  review panel  →  snapshot-bound confirm  →  live

  Cmd+Shift+P → SpiderPublish: Deploy Site
    readiness check → preview → confirm → Cloudflare edge in ~3s

Architecture​

The extension is a thin UX layer on top of the @spideriq/mcp-publish MCP server. On activation it spawns the MCP server as a child process (~336 ms cold start) and delegates every backend call to it. Same 87 tools, same auth, same preview→confirm semantics — just rendered into VSCode's native UI:

┌─────────────────────────────────────────────────────────────────┐
│  VSCode / Cursor / Antigravity                                  │
│   ├─ Tree view (Changes)         ← reads from .spideriq registry│
│   ├─ Status bar                  ← draft + undeployed counts    │
│   ├─ Native diff editor          ← virtual URI providers        │
│   ├─ Diagnostics                 ← JSONPath → file:line decoder │
│   └─ Code Actions                ← "Accept redirect" Quick Fix  │
│                          │                                       │
│                          ▼  (child_process.spawn)                │
│   @spideriq/mcp-publish (87 tools)                               │
│      └─ HTTPS → spideriq.ai/api/v1/dashboard/projects/...        │
└─────────────────────────────────────────────────────────────────┘

This means every command you run in the extension is the same primitive an AI agent uses in chat. There's no second code path; nothing the extension does is hidden from agents and nothing agents do is hidden from the extension.

Why this is different​

Content as source, not a database. Every page, post, component, and template is a file on disk. git diff-clean. Reviewable in PRs. Reverted with one command.

Native VSCode diff for content. Through virtual URI providers (spiderpublish-baseline: for the last-pulled snapshot, spiderpublish-remote: for the live state), the actual VSCode diff editor opens — not a custom webview.

Multi-tenant safe by default. The extension walks UP from the active editor's file (not the workspace root) to find spideriq.json. An agency can keep fifty clients open in one window and never push to the wrong tenant.

Two-phase mutations, no surprises. Every destructive operation is preview-then-confirm. Snapshot-bound confirm_tokens pair the preview to the exact payload that requested it. The preview is what gets confirmed; nothing else.

Built for AI agents from the first commit. The bundled MCP child process is the same surface registered as Language Model Tools in Cursor / Antigravity. Anything you can do here, an agent can do for you.

Status​

Current version: 0.1.x — first user-installable release.

SurfaceWhat ships in 0.1
AuthSign In (paste-token PAT), Select Project, Who Am I, multi-tenant spideriq.json
ReadPull (parallel per-type GET, 3-way merge), Changes view, status bar
WriteStage / Unstage, Push Content (snapshot-bound), Push Current File, Discard Changes
DeployDeploy Site (readiness → preview → confirm → poll)
ValidationJSONPath → file:line diagnostics on every push/deploy failure
AuditPre-push link audit, manual Audit Internal Links, "Accept redirect" Code Action

Roadmap ahead: navigation registry tracking (so nav broken-links also get inline diagnostics), bulk redirect accept, "Mark as intentional" Code Action, component-preview iframe panel.

Reference​

  • CLI counterpart: @spideriq/cli — same primitives, terminal-first. Install guide ↗.
  • Agent integration guide: SpiderPublish AGENTS.md — what AI agents see when they degit the starter kit.
  • MCP transport: @spideriq/mcp-publish@^1.6.0 (87 tools).
  • License: MIT.