Sharing an Bricks skill — built from actually using it on a real site

Uncategorized
1

Started with the official Bricks skill from CodeerHQ. Good starting point, but when I ran an AI agent against a production site, I kept hitting the same kind of silent failures — things that look fine in the builder but break quietly on the frontend.

A few examples:

  • Agent generates fake link attributes instead of using Bricks’ native link field — renders as <a> in HTML, looks correct, but Bricks’ own link system never kicks in.
  • Theme Styles settings end up in the wrong structure. Bricks silently ignores them — no error, no CSS output.
  • The same stylesheet gets copy-pasted into every inner page. 12 pages of identical CSS that should live in one place.
  • WP-CLI Abilities calls come back 403 for no obvious reason.

None of these throw errors. You only notice if you go looking.

So I extended the skill with rules that came out of fixing these issues — now covering 25+ Bricks subsystems and 16 ready-to-paste JSON patterns.

:backhand_index_pointing_right: GitHub - bboyfan/now-bricks-skill · GitHub

Inspired by wpgaurav/bricks-skills and codeerhq/bricks-skills. Happy to hear if others have hit similar issues.

1 Like
2

Thanks for writing these up. The ‘looks right in the builder, breaks on the frontend’ class of failure is what makes agent edits risky on production. A few rules that could catch more of these: have the agent verify every change by fetching the rendered frontend HTML and CSS instead of trusting the saved builder JSON, run it against a staging copy and diff the post meta and options before and after, and require it to read the existing Theme Styles or global class structure before writing to it. That last one should catch most of the silently ignored settings. Disclosure: we’re building Tado Studio, which takes a different route (Astro sites as plain files, with the code shown next to the visual editor), so we can’t speak to Bricks internals beyond what’s in your post.