For developers

WordPress as a deploy target for Claude Code.

Typed bridge to real WP data. App-Password auth that takes ten seconds. Atomic deploy with one CLI command. Choose iframe mode for untrusted bundles, or inline mode when you want native SEO and site-owned routes.

CLI reference GitHub MIT / GPL

The loop

From `init` to live in three commands.

The CLI scaffolds an Astro starter, authenticates with a WordPress Application Password, and pushes the bundle. Each subsequent deploy is an atomic update at the same app id.

1 · scaffold

Start a new app.

A starter Astro project with dsgo-app.json wired up, the typed bridge installed, and a CLAUDE.md documenting the current bridge surface.

npx designsetgo apps init my-app

2 · authenticate

Log in once.

Uses WordPress Application Passwords — built into core, scoped, revocable. Credentials are stored at ~/.config/designsetgo/credentials.json with 0600 permissions.

npx designsetgo apps login

3 · deploy

Ship it.

Builds, shows you the capability diff, and atomically replaces the bundle on the site. Re-run as often as you like — same app id, no downtime.

npx designsetgo apps deploy --build

The bridge client

No REST plumbing. No auth boilerplate.

The @designsetgo/app-client package gives you typed access to your WordPress site. Same surface in inline mode (same window) and iframe mode (cross-frame) — the transport is auto-selected.

app.ts @designsetgo/app-client

// Read posts, pages, the current user, and per-app storage.
// The bridge handles auth + REST behind the scenes.

import { createBridge } from "@designsetgo/app-client";

const dsgo = createBridge();

// Site context
const site = await dsgo.site.info();

// Real posts, filtered by what the current user can see
const { posts } = await dsgo.posts.list({
    category: "recipes",
    per_page: 10,
});

// Logged-in user — and what they're allowed to do
const me = await dsgo.user.current();
if (await dsgo.user.can("edit_posts")) {
    // show the editor-only UI
}

// Per-app, per-user persistent storage — survives reloads
await dsgo.storage.user.set({ favourites: [42, 88] });

AI surface

Apps can talk to the site’s AI — and the site’s AI can talk back to apps.

DSGo apps can call dsgo.ai.prompt() to reach the site’s configured Connector (DSGo never sees the keys), and dsgo.abilities.invoke() to call any ability another plugin registered. Apps can also publish abilities back through abilities.publishes, making them invokable by the site’s AI agent.

Consume

Use any ability your site has.

Yoast Premium ships analyze-page-seo. WooCommerce can register list-products. Your app calls them with one line. As your site grows abilities, your app does too — without a rewrite.

await dsgo.abilities.invoke('woocommerce/list-products', {...})

Publish

Become an ability.

Declare abilities.publishes in your manifest. DSGo registers each via the WordPress Abilities API. Both iframe and inline apps can publish; iframe is the stronger isolation path, inline is the crawlable trusted-code path.

"abilities": { "publishes": [...] }

CI & multi-site

Deploy from GitHub Actions. Ship to many sites at once.

A wrapped Action does what the CLI does, with secrets out of the repo. Agencies can pass --site=... repeatedly to push the same bundle to every client; each install reads that client’s WordPress data.

.github/workflows/deploy.yml DesignSetGo/deploy-action@v1

on: { push: { branches: [main] } }

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci && npm run build
      - uses: DesignSetGo/deploy-action@v1
        with:
          site: ${{ secrets.DSGO_SITE }}
          username: ${{ secrets.DSGO_USER }}
          app-password: ${{ secrets.DSGO_APP_PASSWORD }}
          bundle: dist

Read the bridge spec.

The bridge protocol is public and frozen at v1. Any plugin that implements it can run a DSGo app — real anti-lock-in commitment.

Bridge API Manifest reference