Sections give you structure and design systems give you the look. Gems give you the behaviour — the magnetic button, the marquee, the scroll reveal, the hover state that makes a page feel built rather than assembled. They're small, self-contained, and designed to sit on top of something that already exists.
Gems are indexed by what they do and what triggers them, so lead with the behaviour:
Behind the scenes this becomes a [class]search_byq_gems[/class] call.
Each match returns with a name, description, tags, a thumbnail, the interactions it responds to — Hover, Click, Mouse Move, Focus, Loop — and whether it depends on GSAP.
That last flag is worth paying attention to. Most gems are GSAP-driven, but plenty are pure CSS or vanilla JavaScript with no dependencies at all. If your project doesn't already load GSAP and you'd rather keep it that way, say so — "find a gem for this that doesn't need GSAP" — and your AI can filter on it.
Once you've picked one, your AI calls [class]get_byq_gem[/class] and wires it into the element you're pointing at. Unlike a section, a gem isn't a block you place — it's behaviour you add to something already on the page. So be specific about the target: "add a magnetic hover to the primary CTA only" beats "add a magnetic hover."
The sequence matters here in the opposite direction to design systems. Pull a design system first; add gems last, once the structure is settled and you can see what the page actually needs.
Motion applied at the end is motion you can judge — you add it where attention should go. Motion applied as you build tends to accumulate until everything moves and nothing stands out. One well-placed gem on a primary action does more than six scattered across a page.
Gems are hard to describe and easy to recognise. If nothing you type is landing, open the Gems library on the site, find the effect you actually want, and then ask your AI for it by name — the search will hit it exactly.