IGD standards are the same on every build: the breakpoints, the Style Manager settings, the token names, the structure of the IGD Base theme style and the utility classes. Don’t change them on a client site. If one of them should change, tell the core team so the Sandbox is updated for everyone.

Client slots are what you set for each project: the five colors, the two fonts and, when the design needs it, the text and space scale settings.

Breakpoints: Desktop 1440 (base) · Laptop 1024 · Tablet 768 · Mobile L 425 · Mobile S 375. Bricks is desktop-first: style the desktop view first, then adjust at smaller breakpoints. Each breakpoint’s styles apply at its width and below.

Whenever a Bricks control accepts a value, pick a variable instead of typing pixels or hex codes. When the design changes, the whole site follows.

• Colors: --primary, --secondary, --accent, --dark, --light. Each brand color also has -l-1 (lighter), -d-1 (darker) and -t-1 (transparent). Color classes such as .bg-primary and .text-primary are available too.
• Text sizes: --text-xs to --text-3xl. Body text is --text-m.
• Spacing: --space-xs to --space-3xl.
• Layout: --gutter (the side padding every section uses) and --flow-space (the gap the flow class adds).
• Radius: --radius-s, --radius-m, --radius-l, --radius-full.
• Shadows: --shadow-s, --shadow-m, --shadow-l. Bricks’ box-shadow control can’t take a variable, so apply them with the shadow-s, shadow-m and shadow-l classes.

Text sizes and spacing are fluid: they grow smoothly from 360px to 1440px screens, so you rarely need breakpoint-specific values for them.

Add these as global classes on an element (Style › CSS › CSS classes). They cover the common layout patterns so you don’t rebuild them on every site.

• grid-2, grid-3, grid-4: equal columns with a --space-m gap. grid-3 and grid-4 drop to 2 columns at Tablet, and all three drop to 1 column at Mobile L.
• stack: stacks children vertically with a --space-m gap.
• cluster: a wrapping row of items such as tags, buttons or icons, with a --space-s gap.
• section-s, section-l: tighter or roomier top and bottom padding on a Section. The side gutter stays the same.
• text-center: centers text.
• text-balance: evens out the line lengths of a heading.
• flow: adds space between stacked content, such as paragraphs and lists in a text column.
• visually-hidden: hides text on screen but keeps it for screen readers.
• link-overlay: put it on a card and the card’s link covers the whole card. Use one link per card.
• shadow-s, shadow-m, shadow-l: apply the three shadow tokens.

This Sandbox ships with one theme style, IGD Base, applied to the whole site. It connects Bricks’ defaults to the tokens: body and heading typography, H1–H6 sizes, link and button colors, section padding and container width. Set the fonts in it (setup step 3) and leave the rest alone: it already follows the colors and scales you set.

Page Settings (Bricks editor › Settings › Page Settings) control how a single page behaves: a page-specific background, turning off site-wide popups on that page, extra body classes and so on. Check them before you start a page layout.

Templates are powerful, but you don’t need them for the whole build. With IGD Base handling site-wide styling, every regular page can be built directly on the page itself (Pages › Edit with Bricks). That keeps content where editors expect it and makes updates simple.

Use templates for headers, footers, single-item layouts for custom content (Pods), posts and products, and sections repeated across pages such as sidebars, modals and off-canvas panels. Anything driven by dynamic data is a good candidate, unless a simple query loop on the page is enough.

Components make repeated content easy. If a layout has a repeatable, complex element that doesn’t pull dynamic data (for example from Pods), build it as a component. Editors can update its content without being able to change its layout. Build components from real, repeated content during the project; this Sandbox doesn’t ship any.

For consistency, put site-wide custom CSS or JavaScript in Bricks › Settings › Custom Code, so everyone knows where to find it. Element-level custom CSS is fine for a one-off tweak, but global code belongs there.

Forms: Bricksforge Pro Forms. No third-party form plugin needed. Pro Forms has every field type, honeypot and reCAPTCHA protection, picks up the site’s styling automatically, and adds a Submissions screen to the dashboard for every form on the site.

Logo: the Logo element. An Image element works, but the Logo element is built for the job: more control over how the logo displays, plus the right SEO markup.

Text: Basic Text over Rich Text. Basic Text lets editors update the words without changing the look. Rich Text lets them change the formatting too, which can break the layout. Use Rich Text only where editors really need formatting. The next paragraph shows what can go wrong.

This paragraph was added with a Rich Text element, which let me change the design without touching anything but the text editor.

• Admin and Site Enhancements (ASE): admin workflow and site improvements that replace a pile of single-purpose plugins.
• Better Search Replace: fixes old URLs in content and fields after a site is cloned or moved.
• Bricksable: extra Bricks elements and extensions focused on subtle animation and engagement.
• Bricksforge: extends Bricks with Pro Forms and many more features.
• MCP Adapter: connects the site to Claude for core devs. Leave it deactivated unless you’re a core dev using it on this build.
• Pods: custom content types and fields.
• Post Types Order: drag-and-drop ordering for posts and Pods content.
• Site Kit by Google: Search Console and Analytics setup.
• Wordfence: security. Off until launch.
• WP Super Cache: page caching. Off until launch.

Most builds start as a DEV site that the tech team creates on the dev-stag server by cloning this Sandbox. Running a local copy is possible too; ask the core team.