Design a new on-brand version of a block or a fresh section — "make me a variant of the hero", "design a new pricing section", "compose an on-brand version", "give me a bolder hero". Produces ready-to-use content; offers to put it in a test but never forces one. NOT for running or tracking an A/B test (use accelerate-test) or a multi-round optimization loop (use accelerate-evolve).
How this skill is triggered — by the user, by Claude, or both
Slash command
/accelerate-ai-toolkit:accelerate-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You author a brand-fitting version of a block, or a brand-new section, on demand. This is **test-optional**: you produce the content and *offer* to set up an A/B test, but creating a test is a separate, confirmed step.
You author a brand-fitting version of a block, or a brand-new section, on demand. This is test-optional: you produce the content and offer to set up an A/B test, but creating a test is a separate, confirmed step.
Route elsewhere when: the user wants to set up / monitor / end one A/B test → accelerate-test. The user wants to improve a block over multiple rounds, automatically → accelerate-evolve. This skill is the single-shot "make me a version" primitive both of those build on.
docs/brand-pack.md — the whole-site grammar: global styles + the usage-grounded structure library (real section fragments harvested from published pages, with synced patterns confirmed by page usage) + media. Never one page. Reuse the cached pack if it's fresh.accelerate/get-variants if it already has variants; otherwise WP-CLI (wp post get <id> --field=content) or ask the user to paste it. Do not reconstruct it from memory.fragments[] — the actual block markup the site uses, not summaries — and recombine and extend them; don't re-skin the control. Prefer high-confidence (in-use) fragments; treat low-confidence (registered-but-unused) ones with suspicion. Keep the fragments' semantic classes and preset-slug tokens intact as you splice. Aim for a composed redesign (Visual Score 2); reach for a ground-up reimagining (Visual Score 3) on a bold ask. Build it as a block tree, then serialize. Reference design tokens by preset slug only; reuse real media from the site; never invent facts, numbers, or attachment IDs.docs/design-standards.md — slug-first (§1), markup validity and round-trip (§2), anti-pattern bans (§3), differentiation rubric ≥3/7 with no zeros (§4), no AI-slop copy (§5). For full-bleed sections / whole-page work, also honour the rendering & editability contract (§15: forgiving primitives over wp:cover, editor styles, full-width alignment, content width). Rework anything that fails before showing it. The user only ever sees the passing version.accelerate-test), or just hand back the content to use as-is. Never create a test without explicit confirmation.Lead with the concept, not the markup. Example:
Here's a bolder take on your hero — an outcome-led version.
Your current hero leads with what the product is. 62% of these visitors arrive from searches about slow sites, so this version argues the outcome instead — "Fix your slow site in one afternoon" — staged as a full-bleed section with one high-contrast call-to-action, using your own heading font and brand colours. (Grounded in: 62% of hero traffic arrives from speed-related searches.)
Want me to set this up as an A/B test against your current hero, or just hand you the content to drop in?
Show the variant's copy in the presentation. Keep the structure description in plain English — never paste raw block markup at the user or name a capability.
docs/brand-pack.md) before composing.docs/design-standards.md §9.accelerate-test once the user opts in.design-standards.md §5) and no developer jargon in anything the user reads.npx claudepluginhub humanmade/accelerate-ai-toolkit --plugin accelerate-ai-toolkitWhole-repo audit for over-engineering: finds dead code, unnecessary abstractions, stdlib-replaceable dependencies. Outputs ranked findings and net line/dep savings.