LIVE-INSPECTED STRUCTURE · SAMPLE CONTENT
This is a local interface demo. Messages are never sent to Grok.
What would a calendar look like if it connected my goals to my day?
Start with a simple chain: vision → project → next action → time. Each calendar item can show why it exists, not only when it happens.
Give the user three ways to look at the same plan:
const today = goals.flatMap(goal => goal.nextActions);Tool and connector activity stays beside the response.
Questions are answered in the conversation, not in a separate workflow.
A request for access should say why and let the user continue without it.
Show my sales pipeline as a CRM table with contacts, companies, deal stages, values, and follow-ups. Keep it here in the chat.
Here is a CRM table using sample contacts and deals. Search, filter, sort, select, and reorder work here; no real CRM or account is connected. Row changes last until reload.
A CRM example of the shared table; the separate task widget handles to-dos.
Swipe the table sideways to see every column.
The interactive table needs JavaScript.
Show me launch analytics here: a chart I can change by metric and time period, with exact values when I need them.
Here is an interactive analytics widget using sample numbers. Nothing is connected to your real traffic or accounts.
One chart, clear totals, exact daily values, and no invented connection.
The interactive chart needs JavaScript.
Show a product result I can search, filter, sort, and save from, without leaving this chat.
Here is a working product result with sample items. Search, sorting, and saved choices work here; there is no store or checkout.
A compact product collection with useful actions, not a separate storefront.
The interactive products need JavaScript.
Give me a focused task view here. I want to capture a task, see what needs attention, finish it, and move work between Now, Next, and Waiting.
Here is a working task view using sample launch work. Your changes stay in this browser; no real project or service is connected.
Capture, act, and move work without leaving the conversation.
The interactive task view needs JavaScript.
Show me a launch brief I can read, search, and revise here. Keep the draft safe while I move through the result.
Here is an editable sample document. Edits stay in this browser; nothing is shared, published, or connected to a real project.
Move between sections, find a passage, and revise the draft in place.
The interactive document needs JavaScript.
Enter to add to this demo · Shift+Enter for a new line
Tools below are examples. Nothing generates or uploads.
Try another category or search term.
Scheduled and triggered work should show what it will do, when it runs, and whether it needs attention.
A sample bot surface. No bot is running.
Project files, conversations, and creation tools share one workspace.
The signed-in Grok canvas is dark, sparse, and centered. A narrow navigation rail holds destinations and history; the main area keeps the next prompt in focus.
--canvas--sidebar-bg--composer-fill--raised--text--palette-slateCOLOR SPECTRUM / EIGHT APPROVED ACCENTS
--palette-red--palette-orange--palette-yellow--palette-green--palette-teal--palette-blue--palette-violet--palette-magentaScott’s reference image defines the saturated color direction. Use only these eight accents for new labels and demo-card artwork; keep the canvas neutral. Violet still matches the avatar exactly. The spectrum is an accessible kit adaptation, not an official Grok palette or a pixel-for-pixel copy of the image.
System sans for UI; monospace only for code. Keep essential copy at 13 px or larger. This readable scale is an adaptation, not an exact Grok measurement.
Let content wrap and cards grow. Do not shrink text to force a fixed height.
Lighter charcoal in dark mode, a distinct fill in light mode, and one soft shadow. Borderless at rest and on focus.
Group one coherent object with its surface color, rounded corners, and spacing. Keep internal separators where they help.
Use for actions, options, and list items inside a larger surface.
Keep the canvas open. Reserve soft elevation for floating composers, menus, dialogs, and temporary feedback. Cards remain borderless. The live desktop composer radius was measured at 24 px.
One chat language: A new chat starts with the large setup composer. After the first message it stays compact: +, message, vertical options menu, Send. Scrolling never changes its mode. Model choice and context-aware tools live in the options menu; drafts still grow automatically. main chat and panel chat share the same composer, controls, messages, and focus behavior. Panel headers sit at the top—no global header. Panel chat grows upward from the bottom to 60% of its panel or 480 px, then its history scrolls. Minimize keeps the header; restore, X, and the chat-icon toggle keep drafts and history safe.
These are the reusable controls behind the canvases. Each action shows its state; every demo action is local only.
Normal widgets show only their title, actions, and content. Turn this on to inspect loading, empty, and error states and leave design review notes. Turning it off returns every widget to its working view without changing your data.
48 px field · 12 px corners · 4 px inset · 40 px action · 8 px inner corners. Copy shows a green check only after the clipboard succeeds. The button keeps its width across states.
One clear action per surface. Keep quiet actions quiet.
Escape closes; focus returns to work.
Explain what happened, then offer the next useful action.
A UI kit is more than colors. These interaction rules are the part worth carrying into another product.
Keep creation central. Let navigation and history support it without taking over the page.
Tool steps, sources, questions, and connector requests belong beside the answer they affect.
Search across chat and media; show results and a preview in one place.
Errors, gates, and mode switches should preserve what the person already wrote.
Unavailable modes, failed uploads, and expired connections need plain reasons and a useful next step.
Show Undo after recoverable removal. Keep irreversible actions explicit.
Audit and codify together. Fix the shared cause, test every affected view, and keep the rules and examples in agreement.
Read the newest user decisions and this contract. Resolve contradictions and remove superseded guidance. Current chat behavior is large setup before the first message, then compact—not scroll-to-hide.
Trace each visual and behavior to its token/component/controller. Reuse it. No copied controls, per-page skins, late override blocks, or new !important repairs. A legitimate variation gets a name and a documented reason.
Measure height, radius, padding, icon gap, edge inset, and text alignment. Standard controls are 48/12; compact 32/8; an inset action derives 40/8 from its 48/12 parent. Center peers and align row controls to the primary title. Check dropdown arrows, disclosures, hover-only drag handles, and long labels.
Check approved palette, white text on blue, contrast, 15 px row titles, supporting type, borderless fields/cards, composer elevation, same-hue gradients, icon family, and named motion. No random colors or per-widget typography.
Exercise idle, hover, keyboard focus, disabled, pending, success, failure, loading, empty and retry where applicable. Actions tell the truth, prevent duplicate submission, keep focus, and offer Undo where promised. Confirmations follow actual success.
Check drafts, messages, filters, model selection, sorting, saved changes and Undo across panel moves, close/reopen, navigation and reload. Use stable IDs, not titles. Preserve unreadable stored data. Failed record commits cannot replace cached saved records. Explain session-only versus persistent storage; never imply AI/backend connectivity.
Test wide desktop, narrow split panel, mobile width and short height in both themes. Check keyboard order, focus return/containment, labels, visible focus, contrast, reduced motion and long-content scrolling. No clipped actions, overlapping composers, inaccessible hidden controls, or outer-page overflow.
Remove obsolete code, dead rules, conflicting names and duplicate handlers. Keep CSS/data/behavior ownership explicit. Content changes never go through HTML injection; content data keys do not change with visual review versions. Do not add a package, controller, or abstraction without a real need.
Run executable state tests, structural checks, syntax checks and whitespace checks. Test all five widget types plus affected shared screens in the browser, not just the edited example. Capture representative screenshots. Add a regression check for every fixed class of bug; distinguish automated assertions from manual browser checks.
The written rule, visible kit example and running component must agree. Update this contract, specimen contract, contributor guidance and test expectations together. Record Found / Fixed / Protected / Unverified, actual tested sizes/themes, evidence and limits. Do not advance with known blocking regressions.
Release gate: no known blocking regressions. Record Found / Fixed / Protected / Unverified in AUDIT.md. Browser/device limits must be stated, not hidden. Test controls stay in Components, never in ordinary widgets.
Observed live: signed-in desktop chat home, sidebar, model picker, command search, Library grid/options, Imagine composer and templates.
Measured live: body background rgb(19,18,17); composer surface rgb(32,31,29); main heading 24px / 550 weight; desktop composer radius 24px.
Documented, not re-tested end-to-end: conversation error and retry, connector cards, project previews, bots and automations. See release notes.
Original kit decisions: all example content, icons, illustration cards, component class names, motion, light theme, and responsive breakpoints. This is not an xAI asset library.