Can your skill work with WordPress block design?

[locksmith-unit-orlando-fl]

Hello, I know this is a more technical forum.

I looked at your website, and I noticed that the stack does not show any compatibility with WordPress.
Can it work with WordPress for design purposes?

In general, Claude tends to generate React-based designs by default.
And with your skill it even try to do animations using another library's (Futter, Next.js etc)

Can it also work and design for WordPress (for example default WordPress with Gutenberg blocks), or will it try to include React elements in the output? (I am connecting Claude via an MCP plugin.)

I would appreciate your recommendation.

[mrgoonie]

Summary: The skill can be used for WordPress/Gutenberg design direction, but this repo does not currently ship a dedicated WordPress or Gutenberg stack preset.

Decision: accepted as a useful docs/preset gap; implementation should be scoped narrowly.

Evidence:

• The current data/templates include broad Web guidance and product/style rules, but no explicit WordPress/Gutenberg compatibility preset was found in the repo scan.
• Existing guidance can still steer Claude toward non-React output if the prompt is explicit about the target platform and constraints.

Recommendation / next step:

• For now, tell Claude explicitly: design for WordPress Gutenberg blocks, use semantic HTML/CSS/block markup concepts, avoid React/Next.js components, and avoid animation libraries unless they are WordPress-compatible.
• A good repo improvement would be a dedicated WordPress/Gutenberg stack preset or documentation note so users do not have to rely on prompt constraints alone.

[mrgoonie]

Cron maintainer recheck: issue #367 remains valid as a WordPress/Gutenberg compatibility request, but it overlaps strongly with existing issue #164, which now has clearer WordPress workflow details from the reporter.

Evidence checked:

• Current main still has no WordPress or Gutenberg references in src/, cli/assets/, .claude/skills/ui-ux-pro-max/, README.md, or CLAUDE.md.
• PR search for WordPress Gutenberg block design found no implementation PR.
• Issue search found [Feature Request] - WordPress Functionality! #164 ([Feature Request] - WordPress Functionality!) as the older related request; [Feature Request] - WordPress Functionality! #164 clarifies stock WordPress template customization, Gutenberg/block theme direction, no page builders, optional ACF, and headless React/Next only when explicitly requested.

Useful brainstorm / scope framing:

• Underlying problem: WordPress users need Claude to produce WordPress-native design direction instead of defaulting to React/Next components or incompatible animation libraries.
• Tradeoff: a broad “WordPress support” integration is too large; a narrow Gutenberg/stock-theme preset is reviewable and immediately useful.
• Recommended narrow scope: create one WordPress/Gutenberg stack preset or docs lane covering semantic HTML/CSS, block theme patterns, theme.json/style constraints, ACF-aware layout guidance where relevant, and an explicit rule to avoid React/Next unless the user asks for headless WordPress.
• Risk to avoid: shipping generic web guidance labeled “WordPress” would not fix the problem; it must constrain output toward Gutenberg/block-theme-compatible markup and assets.
• Concrete acceptance evidence needed: source-of-truth stack/docs under src/ui-ux-pro-max/, packaged cli/assets mirrors kept in sync, README/quick guidance mention the WordPress/Gutenberg path, and a smoke query/command proves WordPress guidance prefers Gutenberg/block-theme-compatible output and avoids React/Next/library assumptions unless headless is requested.

Recommendation: keep #367 open as the user-facing question, but treat #164 as the parent/older backlog item for implementation planning to avoid duplicate broad work.

[locksmith-unit-orlando-fl]

Hey @mrgoonie, I saw that you attached a note.

My recommendation would be to focus only on Default Wordpress - Gutenberg. Native WordPress is much better than relying on any costume theme.

By the way, you can achieve almost any design using native CSS with Global Styles or custom CSS, giving you the same result as most paid themes.

I actually think it's better to build on top of default WordPress. It will be lighter, more performance-focused, and, most importantly, much more compatible with future WordPress updates.

The only real challenge is JavaScript-based animations. You can create animations with CSS, but they're limited to simpler effects.

