A factory for WordPress static site implementations, generated by Data Machine in Homeboy-powered GitHub Actions and validated by Homeboy in CI. Sites can be commerce-shaped (WooCommerce storefronts) or content-shaped (blogs, local business sites, portfolios, professional services, nonprofits, etc.). Commerce is one supported profile, not the identity of the repo.
The repo knows about WordPress. The generation agents inside it do not — they describe real-world businesses, websites, designs, and static HTML, and never mention WordPress, themes, blocks, or import tooling. The WordPress-aware lane lives in CI workflows, the Homeboy/Static Site Importer integration, and the transformer iterator.
Ideas live as GitHub issues. Static sites arrive as pull requests: raw HTML/CSS/assets that are imported through Static Site Importer in Homeboy CI, with metrics, visual parity artifacts, finding packets, and a Playground preview posted back as review evidence.
Concurrency is the strategy. The system is designed to produce many credible starting points fast, not one perfect site slowly.
Volume over perfection. If a hundred sites land in a day, the cost of any individual one being wrong is small, and the cost of finding a good one is just clicking a link.
+---------------------+ +-----------------------+
| store-idea-agent | | website-idea-agent |
| (commerce lane) | | (content lane) |
+----------+----------+ +-----------+-----------+
| |
v v
opens GitHub issue
status:idea-ready
site-kind:<commerce|content>
commerce:<woocommerce|none>
industry:<axis>
|
v
+---------+----------+
| design-agent |
| (palette / type / |
| layout / mood) |
+---------+----------+
|
v
opens design-direction issue
with source issue metadata
toggles label: status:idea-ready
-> status:design-ready
|
v
+---------+----------+
| static-site-agent |
| (raw HTML/CSS site |
| for the concept) |
+---------+----------+
|
v
PR with static source files
branch: static/<slug>
label: target:<wordpress|woocommerce>
|
v
Homeboy WordPress extension
runs Static Site Importer
against the PR in CI
(PHP-WASM + SQLite, no host,
no browser required)
|
v
PR comment with metrics
+ visual parity artifact
+ Playground preview link
+ import-report.json artifact
+ finding-packets.json artifact
|
v
+---------+----------+
| php-transformer- |
| iterator-agent |
| (upstream fixes or |
| fallback issues) |
+--------------------+
|
v
+---------+----------+
| ssi-stack-reviewer |
| agent |
| (upstream PR gate) |
+--------------------+
Every layer is intentionally generic on its own:
- Data Machine doesn't know about WooCommerce.
- The agents don't know they run on WordPress, or how their output will be reviewed or imported.
- The flows don't know about validation.
- Homeboy WordPress extension doesn't know about Static Site Importer.
- Static Site Importer auto-detects whether the input is a content site or a Woo store from the input data; it does not branch on a flag.
- Playground doesn't know about Homeboy.
- The iterator doesn't know about generated-site strategy; it consumes validation findings and routes upstream transformer gaps.
This repo is the only place all of them meet.
This repository is the orchestration and generated-site source repo. The working system spans these repos:
chubes4/wp-site-generator— concept issues, Data Machine bundles, generated static-site PRs, validation workflows, and iterator dispatch.Extra-Chill/data-machine— agent runtime, bundles, flows, pipelines, chat/step execution, and GitHub handler integration.Extra-Chill/data-machine-code— workspace, worktree, GitHub, and PR tooling used by agents that edit code.Extra-Chill/homeboy— local and CI quality runner used to execute repo checks and WordPress benches.Extra-Chill/homeboy-action— GitHub Action wrapper that runs Homeboy in repository workflows.Extra-Chill/homeboy-extensions— reusable WordPress Playground workloads, Data Machine agent CI workflow, validation reporting, and iterator plumbing.chubes4/static-site-importer— WordPress plugin that imports each generated static site into a block theme.chubes4/html-to-blocks-converter— HTML-to-block transformer used by Static Site Importer.chubes4/block-format-bridge— block serialization/format bridge used by the import pipeline.WordPress/wordpress-playground— PHP-WASM WordPress runtime used by validation and preview links.
The generated-site PR is only one artifact in the loop. Validation output can produce upstream PRs or issues in the importer and transformer repos, then the generated-site PR is revalidated against the improved stack.
The agents are narrow on purpose.
Implemented as two focused bundles:
store-idea-agentwebsite-idea-agent
Reads the recent issue corpus, picks the strongest distinct commerce store concept inside the industry the flow specifies, and files a status:idea-ready issue. Industry / problem space lives on flow user messages; flow labels carry the site-kind:, commerce:, and industry: axes. Ships eight industry-tuned flows plus a manual flow.
Issue body sections: Recommended Concept, Who It Serves, What It Offers, Why It Could Work, Issue Overlap Check, Next Step.
Same shape, different lane. Generates non-commerce website concepts (blog, local business, portfolio, professional services, nonprofit). Ships a manual flow plus focused local business, blog, portfolio, professional services, and nonprofit flows. Concepts whose core is an online storefront are excluded from this agent — they belong to the store agent.
The bridge between the idea agents and the build agent. Reads one open status:idea-ready source concept issue, decides one visual design direction (palette, typography, design system, layout direction, mood), opens a separate design-direction issue containing source issue metadata plus a fenced json block, and toggles the source concept from status:idea-ready to status:design-ready. Does not edit the source concept title/body. Does not write code. Does not open PRs. Does not pick slugs. The design issue's field set is the agent's call per concept; there is no rigid schema beyond source issue/title metadata and parseable design JSON.
Reads one open status:design-ready source concept issue plus the separate design-direction issue recorded by the design task, then authors a static HTML/CSS site PR. The source concept remains the identity contract: PR title, branch, static-site directory, and Closes #... derive from the concept issue, not the design issue. Files live under static-sites/<slug>/. The exact set of files is the agent's call based on what the design needs; there is no required file list and no forbidden file list. PRs open with target:wordpress for content concepts or target:woocommerce for commerce concepts. Validation happens in CI.
PR title shape: 🧱 <Concept Name> — static site. Branch: static/<slug>.
Consumes grouped SSI finding packets from a generated-site PR's validation run and routes each actionable finding to the owning upstream transformer repo (static-site-importer, html-to-blocks-converter, or block-format-bridge). It opens a focused upstream PR when the evidence is patchable, opens a fallback upstream issue when human narrowing is safer, and comments back on the generated-site PR with the upstream action. It is a repair loop for importer/transformer gaps, not a site-generation agent.
Reviews an upstream iterator PR before merge or promotion. It consumes the upstream PR URL plus finding-packet context and leaves a review/comment on that PR. It checks owner repo, generic transformer behavior, SSI layer purity, generator-specific leakage, regression coverage, and bootstrap-helper patches. It does not repair findings, open PRs, create issues, or duplicate the iterator role.
| Label | Meaning |
|---|---|
status:idea-ready |
An idea agent published a concept; design has not been picked yet. |
status:design-ready |
The design agent created a separate design-direction issue for the source concept; the build agent can pick it up. |
status:built |
A target-lane PR currently claims the concept or the generated-site PR has merged and closed it. |
status:abandoned |
The most recent target-lane PR for this concept closed without merging and no other open target-lane PR still claims it. |
target:wordpress— content-shaped sites imported into WordPress.target:woocommerce— commerce-shaped sites imported into WordPress with WooCommerce available.
site-kind:commerce,site-kind:contentcommerce:none,commerce:woocommerceindustry:food-beverage,industry:home-craft,industry:outdoors-field,industry:apparel-accessories,industry:music-audio,industry:health-body,industry:pet-animal,industry:print-paper-stationery,industry:local-business,industry:blog,industry:portfolio,industry:professional-services,industry:nonprofit
Idea flows publish issues with status:idea-ready plus the relevant site-kind:, commerce:, and industry: axes set.
Static-site PRs trigger a Homeboy CI workflow that:
- Boots WordPress Playground inside GitHub Actions.
- Installs Static Site Importer and WooCommerce via
wp_codebox_blueprint. - Runs
wp static-site-importer import-themeon the PR'sstatic-sites/<slug>/index.html. - Captures a Playwright visual parity comparison between the source static HTML and imported WordPress result.
- Reads the resulting
import-report.jsonand emits importer metrics + the report itself as a Homeboy bench artifact. - Builds
finding-packets.jsonfor actionable importer, block, and visual parity failures. - Posts a PR comment with the metrics, visual parity status, and a Playground preview link that re-imports the site live in the reviewer's browser.
- Dispatches the PHP transformer iterator when actionable finding packets exist.
This whole loop runs without a hosted WordPress site. PHP runs as WebAssembly in CI; the database is SQLite. The Playground preview link the reviewer clicks does the same import in their browser.
The PR target label gates validation. target:wordpress marks content-shaped WordPress imports; target:woocommerce marks commerce-shaped imports. The current validation harness installs WooCommerce in the Playground environment for both lanes, so the target label is selection and review metadata rather than the only place WooCommerce is introduced. The build agent still emits static source files; CI owns the WordPress import context.
The Homeboy WordPress extension capability that makes this possible (wp_codebox_workloads) is generic. SSI is just one consumer; any WordPress plugin can be exercised the same way in CI. The validation workflow refreshes the reusable harness scripts from origin/main before running, so older generated-site branches get the current validation behavior without rebasing their source files.
- Idea agents publish a buildable concept directly instead of spending turns on corpus analysis.
- Prompt-level variety keeps concepts specific without trying to enforce global uniqueness.
- Adjacent but differentiated ideas are acceptable when the audience, offer, place, product angle, or site shape differs.
Prompt-level variety keeps the generator moving. Stronger duplicate prevention should be deterministic, ideally through Data Machine processed-item/idempotency machinery, rather than asking the model to police the corpus.
wp-site-generator/
README.md
homeboy.json Homeboy config: WordPress extension + base wp_codebox_blueprint
.github/
workflows/
static-site-validation.yml SSI import, visual parity, findings, iterator dispatch
site-generation-loop.yml end-to-end idea -> design -> static-site PR loop
playground-stage-5.yml Data Machine idea-agent proof in Playground CI
php-transformer-iterator.yml upstream transformer repair loop from findings
ssi-stack-reviewer.yml review-only gate for upstream iterator PRs
bundles/
store-idea-agent/ Data Machine bundle: commerce concept generation
website-idea-agent/ Data Machine bundle: non-commerce concept generation
design-agent/ Data Machine bundle: visual design direction
static-site-agent/ Data Machine bundle: static HTML/CSS implementation
php-transformer-iterator-agent/ Data Machine bundle: upstream transformer fixes
ssi-stack-reviewer-agent/ Data Machine bundle: upstream PR review gate
static-sites/ generated raw HTML/CSS sites for SSI validation
<slug>/
index.html
assets/styles.css
... agent's call: any files that faithfully implement the design
resources/ reusable theme bases / shared assets
scripts/ optional dev helpers
The agents are portable Data Machine bundles. Six focused bundles are tracked here.
You don't need any of the agent infrastructure to review a generated site. From a PR:
- Inspect the generated static site files or artifact linked from the PR body.
- Review the Homeboy/SSI metrics, visual parity artifact, import report, and finding packets posted by CI.
- If validation found importer/transformer gaps, follow the iterator callback to the upstream PR or fallback issue before judging the generated site itself.
- For upstream iterator PRs, run
ssi-stack-reviewer.ymlwith the upstream PR URL and finding-packet context before merge or promotion. - If you like it, merge the PR. The source idea issue auto-closes via
Closes #<issue>and remainsstatus:built. - If it misses the concept or design, close the PR without merging. If no other open target-lane PR still claims the idea, the lifecycle workflow moves the issue to
status:abandoned; reopen the issue to return it tostatus:idea-readyfor another pass.
That's the loop. Generate. Design. Build. Validate. Review. Decide. Repeat.
The primary loop runs in GitHub Actions through homeboy agent-task run-plan. The workflow builds a Homeboy plan with output-driven DAG phases, runs the Data Machine bundles through the WordPress Codebox agent-task provider, and writes GitHub issues or PRs back to this repo with the workflow GITHUB_TOKEN.
Required GitHub secrets:
OPENAI_API_KEY
Useful workflow entry points:
store-idea-agent.yml— manually generate one commerce concept issue from a prompt.website-idea-agent.yml— manually generate one content concept issue from a selected website flow.design-agent.yml— attach a design direction to one issue.static-site-agent.yml— build one design-ready issue into a static-site PR.site-generation-loop.yml— run the current two-lane end-to-end loop with Homeboy agent-task output dependencies: store idea, website idea, design both, build both.static-site-validation.yml— automatic PR validation for labeled target-lane static-site PRs.php-transformer-iterator.yml— automatic or manual upstream repair loop from validation finding packets.ssi-stack-reviewer.yml— manual review-only gate for upstream iterator PRs before merge or promotion.
Local Studio remains useful for bundle development or manual runtime experiments. A local host needs:
- Data Machine + Data Machine Code plugins active.
- A GitHub credential profile in DMC scoped to this repo with
Contents,Issues, andPull requestswrite access. - An AI provider configured (today: OpenAI, model
gpt-5.5). - The bundles imported and pointed at
chubes4/wp-site-generator.
Install or refresh a bundle:
studio wp datamachine agent install bundles/store-idea-agent
studio wp datamachine agent install bundles/website-idea-agent
studio wp datamachine agent install bundles/design-agent
studio wp datamachine agent install bundles/static-site-agent
studio wp datamachine agent install bundles/php-transformer-iterator-agent
studio wp datamachine agent install bundles/ssi-stack-reviewer-agent
Run a flow manually:
studio wp datamachine flow run <flow-id> --drain
Each agent ships with a default manual flow. The store idea agent additionally ships industry-tuned commerce flows; the website idea agent ships focused content flows for local business, blog, portfolio, professional services, and nonprofit concepts. Add more by dropping new flow JSON into the relevant bundles/<agent>/flows/ directory and reinstalling.
There is no auto-merge step. Merging is a human decision, and generated-site PRs are only mergeable when the imported WordPress result is clean enough to accept: zero fallback blocks and exact visual parity are the bar, not merely "CI produced a preview."
- Keep generated sites as raw static source PRs.
- Keep WordPress import, visual parity, and diagnostics in CI.
- Convert actionable failures into compact finding packets.
- Let the PHP transformer iterator open focused upstream fixes or fallback issues.
- Gate upstream iterator PRs with the SSI stack reviewer before merge or promotion.
- Re-run the generated-site PR against the improved importer stack until the WordPress result is reviewable.
The repo exercises both sides of the loop: generation and validation in CI, plus upstream repair from validation evidence.