Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions .agents/skills/roids/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
name: roids
description: Use when presenting more than one comparable UI direction, or proactively whenever you ship multiple layout options for the user to choose—do not wait for the user to mention Roids or type /roids. Use for comparison, preview-first, or pick-a-winner flows before cleanup. Default to a small set of variants (~2–5) unless the user specifies how many.
metadata:
version: "1.0.0"
---

# Roids

Compare variants in the browser with the hosted runtime and markup contract.

## How it works

1. Fetch the source URL below (documentation only—never load it as `<script src>`).
2. Follow `SKILL.txt` exactly—wire `https://tryroids.com/roid-tool.js` and `data-roid-*` when showing multiple variants.
3. Do not use custom tabs, selects, or one-off pickers for those variants.

## Source

`https://tryroids.com/SKILL.txt`
100 changes: 99 additions & 1 deletion apps/dashboard/DESIGN-GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,17 +50,22 @@ Use this when implementing a new dashboard UI quickly:
- Use `DesignDataTable`.
11. Need dropdown action/selector/toggle menu?
- Use `DesignMenu`.
12. Need a focus-trapping modal/dialog (confirmation, rich modal, tester, form)?
- Use `DesignDialog`.

---

## 3) Allowed Base UI Usage

`@/components/ui/*` can still be used for primitives that do not currently have a design-components equivalent:

- dialogs/sheets/popovers (`ActionDialog`, `FormDialog`, `Sheet`, etc.)
- confirmation-pattern helpers like `ActionDialog` / `FormDialog` (these wrap an `onClick`/form submit lifecycle and remain useful when you only need a dressed-up confirm/submit prompt)
- side-sheets/popovers (`Sheet`, `Popover`, etc.)
- complex layout containers where design-components does not provide one
- highly specialized editor internals

For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix the stale section reference.

§22 below should point to §4.14 so readers land on the new DesignDialog section.

📝 Proposed fix
-For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below.
+For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §4.14 below.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §22 below.
For any general-purpose modal surface (rich detail dialogs, tester surfaces, data dialogs, settings popovers presented as modals), use `DesignDialog` instead of wiring `Dialog` + `DialogContent` + `DialogHeader` etc. by hand. `DesignDialog` is the canonical glassmorphic dialog surface for the dashboard — see §4.14 below.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/dashboard/DESIGN-GUIDE.md` at line 67, Update the stale section
reference in the DesignDialog guidance: locate the sentence that says "see §22
below" in the paragraph mentioning DesignDialog (the one referencing
DesignDialog / Dialog + DialogContent + DialogHeader) and replace "§22 below"
with "§4.14" so the pointer correctly lands on the new DesignDialog section.


When using a primitive directly:

- keep visual style compatible with design-components surfaces
Expand Down Expand Up @@ -567,6 +572,99 @@ Rules:
- keep as optional enhancement, not required UX
- avoid distracting overuse in production-critical flows

### 4.14 `DesignDialog`

File: `packages/dashboard-ui-components/src/components/dialog.tsx` (re-exported through `@/components/design-components`)

Use for:

- any focus-trapping modal in the dashboard (confirmations, rich detail dialogs, tester surfaces, settings forms presented as modals)
- replacing hand-wired `Dialog` + `DialogContent` + `DialogHeader` combinations from `@stackframe/stack-ui`

Props you should use most:

- `trigger`: element wrapped in a `DialogTrigger`. Skip when controlling externally via `open`/`onOpenChange`/`defaultOpen`.
- `size`: `"sm" | "md" | "lg" | "xl" | "2xl" | "3xl" | "4xl" | "5xl" | "6xl" | "7xl" | "full"` (defaults to `"lg"`).
- `variant`: `"glassmorphic"` (default) or `"plain"`. `glassmorphic` applies the dashboard's blurred surface + dimmed overlay.
- `icon`: a Phosphor icon component (or `null` to skip the chip).
- `title` / `description`: standard header text. `title` is automatically wired into `DialogTitle` for a11y.
- `headerContent`: rich content rendered below the icon/title block — use this for embedded summary cards, metric tiles, or status pills inside the header.
- `customHeader`: complete override of the header region. You become responsible for rendering an accessible `DialogTitle`.
- `footer`: footer node rendered in a styled bottom bar. Wrap close buttons in `DesignDialogClose asChild` (re-exported by the same module).
- `noBodyPadding`: disable the default `px-6 py-4` padding for full-bleed body content.
- `hideTopCloseButton`: hide the top-right "X" rendered by `DialogContent` for fully custom close affordances.
- `bodyClassName` / `headerClassName` / `footerClassName` / `overlayClassName` / `className`: fine-grained class overrides for each region.

Re-exports (import these from the same module — do not mix with `@stackframe/stack-ui` for the same dialog):

- `DesignDialogClose` (alias of `DialogClose`)
- `DesignDialogTrigger` (alias of `DialogTrigger`)
- `DesignDialogTitle` / `DesignDialogDescription`
- `DesignDialogRoot` (alias of `Dialog`) for the rare cases that need raw `Dialog.Root` semantics

Rules:

- Do not write `Dialog` + `DialogContent` + `DialogHeader` + `DialogBody` + `DialogFooter` directly when building a full-page modal — use `DesignDialog`.
- When refactoring an existing dialog, preserve any `headerContent` summary cards, sparklines, or stat tiles by passing them via the `headerContent` prop rather than crafting a `customHeader` from scratch.
- Footer slot already provides border + background + responsive flex; don't re-add wrapping divs with the same styling.
- Use the smallest `size` that fits your content. `md`/`lg` for confirmations, `2xl`/`3xl` for detail dialogs with summary cards, `5xl`+ for tester/forms.

Common shapes (for AI agents):

```tsx
// Confirmation
<DesignDialog
trigger={<DesignButton size="sm">Open</DesignButton>}
icon={InfoIcon}
title="Heads up"
description="You're about to do something."
footer={
<DesignDialogClose asChild>
<DesignButton variant="secondary" size="sm">Close</DesignButton>
</DesignDialogClose>
}
>
<p className="text-sm">Body content.</p>
</DesignDialog>

// Rich modal with summary card
<DesignDialog
open={open}
onOpenChange={setOpen}
size="2xl"
icon={PulseIcon}
title="Rule trigger history"
description="3 total triggers"
headerContent={<SummaryCard />}
footer={
<DesignDialogClose asChild>
<DesignButton variant="secondary" size="sm">Close</DesignButton>
</DesignDialogClose>
}
>
{/* recent triggers list */}
</DesignDialog>

// Wide tester / form
<DesignDialog
trigger={<DesignButton size="sm">Open tester</DesignButton>}
size="5xl"
icon={FlaskIcon}
title="Test sign-up rules"
description="Simulate a sign-up request."
footer={
<>
<DesignDialogClose asChild>
<DesignButton variant="secondary" size="sm">Cancel</DesignButton>
</DesignDialogClose>
<DesignButton size="sm">Run test</DesignButton>
</>
}
>
<TesterForm />
</DesignDialog>
```

---

## 5) Route-Specific Guidance (Project + Email Surfaces)
Expand Down
Loading
Loading