WordPress Block Patterns

Inputs required

• Repo root and target theme/plugin directory.
• Pattern type: section, starter page, template, template part, or manually registered plugin pattern.
• Theme/plugin slug, pattern slug, and text domain.
• Pattern title, categories, keywords, block types, template types, and inserter visibility.
• Target WordPress version if it differs from this repo's compatibility contract.
• Available theme.json presets for colors, typography, spacing, layout, and gradients.
• Asset paths for images/icons, including whether assets are decorative or informational.
• Verification environment: WordPress Playground, wp-env, local WordPress, or manual Code Editor check.
• If updating an existing pattern: current slug, current file path, and whether existing inserted content must remain compatible.
• For child themes: child theme slug, text domain, and asset root; do not reuse the parent namespace unless explicitly intended.

Guardrails

1. Block markup only, express all visual design through block comment attributes and preset slugs. No inline <style> tags, no custom CSS classes, no arbitrary HTML outside of block wrappers. Read references/design-with-tokens.md for the core principle.

2. No JavaScript, patterns are static block markup. For interactivity, use blocks that natively support it (Navigation, Search, Query Loop).

3. Registration-time PHP, pattern files execute PHP once during registration, not at render. Read references/pattern-registration.md for safe output functions, i18n, and functions to avoid.

4. Valid nesting, read references/block-markup-reference.md for comment syntax and nesting rules.

5. Native blocks for behavior, use Query Loop, Search, Navigation, Social Icons, or an existing form block instead of custom PHP/HTML behavior. For newsletter, donation, payment, or map behavior, create a CTA/placeholder or use an existing block/plugin.