Pete Panel
Pete Panel workflows

Workflows

One-line commands. A full engineering process.

Every workflow runs inside a Pete playground — an agentic WordPress environment — with gates at the risky steps, and every rule in them was learned on a real migration.

Claude Code running /retheme end to end

/retheme

Classic theme → block theme · local-only · ends at a verified .zip

Migrates a WordPress site off a legacy classic theme — Genesis, Divi, or hand-rolled PHP — onto a standalone Full-Site-Editing block theme: theme.json design tokens, block templates, and reusable patterns. The agent inventories the legacy theme, extracts your palette, fonts, and section structure, then rebuilds it as native blocks — not just the homepage, but every page your main menu links to, converted and verified one at a time in menu order.

$ /retheme <PETE_SITE_LOCAL_URL>
Design gate Content gate Menu-driven page loop Never deploys Rollback: 1 command
  • Inventory
  • Design decisions
  • Foundation build
  • Page loop
  • Final verify
  • Package

Rules learned the hard way

  • Menu-driven page loop, homepage first — the work list isn’t “the homepage”; it’s every page the active main menu links to, derived during inventory. Each page is converted and render-verified before the next begins, so a regression always points at the page just touched. The run ends with a per-page checklist: page → HTTP status → verified.
  • Files, not database — every design decision lives in theme files, so the .zip carries the whole design.
  • Purge page caches and prove the change — cache plugins will happily serve the old theme’s HTML after activation.
  • Map assets to sections before composing — the image in the CSS isn’t always the hero art.
  • Flow wrapper, constrained content — or every full-width section silently boxes at content width.
  • The legacy theme stays installed — inactive, as the “before” state and instant rollback.

Field-tested on: a Genesis golf-club site; this very website — the Divi homepage, key pages, and 29 more pieces of content you’re browsing right now; and an 11-page Divi WooCommerce store rebuilt page by page through the menu loop, live checkout included.

Terminal screencast: /reblock running end to end

/reblock

Any page → block theme · rights-gated · stack-agnostic

Point it at a page on any stack — WordPress, Shopify, Webflow, headless — and it rebuilds the design as a self-contained block theme: bundled images, license-correct fonts, zero runtime references to the source. Before anything downloads, the rights gate asks one question: is this your property (faithful rebuild), or inspiration (an original design study with fresh branding, art, and copy)?

$ /reblock <PAGE_URL> <DEST_URL>
Rights gate Stack detection Self-contained output Fidelity report
  • Detect stack
  • Rights gate
  • Extract
  • Build
  • Verify
  • Package

Rules learned the hard way

  • Identify the source stack first — hashed bundles hide fonts; images may live on a separate origin entirely.
  • Trace @font-face, never trust <link> tags — sites load unused font kits while self-hosting the real display face.
  • Fonts by license — Google Fonts get bundled; commercial faces get an open substitute, documented.
  • Match layout, not just content — header composition, sprite-sheet logos, CSS background images, spacing rhythm.
  • Screenshots are the layout source of truth — text extraction misses what a picture shows instantly.

Field-tested on: Divi, Shopify, and headless-WP/Astro sources — three stacks, one repeatable process.

/push_page

Dev → production · exactly one page · backed up before it writes

Ship a single page from your local playground to production or staging — without a full-site deploy. It copies the page’s content, title, status, template, and the media that page references, rewrites the dev domain to the live one, and transports everything over SSH. Deliberately narrow: never themes, plugins, options, menus, or other pages. Re-run it as often as you like — it updates in place, keyed by slug.

$ /push_page <SRC_URL> <DEST_URL> [SSH_HOST]
Backup before overwrite Overwrite confirmation Exactly one page Idempotent by slug Media included SSH key auth only
  • Preflight
  • Export
  • Rewrite domains
  • Back up target
  • Push + media
  • Verify

Rules learned the hard way

  • Back up the target before any write — non-negotiable. It’s what makes the overwrite confirmation honest, and every push reversible with one command.
  • Update in place, keyed by slug — re-running must be idempotent. Import-based approaches silently create my-page-2 instead of updating the page you meant.
  • Never import a WXR file — your dev site isn’t publicly reachable, so attachment fetching fails and you end up with duplicate slugs and broken media.
  • Rewrite both URL schemes — dev is http://, production is https://. Miss the http:// variant and you ship mixed-content image URLs that browsers block.
  • Verify with a real request, never assume — the run isn’t done until the live URL returns 200 and actually contains the title and the pushed media.
  • If the target renders unstyled, stop and say so — the page depends on a theme or patterns that don’t exist there. Pushing a theme is a separate, deliberate act, not a silent side effect.

Field-tested on: this site. The case study you can read here and the homepage that links to it were both pushed to production with /push_page — backed up, domain-rewritten, and curl-verified on the way in.

Need a workflow for your stack?

These two are just the beginning — every migration teaches the next rule. Tell us what you’re moving.

Talk to Us
Why Agents + Pete