How to Design an Adobe Commerce Theme with Claude (Page Builder, PWA, and B2B)

What designing an Adobe Commerce theme with Claude means

Adobe Commerce is the paid, enterprise edition of Magento. It shares the same core theme system, so everything that works for a Magento theme works here too, but it adds enterprise features you can also design with Claude: Page Builder, B2B, content staging, and a managed cloud deploy pipeline. Designing an Adobe Commerce theme with Claude means using Claude as a fast front-end engineer that produces the layout XML, PHTML templates, styles, and Page Builder content that make up a real, upgrade-safe theme.

The value is the same as with Magento: you set the design direction and Claude produces maintainable, structured output. The difference is the extra enterprise surface, and being explicit about it is what keeps the code usable, which is exactly how our eCommerce development work is scoped.

How Adobe Commerce differs from Magento Open Source

Tell Claude which edition you are on, because these enterprise features change what you should generate:

• →Page Builder: a drag-and-drop content tool where marketers build pages from content types, so your theme should style Page Builder output, not fight it.
• →B2B module: company accounts, shared catalogs, quotes, and requisition lists that need their own templated pages.
• →Content staging and preview: schedule design and content changes with a future go-live, so themes must render cleanly in preview.
• →Adobe Commerce Cloud: a managed, git-based hosting pipeline with integration, staging, and production environments.
• →Commerce-only extension points and Adobe Sensei personalization blocks that a theme may need to place.

The theme folder structure to work in

Name this structure in your prompt so Claude returns files that slot straight into an Adobe Commerce project:

• →app/design/frontend/Vendor/theme/: the root of your custom theme
• →theme.xml and registration.php at that root, declaring the theme and its parent
• →Magento_Theme/layout/ and other Module/layout/ folders for layout XML overrides
• →Magento_Theme/templates/ and Module/templates/ for PHTML overrides
• →web/css/ for LESS, or web/tailwind for Hyva, plus web/js for JavaScript
• →Content type definitions for Page Builder when you extend or restyle the drag-and-drop content types

Luma, Hyva, or PWA Studio: which frontend to build on

This choice shapes everything Claude generates. Luma is the default server-rendered theme: widely installed but heavy, with Knockout.js and LESS. Hyva is a modern Tailwind and Alpine frontend that is far lighter and much easier for an AI to generate clean, fast code for. PWA Studio is Adobe's headless React storefront that talks to Commerce over GraphQL, a very different build.

If you want the fastest maintainable build and can license Hyva, build on Hyva and ask Claude for Tailwind and Alpine components. If you are extending an existing Luma store, ask for Luma-compatible LESS and Knockout. If you are going headless, ask Claude for React components and GraphQL queries against the Commerce schema. Pick one and say so up front.

Step 1: Write an Adobe Commerce design brief

Claude produces far better output when the brief is specific. Give it your brand colours and hex values, fonts, the page types you need (home, category, product, cart, checkout, and any B2B pages), your Adobe Commerce version, whether you are on Luma, Hyva, or PWA Studio, and whether marketers will build pages in Page Builder.

State the constraints clearly: build as a child theme that overrides only what changes, keep it upgrade-safe, do not modify core, and make sure Page Builder content still renders correctly inside the new theme.

Step 2: Generate themes, Page Builder content types, and styles

Work area by area rather than asking for the whole theme at once. For each page type, ask Claude for the pieces that work together:

• →The layout XML that places or restructures blocks and containers for that page type.
• →The PHTML template that renders the markup, pulling data from the block or view model rather than hard-coding it.
• →The styles, Tailwind on Hyva or scoped LESS on Luma, kept in the theme's web folder.
• →Page Builder styling so marketer-built rows, banners, and sliders match the theme instead of clashing with it.

Step 3: Deploy safely on Adobe Commerce Cloud

Adobe Commerce Cloud is git-based, which makes safe deploys the default if you follow the pipeline. Never edit the live theme or core in place:

• →Commit the child theme to your branch and push to the integration environment, where the pipeline builds it.
• →Promote to staging and run setup:upgrade if you added a theme, then setup:static-content:deploy to compile assets.
• →Flush the cache with cache:flush so changes actually appear, and verify content staging previews render correctly.
• →Promote to production during a low-traffic window with a rollback plan, since Cloud lets you redeploy the previous build fast.

Step 4: Test, QA, and go live

Before go-live, check every page type on desktop and mobile: home, a category with filters, a configurable product, cart, checkout, and any B2B pages like company accounts and requisition lists. Confirm add-to-cart, search, and checkout work, and that Page Builder content renders as designed.

Run a performance and accessibility pass. Hyva and PWA Studio should score very well on Core Web Vitals; Luma needs more care with image sizes and JavaScript. When it passes on staging, promote to production. If anything breaks, redeploy the previous build or revert the theme in Design Configuration.

Common Adobe Commerce pitfalls to avoid

A few mistakes turn a smooth Adobe Commerce theme build into a broken storefront:

• →Editing core or the parent theme instead of a child theme, which breaks upgrades and future patches.
• →Ignoring Page Builder, so marketer-built content clashes with the theme after launch.
• →Skipping static content deployment or cache flush, so your changes never show up.
• →Assuming the wrong frontend: writing Luma code for a Hyva store, or server templates for a headless PWA build.
• →Testing only B2C pages and missing B2B accounts, shared catalogs, and content staging previews.