Openbot Screen Layout
The default layout for every OpenBot configuration screen, PageShell and its...
Install
npx skills add CopilotKit/OpenBot --skill openbot-screen-layout -g -a claude-code -y- Repository
- CopilotKit/OpenBot9.5k
- Category
- Design
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
The default layout for every OpenBot configuration screen, PageShell and its prose/wide widths, PageSection and PageRows, Item row composition, the settings-row pattern where a summary and a chevron open a dialog, and the size and variant vocabulary. This is what a new screen looks like unless an instruction says otherwise. Use when adding or changing a screen under app/src/routes, adding a row to an admin or settings page, choosing a Button or Item size, picking between a bordered and a filled row, laying out a dialog, or reviewing a diff that adds max-w-*, a hand-drawn card, or a new spacing scale under app/src. Don't use for where the data comes from (that is openbot-data-access), for the gallery components under components/gallery that a Bot draws, for the chat and channel surfaces, or for editing the primitives under components/ui themselves.
OpenBot Screen Layout
When To Use
This skill applies to any change under app/src/routes that puts a configuration screen on the
screen, a new admin page, a new settings section, a new row on an existing page, a detail page
behind a list. Twelve screens render through PageShell today and seven build their rows out of
Item; all of them look the same on purpose.
It does not cover where the data comes from, that is openbot-data-access, which owns queries,
mutations, and the pending/error/empty/rows branching. It does not cover the gallery components
under components/gallery, which a Bot draws inside a conversation rather than a person navigating
to. It does not cover the primitives under components/ui, which are this repository's own design-system
primitives: they began as shadcn output, but there is no upstream to re-pull from, and they are
formatted and linted like the rest of the app.
The Default
A new screen uses this layout. Deviating from it needs a reason given in the request.
This is the point of the skill. The decisions here, the width, the spacing, the heading sizes, the
row anatomy, which control means what, are already made, and they are already made the same way on
every other screen. Somebody who does not work in the frontend should be able to add a page that
looks like it belongs without making a single visual decision, by reaching for PageShell,
PageSection, PageRows and Item and filling them in.
The failure this prevents is the one the PageShell doc comment describes: Admin was once nine pages
that shared no layout, four container widths, four heading sizes, four padding schemes, three of
them drawing their own buttons and inputs. It did not read as a different screen, it read as a
different application, at exactly the moment an administrator was deciding whether to trust it with
credentials.
