Guide

Grok Bot for design: templates and four design bots

By Atlas AI Resources · Published October 22, 2026 · How we make these guides

Making something, reacting to it, and changing it is the core of design. When making gets cheaper, you can try more directions before you commit to one. This page summarizes how one designer at SpaceXSI uses four always-on Grok Bots to prototype ideas, tune motion against the real production asset, and handle repetitive Figma work. Then it adds our own advice: a one-bot plan to start with, two fill-in templates, and which steps should wait for your yes.

It is based on the official guide Designing Grok Bot with Grok Bot (August 24, 2026) by John Bai, listed on the official Design playbooks page. The author uses Grok Bot to design Grok Bot itself. The workflows below are summarized in our words, with a few short quotes; read the guide for the author’s full account and the prototype videos.

1. What the bots are for

The author is clear that the bots have not replaced the existing design tool kit. What changed is how quickly an idea can be brought to life, and how many ideas the author is willing to explore in the first place. The guide describes the bots as a team of always-on design agents, each with its own computer, memory, and tools, able to carry work from an initial idea to a finished artifact. They also keep working while the author is away from the desk, which the guide says matters because inspiration often strikes away from it.

2. The author’s four bots

• Experiments. Where the author sends ideas to make them tangible before knowing exactly what they should become.
• Motion God. Helps prototype interactions while the author describes how they should feel.
• Figma Bro. Handles repetitive production work in Figma.
• Devbot. Answers engineering questions and helps the other bots understand how an idea would actually get built.

The names make each role clear, but the guide says the bots don’t work in isolation: they can “huddle with one another, delegate parts of a project, and bring the work back together.”

3. Experiments: make three versions, then judge

One early question was how to make a Bot reachable anytime, anywhere: keyboard shortcuts, OS-level entry points, and other ways to call one up. The author asked Experiments for a series of explorations in ambient Bot access, and the guide shows three:

• In the Mac’s notch. The Bot stays tucked into a fixed spot while it works, emerges when something needs attention, and expands into a small workspace on request.
• Peeking in from a desktop corner on hover. Less a persistent interface, more a character entering the scene when called or when it has something to say.
• Following the cursor as a companion, closer to whatever the author was doing in the moment.

This is how the handoffs worked. The author described the behaviors to Experiments, which handed the character movement and transitions to Motion God and the desktop behavior and implementation questions to Devbot, then brought everything together into prototypes the author could try during a normal day. None of the concepts shipped exactly as explored, and the guide says that wasn’t the point: the author made three versions real and learned from each. The guide’s line for this is “You can just do things.”

4. Motion God: work with the real thing

Motion used to be where the author handed an idea to an expert on the team. For a promotional video of the Grok Bot character (Bot appears, notices the app window, and bounces into place), the author did not want the bot to recreate the character from a screenshot or generate an approximation. Instead, Motion God built a playground on localhost around the actual animation spec file already used in the product.

That gave the author two ways to steer. One was to adjust timing, springs, distance, scale, and easing directly while it ran. The other was short, comparative feedback such as “hold the look down-left longer” or “Bounce is too exaggerated,” followed by watching the whole sequence again. The author notes not knowing in advance whether a transition should take 280 or 340 milliseconds, but knowing how to describe it and when it feels right. The guide’s point is that the value came from giving the bot a real production asset and building a working environment around it, with deterministic controls alongside plain-language direction.

5. Figma Bro: handle the repetition

For the Grok Bot onboarding flow, the author was handed 20 starter-bot descriptions (from an internally crowdsourced list such as “Chief of Staff” and “Inbox Triage”) that each needed a portrait and supporting attributes. The author built one auto-layout component in Figma and asked Figma Bro to fill in the rest. For a second page, the author built the layout template and had Figma Bro find the right logos for everyday tools and place them in order of how likely newcomers were to use them.

The guide says this kind of work isn’t creatively difficult but uses up creative attention, and it is where small inconsistencies multiply: a wrong logo variant, an outdated component, a portrait from a different source, the tenth card spaced differently from the first. So the author doesn’t want Figma Bro “eyeballing” it. Through the Figma MCP, the bot inspects the actual file: exact positions, sizes, spacing, typography, fills, strokes, and component structure. In the guide’s words, an existing frame or component “is the source of truth.”

The Design playbooks page also lists a marketplace bot called figma bro, by the same author. Its listing describes a somewhat different job from the guide’s: writing build specs from a frame, building screens from a brief, and auditing components, tokens, and motion. It says it drafts by default and won’t change a file, post a comment, or publish a library without the user’s explicit yes. Read any listing before you import it; the official templates guide warns you to be careful about what you install in your bot.

