A Claude Code plugin that mirrors a live WordPress site down into a local DDEV copy — clone a fresh copy or pull to refresh an existing one — scaffolds a brand-new local site from nothing, and builds one out on the Ollie block theme.
kntnt-wp-skills brings a live WordPress site down to your machine as a local DDEV copy. It ships four skills: clone creates a fresh local copy in an empty directory, pull refreshes an existing copy from production, mkwp scaffolds a brand-new local site with no production source at all, and build-ollie-site builds a site out on the Ollie block theme from a design system and a set of mockups. Each is started by its slash command and runs only when you invoke it; none fires on its own — clone/pull because each executes code on production and overwrites the local database, mkwp because it writes a new local site, and build-ollie-site because it writes a theme and content into a WordPress install.
The first three are about bringing a site down or standing one up; build-ollie-site is about building one out. It takes a design system and mockups and builds a coherent, token-correct site on the Ollie block theme, bottom-up by Atomic Design — deriving the pattern taxonomy from the mockups' structure, mapping the design system into an Ollie child theme's tokens, then building component patterns, composing them into section patterns by slug reference, and assembling pages from sections. It is the natural next step after a clone or mkwp has produced the local site to build into.
The plugin reaches production through a single channel — the Kntnt Extractor plugin's REST API on the live site, authenticated with an Application Password — and never over SSH. Every decision it makes, from which tables to carry with their data to which multi-gigabyte galleries to leave behind, is put to you as a recommendation you accept or override. A routine refresh is a short walk through a handful of gates; an unattended run is a single flag.
- Four skills:
cloneandpullover one shared transfer engine, the standalonemkwpfor scaffolding a brand-new local site, andbuild-ollie-sitefor building a site out on the Ollie block theme. All four install as plain skills in any harness, with or without the plugin. - Bottom-up, Atomic-Design site building on Ollie: tokens → component patterns → section patterns → pages, derived from your mockups and verified against what the live install actually resolves.
- One control channel — the Kntnt Extractor REST API — and no SSH.
- A recommendation with an accept-or-override gate for every decision, so nothing surprising happens silently.
- Three speeds: interactive by default,
--yesfor an unattended run, and replay of a saved plan for a quick repeat. - Incremental file transfer against a stored baseline, so a refresh moves only what has changed.
- User data sealed to a per-run ephemeral key in transit, with the remote extraction consumed the moment the download unseals.
- URL-scoped search-replace and a rewrite flush with plugins loaded, so localised subpages keep working.
- A per-site configuration committed alongside the project, so a copy is reproducible.
A faithful local copy of a production WordPress site is more fiddly than it first looks. The database and uploads are large, they carry real user data that has to move safely, and parts of them — analytics tables, generated thumbnails, oversized galleries — are better left behind or rebuilt locally than carried whole. Doing this by hand, again and again, is slow and easy to get subtly wrong. Not everyone even has SSH access to automate it.
The plugin handles the fiddly parts and asks you only about the decisions that matter. It discovers the site's shape, has the Kntnt Extractor plugin extract a trimmed, sealed copy on production, downloads only what has changed, imports it into DDEV, and localises the result — thumbnails regenerated, URLs rewritten, rewrite rules flushed with plugins loaded so language routes are not lost. Because it works solely through the Extractor plugin's capability-gated REST API, enabling it on production is a far smaller ask than handing over SSH.
The plugin assumes you have already put a few things in place. Each note says why it is needed.
- DDEV up and running, which in turn needs Docker (or an equivalent such as OrbStack) and DDEV's own dependencies. These are DDEV concerns, not this plugin's.
- The Kntnt Extractor plugin (API version ≥ 2) installed and activated on the production site, and an Application Password for a WordPress user holding both the
kntnt_extractor_operateandmanage_optionscapabilities. This is the only channel to production, reached over HTTPS with that Application Password as HTTP basic auth. Onlycloneandpullneed this —mkwpdoes not. mkwp≥ 1.8.1 on yourPATH, used by both thecloneskill and themkwpskill to scaffold a site. Its--dirnameflag is what lets the site's directory be named independently of its DDEV project name (e.g. after a full production host, while the DDEV project keeps a shorter, hostname-safe slug); 1.8.1 is the floor because it is the release that fixes Kntnt/mkwp#3, where an earliermkwpbroke the scaffold outright whenever--dirnamediverged from the site's name.- The CLI tools
uv,jq, andcurlon yourPATH— used by the helper scripts and the transfer pipeline. The sealed-container unseal is auv-run helper withpynaclas an inline dependency, so no separate checksum or encryption binary is needed.cloneandpullverify all of the above (and the target's Kntnt Extractor endpoint — its API-version handshake and that your Application Password's user holds both required capabilities) automatically at the start of every run, telling you exactly what is missing and how to fix it rather than failing partway through.
build-ollie-site has narrower requirements, because it never touches production: a WordPress install running the Ollie block theme as the parent of a child theme you build into (a local DDEV copy that clone or mkwp produced is the assumed target), WP-CLI reachable as wp (or ddev wp), and uv for its helper scripts. It needs neither Kntnt Extractor nor mkwp; the Ollie Abilities / MCP are optional, used only as a convenience hand for content operations.
This is the primary channel, and the one the transfer engine runs fastest in. Add the plugin's marketplace and install it from within Claude Code:
/plugin marketplace add Kntnt/kntnt-wp-skills
/plugin install kntnt-wp-skills@kntnt-wp-skills
All four skills are self-contained — every reference, helper script, and role file each one names lives inside the skill directories themselves — so a generic skill installer such as npx skills, which reaches some seventy-five agent harnesses, can carry them anywhere:
npx skills add Kntnt/kntnt-wp-skills
That command installs all four: clone, pull, mkwp, and build-ollie-site. Install them together — pull runs the engine clone ships, and both derive their names with the classifier mkwp ships; each one's health check says so plainly if a sibling is missing, before it touches anything.
Two things differ outside the plugin. The help forms print a brief usage summary instead of the full manual page, which only the plugin can render, and each skill is invoked bare — /clone, /pull, /mkwp, /build-ollie-site — since there is no plugin namespace to prefix. And the transfer engine runs its four heavy phases sequentially, in the orchestrating agent's own session, wherever the harness cannot spawn subagents: same steps, same evidence, same deterministic helpers, but slower and one after another rather than delegated. It is not louder — every noisy step writes its full output to a log file under the run's scratchpad and reports a compact summary — but a clone of a large site will take longer than the same clone under Claude Code, which delegates each phase to a pinned subagent with its own context.
What no channel changes is what the engine needs on either side: uv, ddev, jq, and curl locally, WP-CLI through DDEV for the localisation steps, and the Kntnt Extractor plugin installed and active on the production site it reaches. mkwp still needs ddev and mkwp itself; what none of them needs is the plugin.
Every skill is started by its slash command and runs only when you invoke it. The full option reference lives in the manual pages — clone, pull, mkwp, and build-ollie-site — also reachable as /kntnt-wp-skills:help clone, /kntnt-wp-skills:help pull, /kntnt-wp-skills:help mkwp, and /kntnt-wp-skills:help build-ollie-site. build-ollie-site's deeper architecture — how it distils the source skills and where its patterns live — is in its own DESIGN-RATIONALE.md.
Run /kntnt-wp-skills:clone in an empty directory. The skill derives a local DDEV project name and a clone directory name (the full production host, e.g. www.example.com) from the production URL, scaffolds the site with mkwp at production's exact core version into that directory, and brings down the database and media. After the import your local users are production's, so you log in with your production credentials.
Run /kntnt-wp-skills:pull from the project directory. The skill takes a rollback backup of the local database, transfers only what has changed since the last sync, re-applies your local state — the inactive plugins you had, the object-cache drop-in — and localises the result. The path to the rollback backup is reported so you can keep it.
Run /kntnt-wp-skills:mkwp <name> to create a local WordPress site from nothing — no production source involved. The skill derives what it can from context (site name, directory, title, locale, and so on) and confirms the rest at recommendation gates, the same shape clone/pull use; --yes accepts every recommendation, including installing Kntnt Extractor so the site is already reachable by a later /kntnt-wp-skills:clone/pull. The first user's password is always mkwp's own random generation, shown only in its own on-screen output.
Run /kntnt-wp-skills:build-ollie-site against a local site whose theme is Ollie (or an Ollie child), pointed at your design system and mockups. The skill works bottom-up through gated phases — ground truth → pattern cartography → foundation (tokens) → component patterns → section patterns → pages — and never builds a layer before the one below it is locked and verified. Its distinctive first phase is pattern cartography: it derives the pattern taxonomy from the mockups' structure (not their content), proposes it as a manifest, and settles that manifest with you before building anything. Ollie supplies only tokens and global styles; the site's patterns are your own, composed by slug reference so that editing a component cascades to every section and page that uses it.
The transfer-engine skills (clone/pull) and mkwp share these run modes; build-ollie-site instead walks its own phase gates, pausing for you to confirm the pattern manifest before the build proceeds.
- Interactive (default) — walk each recommendation; accept it, or decline to reveal the alternatives and choose.
--yes— accept every recommendation, pause for nothing, and print a full record of what was decided and done.- Replay — when a saved plan exists for the site, the whole walk collapses to a single replay the saved plan? gate.
By default the site's existing mailer stays active so you can test the real send flow; if discovery finds a campaign queued against a real recipient list, the recommendation flips to capturing all mail in DDEV's Mailpit with a loud warning. A risk warning is always shown before the destructive steps, listing what reaches outward — real mail, a running cron firing real webhooks, payments, or social posts, and the database's real user data. Use --live-mail or --capture-mail to force the choice. Interactive mode waits for your confirmation; --yes prints the warning for the record and proceeds.
Have a usage question or something to discuss? Please use Discussions.
Found a bug or want to request a feature? Please open an issue. Search the existing issues first to avoid duplicates.
The plugin's logic lives in Python helpers invoked via uv, each shipped inside the skill that drives it — the transfer engine's under skills/clone/scripts/, the version guard and classifier under skills/mkwp/scripts/, and only the manual-page renderer at the plugin root under scripts/; the heavy production-side work — extraction, per-segment sealing, the one-time download link, and cleanup — is owned by the Kntnt Extractor plugin, not generated here (ADR-0017). Clone the repository, then read the coding standard materialised under agents.d/coding-standard/ — general.md plus python.md — before changing code.
The helpers are covered by a pytest suite under tests/. One command runs the whole suite, provisioning pytest through uv (no separate install step):
uv run --with pytest pytest
Contributions are welcome, small or large. Before you start, read CONTRIBUTING.md — it covers which kinds of change are likely to be merged and how inbound licensing works.
Licensed under the Apache License 2.0. The full licence text is in LICENSE.
Release notes for each version live in CHANGELOG.md.
The project follows Keep a Changelog and Semantic Versioning.