The save worked. The site didn’t.
Tired of your agent reporting success while the page looks the same, the colors never changed and the headline showed up in Impact? For WordPress sites built on Bricks Builder, Automatic.css and SureCart, the WordPress Pack makes it check the live site, the stylesheet and the font the browser drew before it tells you it’s done. Running SureContact or OttoKit on the site too? Their skills are in the App Stack Pack.
$39. Every pack, now and later: $149.
Works with
Fit check
Not sure which pack fits? Find yours in two questions
Every requirement, in detailSound familiar?
Tap every one you’ve lived through.
Nothing yet? Lucky you.
Why it keeps happening
Bricks and Automatic.css accept what they’re sent and answer success, whether or not it will render. So the agent reads its write back, finds what it sent, and reports done. The mistake turns up later, on the live site.
So you become the check. You open the site logged out, find the headline in a fallback font or the old colors still there, and explain it again. And a Bricks write through an agent keeps no revision, so undoing it is on you.
What the dashboard showed
The brand hex, saved. The swatch showed the new color, and every imported setting read back correct.
What the site served
--primary: oklch(0.664 0.107 221), the install default, was still in the generated CSS.
The fix
The WordPress Pack is two skills your agent loads and scripts it runs before it tells you it’s done. One names the ways Bricks, Automatic.css and SureCart fail without an error, what that silence looks like, and what to measure instead. The other puts every sign-in screen on brand, the Fortress security plugin’s pages included, and proves the live page serves your current file.
The agent reads the rendered page, the generated stylesheet and the font the browser drew, not the settings row or the success message.
The page reviewer, the font checker and the Fortress theme checker ship self-tests with planted defects, and the pack’s two harnesses break a copy of each script on purpose to prove the checks notice.
Templates stay behind conditions until launch, every Bricks write is backed up first, and each write is read back and compared by hash in a separate call.
Proof
Three real runs of the download. Two self-tests plant known defects and must catch every one; the third gives the font checker a headline set in a brand face nothing declares, and it must fail it.
[ Shot 01 ]
page-review.mjs --selftest
Aimed: one planted defect per check; each must be caught
ok planted page: findings counted, no control failed, exit 1
ok clean page: 0 findings and exit 0, with contrast and both orphan passes measuring something
ok broken detector (min-words 6): the control fails, the run says so, exit 3
42 cases behaved as designed
Landed where it was aimed // exit 0
[ Shot 02 ]
font-check.mjs --selftest
Aimed: a font no @font-face declares; the check must fail it
ok an undeclared family fails
ok document.fonts.check said the undeclared family was available (the reason this tool exists)
ok a declared face whose file 404s fails
31 cases behaved as designed
Landed where it was aimed // exit 0
[ Shot 03 ]
font-check.mjs --probe h1
Aimed: a headline in a brand face nothing declares; the check must fail it
FAIL h1 css "Brand Display"
"Brand Display" does not render on this page: text set in it alone fell back to Times / Times-Bold (system). No @font-face declares it and no installed font has that name. Element drawn with Impact / Impact (system)
document.fonts.check said available (not evidence either way)
1 finding(s)
Landed where it was aimed // exit 1
Who it’s for
Two skills, one job each. Start with the one for the part you just changed.
wordpress-skills.mjs
ok wp-preview.php destroys the session token when the fetch throws
ok surecart-buy-page-dark.php puts the dark class on the sc-buy-page context only (priority 20; checkout and a lookalike class keep the light one)
wordpress skills: clean (66 checks)
wordpress-skills.mjs
ok wp-preview.php destroys the session token when the fetch throws
ok surecart-buy-page-dark.php puts the dark class on the sc-buy-page context only (priority 20; checkout and a lookalike class keep the light one)
wordpress skills: clean (66 checks)
Changes to a Bricks site land where you meant and nowhere else. New templates stay hidden until launch, every write gets a backup first, and every write is read back before anyone calls it done. The colors, fonts and layout a visitor gets match what you set, and SureCart’s light panels, instant checkout and customer dashboard take the site’s dark palette.
check-fortress-theme.mjs --selftest
ok no theme link is a finding naming the top-level key and the reload
ok a 200 HTML catch-all is "not CSS", not a pass
ok different served bytes are "stale" with the bump-and-reload fix
selftest: 12/12 passed, 0 skipped
WordPress’s log-in, lost-password and logged-out screens, and the Fortress security plugin’s two-factor and magic-link pages, in the site’s own design, from one set of colors and fonts. A checker proves the live Fortress page serves the file you just changed, not a CDN’s older copy.
Two skills, each with its job in one line: six references and fifteen scripts, every rule graded measured, observed or documented, and dated.
wordpress-bricks-stack
Bricks, Automatic.css and SureCart through an MCP server: staged, backed up, and reviewed as a visitor sees it.
wordpress-login-screens
WordPress’s log-in screens on any theme and the Fortress security plugin’s two-factor pages, in one look, with proof the live page serves your current file.
One download: the skills your agent reads, Node checks that run on your computer, and PHP snippets that run inside your WordPress, not on your machine.
wordpress-pack/
Unzip it anywhere. install.sh copies the skills into ~/.claude/skills/ and moves any folder with the same name aside instead of overwriting it. .claude-plugin/ lets Claude Code load the whole pack as a plugin instead.
ci/verify.sh is the full check, run inside the pack: the skills present, every script parsing, the installer non-destructive, and two harnesses that break copies of the scripts on purpose. On a fresh unzip, with Playwright and PHP installed, every check passed and none was skipped.
A check that has never failed is a green light with extra steps. Every check here ships a self-test that plants the mistake it exists to catch. Run it first: if it calls the planted mistake fine, don’t trust it on your live site either.
Run the self-tests
# run from a project that has playwright, with the WordPress Pack unzipped at /path/to/wordpress-packnode /path/to/wordpress-pack/skills/wordpress-bricks-stack/scripts/page-review.mjs --selftest # plants one defect per check and must catch eachnode /path/to/wordpress-pack/skills/wordpress-bricks-stack/scripts/font-check.mjs --selftest # a family nothing declares and a font file that 404s must both failPERF_PROJECT=$PWD node /path/to/wordpress-pack/ci/wordpress-skills.mjs # breaks a copy of each script, and each broken copy must fail its selftestnode /path/to/wordpress-pack/skills/wordpress-login-screens/scripts/check-fortress-theme.mjs --selftest # a missing link, a stale copy and a 200 HTML catch-all must each failWe call these negative controls: a planted defect the check has to fail on. The first plants one defect per page check and breaks the orphan detector on purpose; the second plants a family nothing declares and a font file that 404s; the third breaks a copy of each Bricks script, and each test must go red; the fourth serves the Fortress checker a missing link, a stale copy and an HTML page where its stylesheet should be, and must report each one.
The check that has never failed is the one to distrust.
The skills are plain text your agent reads. The Node scripts run on your computer; the PHP snippets run inside your WordPress, and only when you put them there.
claude --plugin-dir /path/to/wordpress-packThe written skills need nothing at all. The scripts need Node 18 or newer, and the page reviewer and font checker need Playwright in your project:
npm i -D playwright && npx playwright install chromiumCommented scripts, and nothing compressed into a blob. A product that says “don’t trust a report you can’t read” has to be readable itself.
WordPress Pack
$39.
Please don't resell it or share it outside your company.
All-Access Bundle
Spotter Round, the Agent Setup Pack, the Email Pack, the WordPress Pack, the App Stack Pack and the Campaign Tracker Pack, plus every pack added after them, each with every future version.
Spotter Round if an agent writes your web pages: it proves the work before and after it ships. The Agent Setup Pack if you use more than one agent or more than one tool, or hand agents API keys. The Email Pack if you send HTML email. The WordPress Pack if you build on WordPress with Bricks. The App Stack Pack if you build web apps on Cloudflare Pages, Supabase or Stripe, or use SureContact or OttoKit on any site, WordPress included. The Campaign Tracker Pack if you run ads and want short links, leads, purchases and cost per lead tracked from the server, on any site behind Cloudflare. The All-Access Bundle is every pack, now and later, for less than the six together.
Yes. The skills are plain text files and the checks are plain Node scripts, so any agent can run them. Claude Code loads the skills from its skills folder. Codex, Cursor and the rest take a skill pasted into your repository's AGENTS.md, and Gemini CLI reads that file once its settings name it.
Not on its own. The page, font and Fortress checks only read the pages they load, and the PHP snippets run only when you paste them into your WordPress or add them to your child theme. The Bricks skill also has your agent stage templates behind conditions, back up before every write, and check a public page logged out after every template write.
No. It was written against a WordPress MCP server exposing the Abilities API, and it has your agent list what your own server exposes before relying on any of it. Without a PHP-execution ability, the snippets run through WP-CLI instead.
No tracking, no license check, no analytics, nothing phoning home. The scripts load only the page you point them at, and the Fortress checker the stylesheet that page links; the PHP snippets run only inside your WordPress, where you put them. You can confirm that yourself: the scripts are commented, and meant to be read.
More than you paid for: everyone who bought Spotter Round before version 2 gets the All-Access Bundle, every pack now and every pack we add later.
Numbered downloads with a list of what changed. More WordPress tooling is on its way, and every future version of the WordPress Pack is included at no charge, so you never pay for a new version, and you are never forced to update.
Yes — that's what it's for. One company covers every project that company delivers.
Fourteen days, no questions. A product about checking things that argued with you over a refund would be a poor advertisement for itself.
Sold separately
Each pack is sold on its own and ships its own checks, the same way this one does.
The layout, the pixels, the speed and the live deploy: your agent’s work, proven before it says it’s done.
One set of rules, proven to reach every coding agent, several agents on one project without landing work on each other's branches, and API keys handed over without entering the chat.
HTML email that survives real inboxes, dark mode and all, sent by Postmark, SureContact or anything else, and every Supabase Auth email from one generator.
Cloudflare Pages, Stripe billing on Supabase, passkey sign-in on Supabase Auth, SureContact and OttoKit: the web-app stack, proven rather than assumed.
Campaign tracking set up the same way for every client: short links from a Google Sheet, first-touch UTM tags without cookies, leads and purchases sent to Meta from the server, and cost per lead in one sheet.
Every pack, now and later: web pages, several agents, email, WordPress, web apps and campaign tracking.
The six separately: $234