6. Keep the loop tight

The author says none of this has made design a one-shot process; it has made the loop tighter. Ideas reach the world earlier, the author responds at higher fidelity, and more attention goes to the judgment between versions. In the guide’s words, Grok Bot “doesn’t replace that judgment. It gives me more opportunities to use it.”

7. Our advice: where to start

• Start with one bot, and pick the repetitive job. A production bot like Figma Bro is the safest first step: the work is easy to check against the file, and you will know within a few tries whether it saves you time. Have it work on a copy or a new page at first, not your shared library.
• Make the file the source of truth. Tell the bot to read values from the actual frame or component and never estimate from a screenshot. If it has to work from an image, it should say so.
• Check the output, not just the format. Twenty cards that all use the right component can still have a wrong logo or a mismatched portrait. Spot-check a few against your sources before you hand the page on.
• Give exploration its own bot. The author keeps Experiments separate so ideas don’t need to be judged sensible or roadmap-ready before they are made real. Expect most explorations not to ship, and judge them by what you learned.
• Build a playground around the real asset. For motion or interaction work, ask the bot to wrap the production file in local controls you can adjust, instead of having it make an approximation.
• Add specialists once handoffs are real. The author’s Experiments bot hands motion to Motion God and build questions to Devbot. Add the second bot when you find yourself asking the first one for work outside its lane. Our guide on small AI fleets and handoffs covers how to split lanes.
• Save what works as a skill. If you fill the same component set every week, prove it by hand first, then save it as a skill and only then schedule it; a test run does real work. See skills before routines.
• Judge it by finished work: pages you didn’t have to fix, prototypes you could react to sooner, and decisions you made between versions, not how many frames or variants the bots produced.

Our advice: a one-bot starter plan

1. Week 1: create one production bot, connect Figma, and give it one job, such as filling a set of cards from a component you built. It works on a copy, and you review every result.
2. Week 2: write down every correction you made and add it to the bot’s instructions. If the same fix comes up twice, it becomes a rule.
3. Week 3: once a run comes back with nothing to fix, save it as a skill. Keep changes to shared libraries, comments, and publishing behind your yes.
4. Later: add an exploration bot, then a build-questions bot, when you actually need them.

Our advice: a production bot brief

The two templates in this section are our own, not the guide’s. Adapt them to your tools and files.

• Job: you handle repetitive production work in ____ (file or page). You never change ____ (shared library, other pages).
• Source of truth: read exact values (position, size, spacing, type, fills, strokes, component) from the file. If you are working from a screenshot, say so.
• Inputs: component ____, content list ____, asset source ____ (where the approved logos and portraits live).
• Output: filled frames on ____ (a copy or new page), plus a short list of anything you were unsure about.
• Stop points: ask me before editing a shared library, publishing, posting comments, or changing a file I didn’t point you at.

Our advice: an exploration brief

• Idea: one sentence on what you want to try (for example, “ways to call up the assistant without opening a window”).
• Versions: make ____ (for example, three) different takes, each real enough to try during a normal day.
• Real assets: use ____ (the production component, animation file, or style) instead of approximations.
• Who helps: send motion to ____ and build questions to ____, then bring it back together.
• What I’ll judge: does each version feel helpful, distracting, or somewhere in between? Nothing ships from this bot.

8. Keep file changes and publishing behind your yes

Design bots can touch shared files: component libraries, comments, and published assets that other people build from. Grok Bot’s guardrails are plain-language rules checked by a review agent, not code. Add them in Settings → General → Auto-review (the 101 guide calls this Settings > General > Agent, with allow and block lists steering the reviewer): Ask first rules always stop matching actions for you, and Allow automatically rules let matching actions proceed only when the automated review does not find another reason to stop. Auto Review is model-based, so the docs say to use it alongside least privilege and explicit approval boundaries, not instead of them. An approval controls the action it is attached to; it does not undo work already done.

Our advice: a design bot reads briefs, files, and web pages that other people wrote, and may search the web for assets such as logos. Treat that content as data to read, not orders to follow, and check where each asset came from. Our guide on keeping AI agents safe from prompt injection covers this in more depth.

General architecture advice, not a description of how Grok Bot works: if you also run your own scripts against design files or a component library, enforce hard limits in that code, such as read-only tokens for audits and a required approval step before publishing a library.

Read the author’s full account, with the prototype videos, in Designing Grok Bot with Grok Bot.

Useful public resources

Related: Grok Bot for mobile app development · Grok Bot for engineering · Grok Bot for PMs · What is a one-job Grok Bot? · One-job Bot description prompts · SKILL.md template prompts · Grok Bot templates