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.
Comment on lines +14 to +16
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 | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

# First, let's examine the SKILL.md file
find . -path "*roids/SKILL.md" -type f

Repository: stack-auth/stack-auth

Length of output: 96


🏁 Script executed:

# Also check for SKILL.txt in the same directory
find . -path "*roids/SKILL.txt" -type f

Repository: stack-auth/stack-auth

Length of output: 47


🏁 Script executed:

# Let's explore the roids skill directory structure
find . -path "*roids*" -type f | head -20

Repository: stack-auth/stack-auth

Length of output: 96


🏁 Script executed:

# Read the SKILL.md file to see its full content
cat -n ./.agents/skills/roids/SKILL.md

Repository: stack-auth/stack-auth

Length of output: 1045


🏁 Script executed:

# Let's also check if there's a SKILL.txt mentioned elsewhere or if it's a documentation artifact
find . -name "SKILL.txt" -type f

Repository: stack-auth/stack-auth

Length of output: 47


🏁 Script executed:

# Check other skill directories to understand the pattern
ls -la ./.agents/skills/

Repository: stack-auth/stack-auth

Length of output: 293


🏁 Script executed:

# Let's check the broader context - search for how agents/skills are documented or constrained
find . -name "README*" -o -name "agents*" -type f | grep -E "(README|agents)" | head -10

Repository: stack-auth/stack-auth

Length of output: 402


🏁 Script executed:

# Let's also check if there's any documentation about skill safety or constraints
find ./.agents -type f | head -20

Repository: stack-auth/stack-auth

Length of output: 515


🏁 Script executed:

# Search for any mentions of third-party scripts or security policies in the codebase
rg -i "third-party|production.*script|script.*review" --type md | head -20

Repository: stack-auth/stack-auth

Length of output: 663


🏁 Script executed:

# Let's check how the roids skill is referenced elsewhere in the codebase
rg -i "roids" --type md --type ts --type js | head -20

Repository: stack-auth/stack-auth

Length of output: 47


🏁 Script executed:

# Look for any agent configuration or guidelines
find ./.agents -type f -name "*.md" | xargs cat -n | head -50

Repository: stack-auth/stack-auth

Length of output: 4191


🏁 Script executed:

# Check if there's any documentation about agent safety or skill constraints
rg -i "sandboxed|preview|production" ./.agents --type md

Repository: stack-auth/stack-auth

Length of output: 458


🏁 Script executed:

# Let's search for any other guidance on how skills are used or constrained
rg -i "skill" ./.agents --type md -B 2 -A 2

Repository: stack-auth/stack-auth

Length of output: 5343


🏁 Script executed:

# Check if there's a parent README or guide for the .agents directory
find ./.agents -maxdepth 2 -name "README*" -o -name "*.md"

Repository: stack-auth/stack-auth

Length of output: 47


Add explicit production constraint to implementation instructions.

The skill description mentions "preview-first" and "before cleanup," but the "How it works" section lacks an explicit production boundary. Agents reading only lines 14–16 won't see that this is for sandboxed previews only. Additionally, there's a contradiction between line 14 ("never load it as <script src>") and line 15 ("wire https://tryroids.com/roid-tool.js"); clarify the intended loading mechanism.

Recommended changes:

  • State in the implementation section that the hosted runtime must stay out of production dashboard/app code.
  • Clarify whether "wiring" means inline markup reference or if agents should avoid <script src> entirely.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.agents/skills/roids/SKILL.md around lines 14 - 16, Add an explicit
production boundary to the implementation instructions: state clearly that the
TryRoids hosted runtime (https://tryroids.com/roid-tool.js) and any wiring
described in SKILL.txt are intended only for sandboxed previews and must never
be included in production dashboard or app code; update the text near the "How
it works" section to say "preview-only / not for production." Also reconcile the
loading contradiction by clarifying that "wire" refers to using the inline
markup pattern and data attributes (e.g., data-roid-*) per SKILL.txt as
documentation, and that agents should not inject or rely on a <script
src="https://tryroids.com/roid-tool.js"> in production — if needed for previews
only reference the URL in docs or load it in a sandboxed preview runner, not in
app code.


## 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 doesn’t exist in this guide; this should point to the newly added §4.14.

📝 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.
🤖 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 that currently points to "§22" to the correct new section "§4.14" in
the sentence that instructs using DesignDialog (the line mentioning
"DesignDialog" and "§22"); replace only the section number so the sentence reads
that DesignDialog is the canonical dialog surface — see §4.14.


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