Ship 30 WordPress apps a week from CI with one CLI command

Your agency onboards 8 clients a month. Each one wants 3 to 5 small apps: a reservation form, a menu page, a member portal, a pricing calculator. That is 30 custom apps a month your team has to build, test, and deploy. By hand. Every month.

A developer day costs $800. A simple app eats 4 hours. Do the math. You are burning roughly $24,000 a month on work that is mostly the same five patterns with different copy.

That is the part that hurts. Not the cost. The repetition. Your senior people are writing the same contact-form-with-email logic for the 47th time, while the interesting work (the part that made them join an agency) sits in the backlog. Turnover follows. So does the gap between “we promised the client this Friday” and “the dev is still building it.”

What changes when an agent runs the deploy

DesignSetGo Apps ships a WP-CLI command, wp dsgo harness generate, that turns a one-line prompt into a validated WordPress app bundle. Pair it with npx designsetgo apps deploy (the @designsetgo/cli package), and Claude Code, Cursor, or a GitHub Actions runner can ship a new app to a client site without a human touching wp-admin.

Same five patterns, generated and deployed from CI. The senior developer reviews the bundle in a PR; they do not write it.

The basic two-step

On a server with WP-CLI installed and a DesignSetGo Apps Pro license active:

wp dsgo harness generate \
  --prompt="A contact form that emails the admin when someone submits it." \
  --out=./contact-form.zip

The command sends the prompt through wp_ai_client_prompt() (using the site’s configured WordPress 7.0 Connector, so no API keys live in DesignSetGo), runs the harness pipeline (system prompts, tools, validator, autofix), validates the manifest against the v1 schema, and writes a zip to disk. Twenty to sixty seconds, end to end, depending on provider latency.

The CLI generates. It does not deploy. That is the second step:

unzip contact-form.zip -d ./contact-form
npx designsetgo apps deploy ./contact-form --site=https://yoursite.com

The split is deliberate. Generate once, review the bundle in a PR, deploy to one client or fifty. No regeneration. No drift.

The actual flags

The full surface of wp dsgo harness generate in v1:

--prompt=<text>   The user prompt. Required. Use '-' to read from STDIN.
--out=<path>      Path for the generated zip. Required.
--quiet           Suppress human-readable progress output.
--json            Print a single JSON object to stdout on completion.

No --slug, --deploy, --profile, --no-validate, --update, --max-autofix-rounds, or --dry-run. The contract is intentionally small. Deploy and configure happen in separate, composable steps.

Slug comes from the generated manifest’s id field. Override by editing dsgo-app.json inside the bundle before deploy.

STDIN prompts for the longer ones

cat prompt.txt | wp dsgo harness generate --prompt=- --out=./out.zip

Or via heredoc:

wp dsgo harness generate --prompt=- --out=./out.zip <<'EOF'
A multi-page member portal with three views (overview, my posts, preferences),
gated to logged-in users, with per-user preference storage.
EOF

JSON output that scripts can branch on

--json emits one line of structured output:

{"ok":true,"attempts":1,"first_pass":true,"app_id":"contact-form","out":"./contact-form.zip"}

On failure:

{"ok":false,"error_code":"ai_not_configured","error_message":"No WP AI Connector is configured."}

The schema is stable. On success: attempts (how many harness rounds ran), first_pass (true if no autofix was needed), app_id, out. On failure: a stable error_code enum plus a human-readable error_message.

Exit codes for shell scripts

0  success
1  general error
2  provider_error or parse_error (harness pipeline produced bad output)
3  wp_version_too_old or ai_not_configured (preflight failure)
4  empty_prompt or prompt_too_long (input validation)

A sane provisioning script branches: 3 means configure the site and retry. 4 means the prompt is wrong, do not retry. 2 likely means a flaky provider, retry might help. 1 is the generic catch-all.

Validate a bundle without invoking the model

wp dsgo harness validate ./contact-form.zip

Checks the zip against the v1 manifest schema and the harness’s structural rules, no LLM call. Success prints Success: OK and exits 0. Failure prints a JSON line with code, message, and data, and exits 1. Run this in CI before the deploy step. Catch the bad bundle before it touches a client site.

The worked example: restaurant onboarding in 9 minutes

Agency onboards a new restaurant client. A YAML file describes the setup:

site_url: https://restaurant-name.com
apps:
  - prompt: "A menu page styled like a printed bistro menu. Pull dishes from the 'menu_item' custom post type."
  - prompt: "A reservation form that emails the manager when someone submits."
  - prompt: "A hours-and-location widget for the homepage."

The provisioning script reads the YAML, generates each bundle over SSH, then deploys with the JS CLI:

i=0
for prompt in $(yq '.apps[].prompt' config.yml); do
  i=$((i+1))
  out="/tmp/bundle-$i.zip"
  ssh deploy@restaurant-name.com "cd /var/www/wp && wp dsgo harness generate --prompt='$prompt' --out=$out --json" \
    > "/tmp/bundle-$i.meta.json"
  scp "deploy@restaurant-name.com:$out" "./bundle-$i.zip"
  unzip "./bundle-$i.zip" -d "./bundle-$i/"
  npx designsetgo apps deploy "./bundle-$i/" --site="$site_url"
done

Three apps. Roughly 3 minutes of harness time each. Total wall-clock: under 10 minutes from “kick off the script” to “all three apps live.” Compare that to a developer day per app. Adding a fourth app later means one new line in the YAML.

The harness is doing the engineering. The developer is doing the prompt and the review. Your senior people get their interesting work back.

When the CLI is the wrong tool

• The client is going to want to iterate on the prompt 15 times. The browser admin page is faster; they see the result immediately.
• The user is non-technical. WP-CLI needs shell access. The admin page does not.
• The bundle needs hand-tuning. Generate, unzip, edit, then npx designsetgo apps deploy. Same end state, review pass in the middle.
• No Connector is configured on the site. The CLI fails predictably (ai_not_configured, exit code 3). The admin page walks the user through configuration first.

CLI is for “I know what I want, I want it scripted.” For exploration, use the browser surface.

Start your 14-day Pro trial and ship the next app from CI

CLI deploy and wp dsgo harness generate are Pro features. The free tier covers one app with HTML upload through wp-admin, which is the right way to kick the tires. Hit the 14-day Pro trial when you are ready to wire the harness into your CI and stop billing clients for the 47th contact form.

Start your 14-day Pro trial. No card on the free tier.

Where to go next

• The harness post for what the pipeline actually does.
• The GitHub Action post for the same apps deploy flow in CI.
• The Apps as Abilities vertical pack post for the pack model scripted provisioning tends to produce.