I noticed that someone in your note suggested using your Skill together with a plugin or extension. I think that's a very smart idea, but I also believe it would require a lot of work because you'd need to maintain it on WordPress.org.

Another option would be to collaborate with another MCP-enabled plugin, such as AI Engine. That could solve this issue since it already provides MCP connectivity along with add-ons like Code Engine (snippet plugin).

I hope this information helps. I think adding a dedicated WordPress Skill would take your project to the next level.

Today, many people want the easiest solution. They generate a React website with your Skill, but they often know nothing about React itself. React websites can be difficult to maintain, especially for non-developers.

WordPress, on the other hand, is a massive ecosystem with a huge community. It's much easier to maintain, has excellent long-term compatibility, and isn't going anywhere anytime soon.

I think creating a specialized Skill for WordPress would be a great investment for you.

[mrgoonie]

Thanks — that clarification is useful and it narrows the right path.

I agree the first implementation should focus on default WordPress + Gutenberg/block themes, not custom themes or a WordPress.org plugin. That keeps the maintenance surface much smaller and makes the output useful for non-React users immediately.

Maintainer framing for implementation:

• Scope: add a WordPress/Gutenberg guidance lane or preset for native block-theme output, semantic HTML/CSS, theme.json/Global Styles awareness, and optional custom CSS.
• Explicit non-goal for the first PR: no full plugin, no page-builder integration, no custom theme framework, and no React/Next output unless the user explicitly asks for headless WordPress.
• Animation constraint: prefer CSS-only motion and call out when a requested interaction needs JavaScript.
• Acceptance evidence: source-of-truth guidance under src/ui-ux-pro-max/, packaged cli/assets mirrors kept in sync if required, README/quick guidance mentioning the WordPress/Gutenberg path, and a smoke query proving the skill recommends Gutenberg/block-theme-compatible output instead of React/Next defaults.

So yes: this should be treated as a dedicated WordPress/Gutenberg support improvement, with #164 as the older parent implementation thread and this issue as the user-facing clarification.

[clark-cant]

Maintainer brainstorm (2026-06-26): Scope now narrowed to default WordPress + Gutenberg/block themes only per reporter clarification.

Underlying problem: Claude defaults to React/Next.js/animation-library output even when the user wants WordPress-native design. The skill has no WordPress stack preset to constrain generation toward Gutenberg-compatible markup.

Tradeoff analysis:

• A full WordPress integration (ACF, headless, custom themes) is too broad for a first PR and overlaps with headless React patterns the reporter explicitly does not want.
• A narrow Gutenberg/block-theme preset is reviewable, immediately useful, and avoids scope creep into plugin territory.

Recommended narrow scope:

1. Add a WordPress/Gutenberg stack preset under src/ui-ux-pro-max/data/stacks/ with:
   • Semantic HTML/CSS output rules (no React components, no JSX/TSX)
   • Block theme patterns: theme.json, style.css, templates/, parts/, patterns/
   • Explicit rule: do NOT generate React, Next.js, animation libraries, or SPA toolchain unless user explicitly requests headless WordPress
2. Mirror packaged cli/assets if the CLI requires it
3. Include one minimal block-theme quickstart template as smoke test

Risk to avoid: Shipping generic web guidance labeled 'WordPress' without actually constraining output toward Gutenberg/block-theme-compatible markup. The preset must actively suppress React/Next defaults.

Concrete acceptance evidence needed:

• Generated output includes theme.json, style.css, templates/index.html, parts/header.html
• Generated output does NOT include package.json, JSX/TSX, React imports, Next.js config, Vite/Webpack
• Block patterns use WordPress block markup (wp:group, wp:columns, etc.), not raw div soup

Overlap: This is a focused implementation slice of parent issue #164 (WordPress Functionality). Not a duplicate of #367's original broad question — now narrowed to one concrete deliverable.

Next step for contributor: Implement the narrow Gutenberg/block-theme preset per acceptance criteria above. First PR should be source-of-truth metadata + one minimal template + smoke check.

Posted by github-maintain cron at 2026-06-26T15:23:10Z