AI Website Creator
The Site Converter answers "I have a site, make it Unyson+." The AI Website Creator is the other half: "I have nothing — make me a beautiful, animated site." It runs through the AI Dev Kit, which the person installs into their own Claude Code or Cursor, and it drives the framework's existing fresh-build and Site Converter paths to a finished, editable Unyson+ site.
:::note Status: planned, not started Nothing on this page is built yet. It lives here so the plan survives outside a chat log — see the house rule on roadmaps. Scope and ordering will move; the framing below is what we have agreed so far. (This page was the earlier "Site Generation Roadmap", now named and expanded.) :::
Verified against the extension source on 2026-10-20.
Phase 1 · The archetype cataloguePlanned
0/7A curated set of section archetypes, each a small recipe that emits page-builder JSON + Unyson+ shortcodes + Animation Engine effects, with colour and type coming from Theme Settings presets rather than baked onto each element. Start where the demand is — heroes, navbars, feature grids, CTAs, footers, marquees — not at a hundred thin entries.
- Recipe format — Planned
One document shape every recipe follows: when to use it, the composition (the exact shortcode arrangement as a builder-JSON template), the motion (which Animation Engine effect pairs with it, and the restrained default), the tokens (which Theme Settings presets it expects), and a live preview (a link to our own demo page). The format is the contract the composition guide and the create-site skill both read.
- Hero recipes — Planned
The highest-frequency archetype by a wide margin. A handful of genuinely good heroes (centered, split, editorial-oversized, media-backed), each as a builder-JSON template with restrained motion and preset-driven type.
- Navbar recipes — Planned
Universal header patterns built on the Header/Footer Builder: logo, primary nav from the sitemap, an accessible mobile menu, an active-page state, and the primary CTA.
- Feature-grid recipes — Planned
Icon-box and card grids for features, services and benefits, mapped to the real shortcodes with preset-owned card skins (never per-element copies).
- CTA recipes — Planned
Conversion blocks — banner CTAs, split CTAs, inverted full-bleed CTAs — with the button skin living on its colour preset.
- Footer recipes — Planned
Universal footer patterns on the Footer Builder: brand summary, navigation, the primary conversion path, and legal links once they exist.
- Marquee & logo-strip recipes — Planned
Moving strips for logos, words and proof, using the native marquee element with reduced-motion handling built in.
Phase 2 · The style libraryPlanned
0/4A curated set of named design directions a person can pick from — the "make the design <style>" input. A style is not a theme file; it is a mapping from a look to Theme Settings presets (palette, fonts, radius, borders, spacing), the Animation Engine register that fits it (instant vs. cinematic), and the section treatments that express its personality. We take the taxonomy and the design thinking from the public design-prompt libraries; every style is re-authored here in our own vocabulary, because those prompts describe React and Tailwind components, not page-builder output.
- Style model — Planned
How a named style resolves to a design system: the Theme Settings preset set it writes, the type pairing, the radius/border/texture rules, and the Animation Engine defaults. One model so every style is described the same way and the picker can list them.
- Map to the existing aesthetic skills — Planned
Several directions already exist as design skills — a refined default, minimalist, brutalist, and a high-end "expensive-agency" look. A style entry points at the matching skill where one exists, and only carries a new recipe where there is a genuine gap, so the library reuses rather than duplicates.
- Seed the high-value styles — Planned
A first set drawn from the demand we can see: a monochrome editorial look (pure black and white, serif hero, zero radius, line textures, inversion hover), a newsprint look, a Swiss/Bauhaus grid look, a modern dark look, a terminal look, a luxury look, and a kinetic/motion-led look. Each is a design direction expressed as Theme Settings presets plus section treatments — authored here, never copied.
- The style picker — Planned
The intake step that offers the styles as an enumerated choice (the "dropdown"), with a describe-your-own escape hatch so the curated set is never a cage. In the kit this is a choice in the create-site flow; in a later in-admin or hosted surface it becomes a visual picker with thumbnails — same list, no rework.
Phase 3 · The composition guidePlanned
0/2A catalogue of parts is not a site. This is the sequencing layer that turns a chosen style and a set of archetypes into a coherent page, and it slots onto the existing build protocol rather than replacing it: design system first → chrome (header/footer) → sections, region by region → motion → ship gate. The generator is no more allowed to skip to "write sections" than a careful human build is.
- Composition guide — Planned
The ordering rules, the page-shape heuristics (which archetypes a given page type wants, and in what sequence), and the hand-off into the build protocol's phases and gates.
- Ship-gate wiring — Planned
Every composed page carries the same accessibility, SEO and performance obligations as everything else we ship — reduced-motion handling, a sane Web Vitals cost, real content in the HTML — checked with the kit's
tools/measureharness. A page that fails the gate does not ship.
Phase 4 · The create-site skillPlanned
0/7The single entry point the person runs in their own Claude Code / Cursor through the AI Dev Kit. One flow, four ways in: a plain-language brief, a reference URL, a design reference (screenshot / image), or a vertical template. It gathers a structured spec, then drives the build protocol (or the Site Converter for the URL and design-reference paths) to a finished, editable Unyson+ site.
- Skill scaffold — Planned
A
create-siteskill under the kit's reservedskills/folder: aSKILL.mdthat wires the intake, the style picker, the archetype catalogue, the composition guide and the ship gate into one routed flow. - Site spec — Planned
A structured description of the site — business, pages, brand, style, sections, SEO, compliance — generalized from the CRM website generator's
site-spec.json. The spec, not a prose prompt, is the source of truth the build reads. - Input: a brief — Planned
From a plain-language brief ("a barber shop, warm and dark, booking-led") to the spec: propose a sitemap, pick a style and archetypes, fill copy, choose a palette. The fresh-build path — the only input that skips capture.
- Input: a reference URL — Planned
Hand the URL to the capture service and Site Converter, which produce a native build; the creator then refines it through the same composition and ship-gate steps. Reuses the converter end to end rather than re-implementing it.
- Input: a design reference — Planned
From an uploaded screenshot or image: read the look (palette, type, spacing, treatment) into a style and tokens, without copying the reference's content, logos or distinctive layout. Captures the design, builds original content on it.
- Input: a vertical template — Planned
Pick an industry starting point and let the creator customize it — the CRM-generator pattern, generalized (see Phase 6).
- Build rules ported from the field — Planned
The durable rules a good WordPress build follows, as the creator's own: editable builder output (never static HTML or one big Custom HTML block), one universal header and footer, drafts not published until asked, native Unyson+ / theme SEO configured against the real business details, and no invented testimonials, metrics, pricing or claims.
Phase 5 · Content maintenancePlanned
0/4After the site exists, keep it growing. A separate flow for creating a page or post around a topic: research and recommend, wait for approval, draft and optimize for SEO, then publish only on an explicit second approval. Two gates, never one.
- Content skill — Planned
A
contentflow in the kit that uses the existing site and its records as the source of truth, so it never re-asks for business, audience or brand facts already known. - Research & recommend (gate 1) — Planned
Study the sitemap, internal links, the topic and search intent; return page-vs-post, angles, titles, a heading structure, the internal links to add, and the specific expert questions only the owner can answer. Wait for approval before drafting.
- Draft & optimize — Planned
Create an editable draft in the current design system, set title, permalink, meta and schema, run the native SEO checks, add genuinely-relevant internal links, and never keyword-stuff or invent facts to satisfy a score.
- Publish (gate 2) — Planned
Publish the approved draft only on an explicit go-ahead — do not rewrite it — then verify the public URL, canonical and SEO metadata.
Phase 6 · Vertical templatesPlanned
0/3Generalize the CRM website generator into the creator's vertical-template layer, so an industry is a starting point rather than a separate product. The CRM Generator becomes the first vertical; its industry presets become the model for the shared library.
- Vertical-template format — Planned
The generalized, non-industry form of the CRM generator's industry presets: pages, copy, forms, the spec and the build wording for a vertical, as data the create-site flow reads.
- CRM as the first vertical — Planned
Fold the CRM website generator in as the first vertical-template provider: its spec and prompts already drive the AI Dev Kit fresh-build path, so it is the proof the pattern works. The CRM pipeline, forms and newsletter CRM come switched on for this vertical.
- Further verticals — Planned
A handful more, drawn from the generator's existing set (local business, professional service, ecommerce, SaaS), each a vertical template the creator can start from and customize.
Phase 7 · The style galleryPlanned
0/2A rendered Unyson+ example per style, so a person can see before they pick — and so the gallery doubles as proof of what the creator makes. Built on our own demos network, listed on the demos home, never a copy of anyone else's preview media.
- A demo page per style — Planned
One native Unyson+ page per seeded style, each the same content rendered through that style's presets, so the differences are the design and nothing else.
- Listed on the demos home — Planned
Each style demo gets a card on the demos home grid, so it is discoverable and never orphaned, per the house rule for demos.
Phase 8 · Product surfacePlanned
0/3Make it easy for a non-expert to drive. v1 is the kit itself — install the AI Dev Kit, point your agent at your WordPress, run the create-site flow — with onboarding that explains exactly that. An in-admin wizard and a hosted web app are later surfaces on the same proven engine, not v1.
- Onboarding — Planned
The guided "how to use it" path: install the kit, connect the agent to the target WordPress, and run the create-site flow — written so someone who has never used Claude Code can follow it.
- In-admin wizard (future) — Planned
The AI Assistant extension drives the whole flow inside wp-admin, so no CLI is needed. A later surface on the same engine.
- Hosted app (future) — Planned
A hosted web app that builds and deploys into the person's WordPress. The biggest surface and the most infrastructure; only once the engine is proven.
Why this, and why now
Prompt-to-site tools are everywhere, and they nearly all produce the same thing: React and Tailwind that a WordPress user then has to rebuild by hand. It looks good in a screenshot and is of no use on the site they actually run.
That gap is the opportunity. Unyson+ already owns the hard parts — a page builder with a real data model, Theme Settings presets, the Header/Footer Builder, and the Animation Engine for motion. A creator that emits our vocabulary produces a page the person can open in the builder and edit on the spot. Nothing is transcribed, nothing is rebuilt. "AI builds it, but you own actual WordPress" is the whole pitch, and the prompt-to-React tools cannot say it.
Four ways in
The creator is one flow with four entry points, so "generate", "convert" and "match this design" are inputs to the same builder rather than separate tools:
| Input | What happens |
|---|---|
| A brief | A plain-language description → a sitemap, a style, archetypes, copy and a palette. The pure fresh-build path. |
| A reference URL | Handed to the capture service and Site Converter for a native build, then refined through the same steps. |
| A design reference | A screenshot or image read into a style and tokens — the look, not the content, logos or layout. |
| A vertical template | An industry starting point (the CRM-generator pattern, generalized) that the creator customizes. |
The principle: native output is the moat
A recipe must emit page-builder JSON + Unyson+ shortcodes + Animation Engine effects, with design tokens applied through Theme Settings presets rather than baked onto each element. That one rule is what separates this from every prompt-to-React tool, and it is also what keeps the output maintainable: change the preset later and every section wearing it changes with it.
It follows that porting an existing prompt library is not possible even in principle — those prompts describe React components. What transfers is the design thinking and the taxonomy: which archetypes matter, and which named looks people actually ask for.
:::caution We take the taxonomy, not the library The public design-prompt libraries are inspiration for categorisation and design direction only. We do not bundle, copy or redistribute any of them: their prompts target React/Tailwind, their preview media sits on someone else's CDN, and their entries carry third-party brand names. Every recipe and every style we ship is authored here, and every preview points at our own demo pages. :::
The style library
A person should be able to say "make the design monochrome" and get it. A style is not a theme file — it is a mapping from a named look to Theme Settings presets (palette, fonts, radius, borders, spacing), the Animation Engine register that fits it (instant vs. cinematic), and the section treatments that express its personality. "Monochrome" becomes a pure black-and-white palette, a serif display face, zero radius, hairline and heavy rules, line textures, and inversion-on-hover — all as presets and shortcode options, not as copied component code.
Several directions already exist as design skills (a refined default, minimalist, brutalist, and a high-end look); a style entry reuses the matching skill where one exists and only carries a new recipe where there is a genuine gap. The picker offers the styles as a choice, with a describe-your-own escape hatch so the set is never a cage. Each style is proved by its demo page (Phase 7): a style is not done until it renders.
Order of work
- The archetype catalogue — the high-frequency sections (heroes, navbars, feature grids, CTAs, footers, marquees) as builder-JSON recipes.
- The style library — named design directions as preset mappings, seeded from the looks people ask for, reusing our aesthetic skills where they fit.
- The composition guide — the sequencing layer, wired onto the existing build protocol (design system first → chrome → sections, region by region → motion → ship gate).
- The create-site skill — the single entry flow with the four inputs, plus the durable build rules (editable output, one universal header/footer, drafts not published until asked, native SEO, no invented proof).
- Content maintenance — research → approve → draft → optimize → approve → publish, two gates.
- Vertical templates — generalize the CRM website generator; the CRM is the first vertical.
- The style gallery — one native Unyson+ demo per style, listed on the demos home.
- Product surface — onboarding for the kit flow now; an in-admin wizard and a hosted app later.
How this page stays current
Status is not ticked by hand. src/data/ai-website-creator-roadmap.json lists every task with a
detect block naming the files that make it real, and scripts/gen-roadmap.mjs checks them against
the AI Dev Kit source tree (the creator lives in the kit, not in an extension):
| Result | Status |
|---|---|
| Every file and symbol found | Done |
| Some found, some missing | In progress |
| None found | Planned |
npm run roadmap:site-creator # scan and rewrite the JSON
npm run roadmap:site-creator -- --dry # report only, write nothing
npm run roadmap:site-creator -- --check # exit 1 if stale
Tasks with no single-file footprint (a principle, a mapping, a gate) are pinned, so the scan leaves them as written.
What this is not
- Not a React or Tailwind generator, and not a port of anyone else's prompt library.
- Not a replacement for the Site Converter — conversion and generation are two entry points to the same builder.
- Not a licence to bundle third-party preview media, prompts or brand names. See the caution above.