@inneranimalmedia/agentsam-sdk 2.6.5 → 2.6.7

package/skills/grok-design-ui/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: design-ui
+description: >
+  Design and build polished, non-generic UI for this TanStack Start + React +
+  Tailwind v4 + shadcn/Radix app. Use whenever you create or restyle any
+  interface surface — pages, landing pages, dashboards, forms, modals, nav, and
+  game overlays (start screens, HUD, menus). Covers design tokens, layout,
+  typography, color, spacing, motion, and the anti-"AI-slop" rules that keep
+  output from looking generic. Triggers on "design", "UI", "make it look good",
+  "polish", "landing page", "theme", "style", "redesign", "ugly", "clean up".
+metadata:
+  short-description: "Polished, non-generic UI: tokens, layout, type, color, motion, anti-slop"
+user-invocable: false
+---
+
+# Design & UI
+
+Make interfaces that look intentional and premium, not template-generic. This is
+the single biggest quality lever in the app builder. Apply it to **DOM / overlay
+UI** — pages, chrome, HUD, menus, forms. (For a 3D game's gameplay canvas, see
+the `building-games` skill; this skill governs the DOM UI layered over it.)
+
+**Read `references/` for depth** (loaded on demand — don't inline it all):
+- `references/refined-ui.md` — the full product-chrome/overlay design system.
+- `references/typography.md` — type scale, pairing, rhythm.
+- `references/surfaces.md` — elevation, borders, shadows, layering.
+- `references/animations.md` — motion, easing, transitions.
+- `references/performance.md` — keep UI smooth (60fps, no jank).
+
+---
+
+## 1. Design-system-first (do this before styling anything)
+
+Define the system once, then compose from it. **Never** sprinkle ad-hoc values.
+
+- **Tokens in CSS (Tailwind v4 is CSS-first).** Put the palette, radii, and fonts
+  in `src/styles.css` under `@theme` as CSS variables; consume them as Tailwind
+  utilities. One source of truth.
+  ```css
+  @import "tailwindcss";
+  @theme {
+    --color-bg: #0b0b0f;      --color-surface: #16161d;
+    --color-fg: #e7e7ea;      --color-muted: #a0a0ab;
+    --color-primary: #14b8a6; --color-border: #26262f;
+    --radius: 0.75rem;        --font-sans: "Inter", system-ui, sans-serif;
+  }
+  ```
+- **Use shadcn/ui components** (Radix primitives + `cva` variants + `tailwind-merge`)
+  for buttons, dialogs, dropdowns, inputs, etc. They're accessible and consistent.
+  Generate them into `src/components/ui`; style via tokens, not inline hex.
+- **Tailwind v4 base fix — buttons need a pointer cursor.** v4's Preflight makes
+  `<button>` use `cursor: default`, which feels broken. Add this once in
+  `src/styles.css` so buttons/clickable roles show a pointer:
+  ```css
+  @layer base {
+    button:not(:disabled),
+    [role="button"]:not(:disabled) { cursor: pointer; }
+  }
+  ```
+- **Ban ad-hoc styling:** no raw hex in JSX, no `text-white`/`bg-black` literals,
+  no arbitrary values like `p-[16px]` or `text-[13px]`. If you need a value,
+  it becomes a token or a scale step.
+
+## 2. The quantified rubric (cheap rules that prevent "ugly")
+
+- **≤ 3–5 colors total** (one primary + neutrals + at most one accent). No random
+  extra hues. Don't default to purple unless asked.
+- **≤ 2 font families** (often one). Pair a display/heading with a body, or use one.
+- **Line-height 1.4–1.6** for body; tighter for large headings.
+- **When you override a background color, override the foreground/text color too**
+  (contrast must hold — check both light and dark).
+- **Mobile-first**: design the ~390px layout first, then scale up. No horizontal
+  overflow; tap targets ≥ 44px.
+- **Consistent spacing scale** (4/8-based). Generous whitespace beats cramming.
+- **One accent, used sparingly** for primary actions — not everywhere.
+
+## 3. Anti-AI-slop (the tells that make output look generic — avoid)
+
+- **No gradient-blob filler**, no giant hero gradients as a substitute for content.
+- **No emoji as icons** — use a real icon set (`lucide-react`).
+- **No hand-drawn SVG** illustrations/maps/charts — use real libraries (`recharts`
+  for charts) or real generated images.
+- **No placeholder images / lorem-gray boxes** in the final product — generate
+  real images or use real content; set `crossOrigin="anonymous"` on canvas images.
+- **Avoid the overused-font look** (default system-only, or Comic Sans-tier picks).
+- **Every element earns its place.** Cut decorative noise. Establish a system,
+  then vary with intent — not randomness.
+- **Match the existing UI when editing** an app in place; don't introduce a second
+  visual language.
+
+## 4. Layout & hierarchy
+
+- Clear visual hierarchy: one primary action per view; size/weight/color express
+  importance. See `references/typography.md` and `references/surfaces.md`.
+- Use real layout structure (grid/flex, container max-widths), not absolute-position
+  hacks. Align to a consistent grid.
+- Empty states, loading states, and error states are part of the design — don't
+  ship blank/janky intermediate states.
+
+## 5. Motion (subtle, purposeful)
+
+- Short, eased transitions (150–250ms) on hover/press/enter; respect
+  `prefers-reduced-motion`. Details in `references/animations.md`.
+- Never animate layout in a way that causes jank; prefer transform/opacity.
+
+## 6. Game overlays (when this pairs with `building-games`)
+
+The gameplay canvas is owned by `building-games`. This skill styles the **DOM
+overlay**: start/"click to play" screen, HUD, score, menus, pause, mobile
+controls. Keep overlay readable over the canvas (backdrop, contrast), and keep it
+out of the pointer-lock/gameplay input path.
+
+---
+
+## Finish checklist (before you call UI done)
+- Tokens defined in `@theme`; no ad-hoc hex / arbitrary values in JSX.
+- ≤ 5 colors, ≤ 2 fonts, consistent spacing scale.
+- Contrast holds; foreground overridden wherever background is.
+- Mobile (~390px) has no overflow; targets ≥ 44px.
+- Real icons/images/charts — none of the anti-slop tells.
+- Loading/empty/error states handled; motion subtle and reduced-motion-safe.
+- Rendered and eyeballed in a browser (see AGENTS.md verification), not just curl.

package/skills/grok-design-ui/agentsam.skill.json

@@ -0,0 +1,25 @@
+{
+  "schema": "agentsam.skill.v1",
+  "id": "grok-design-ui",
+  "name": "Grok \u00b7 design-ui",
+  "description": "Polished, non-generic UI: tokens, layout, type, color, motion, anti-slop",
+  "icon": "skill",
+  "slash": {
+    "suggested": "/grok-design-ui"
+  },
+  "instructions": {
+    "source": "local_file",
+    "ref": "SKILL.md"
+  },
+  "execution": {
+    "mode": "turn",
+    "tools": [],
+    "operations": [],
+    "capabilities": []
+  },
+  "provenance": {
+    "source": "apps/local-studio/.grok/skills",
+    "vendor": "grok",
+    "status": "imported"
+  }
+}

package/skills/grok-design-ui/references/animations.md

@@ -0,0 +1,379 @@
+# Animations
+
+Interruptible animations, enter/exit transitions, and contextual icon animations.
+
+## Interruptible Animations
+
+Users change intent mid-interaction. If animations aren't interruptible, the interface feels broken.
+
+### CSS Transitions vs. Keyframes
+
+| | CSS Transitions | CSS Keyframe Animations |
+| --- | --- | --- |
+| **Behavior** | Interpolate toward latest state | Run on a fixed timeline |
+| **Interruptible** | Yes — retargets mid-animation | No — restarts from beginning |
+| **Use for** | Interactive state changes (hover, toggle, open/close) | Staged sequences that run once (enter animations, loading) |
+| **Duration** | Adapts to remaining distance | Fixed regardless of state |
+
+```css
+/* Good — interruptible transition for a toggle */
+.drawer {
+  transform: translateX(-100%);
+  transition: transform 200ms ease-out;
+}
+.drawer.open {
+  transform: translateX(0);
+}
+
+/* Clicking again mid-animation smoothly reverses — no jank */
+```
+
+```css
+/* Bad — keyframe animation for interactive element */
+.drawer.open {
+  animation: slideIn 200ms ease-out forwards;
+}
+
+/* Closing mid-animation snaps or restarts — feels broken */
+```
+
+**Rule:** Always prefer CSS transitions for interactive elements. Reserve keyframes for one-shot sequences.
+
+## Enter Animations: Split and Stagger
+
+Don't animate a single large container. Break content into semantic chunks and animate each individually.
+
+### Step by Step
+
+1. **Split** into logical groups (title, description, buttons)
+2. **Stagger** with ~100ms delay between groups
+3. **For titles**, consider splitting into individual words with ~80ms stagger
+4. **Combine** `opacity`, `blur`, and `translateY` for the enter effect
+
+### Code Example
+
+```tsx
+// Motion (Framer Motion) — staggered enter
+function PageHeader() {
+  return (
+    <motion.div
+      initial="hidden"
+      animate="visible"
+      variants={{
+        visible: { transition: { staggerChildren: 0.1 } },
+      }}
+    >
+      <motion.h1
+        variants={{
+          hidden: { opacity: 0, y: 12, filter: "blur(4px)" },
+          visible: { opacity: 1, y: 0, filter: "blur(0px)" },
+        }}
+      >
+        Welcome
+      </motion.h1>
+
+      <motion.p
+        variants={{
+          hidden: { opacity: 0, y: 12, filter: "blur(4px)" },
+          visible: { opacity: 1, y: 0, filter: "blur(0px)" },
+        }}
+      >
+        A description of the page.
+      </motion.p>
+
+      <motion.div
+        variants={{
+          hidden: { opacity: 0, y: 12, filter: "blur(4px)" },
+          visible: { opacity: 1, y: 0, filter: "blur(0px)" },
+        }}
+      >
+        <Button>Get started</Button>
+      </motion.div>
+    </motion.div>
+  );
+}
+```
+
+### CSS-Only Stagger
+
+```css
+.stagger-item {
+  opacity: 0;
+  transform: translateY(12px);
+  filter: blur(4px);
+  animation: fadeInUp 400ms ease-out forwards;
+}
+
+.stagger-item:nth-child(1) { animation-delay: 0ms; }
+.stagger-item:nth-child(2) { animation-delay: 100ms; }
+.stagger-item:nth-child(3) { animation-delay: 200ms; }
+
+@keyframes fadeInUp {
+  to {
+    opacity: 1;
+    transform: translateY(0);
+    filter: blur(0);
+  }
+}
+```
+
+## Exit Animations
+
+Exit animations should be softer and less attention-grabbing than enter animations. The user's focus is moving to the next thing — don't fight for attention.
+
+### Subtle Exit (Recommended)
+
+```tsx
+// Small fixed translateY — indicates direction without drama
+<motion.div
+  exit={{
+    opacity: 0,
+    y: -12,
+    filter: "blur(4px)",
+    transition: { duration: 0.15, ease: "easeIn" },
+  }}
+>
+  {content}
+</motion.div>
+```
+
+### Full Exit (When Context Matters)
+
+```tsx
+// Slide fully out — use when spatial context is important
+// (e.g., a card returning to a list, a drawer closing)
+<motion.div
+  exit={{
+    opacity: 0,
+    x: "-100%",
+    transition: { duration: 0.2, ease: "easeIn" },
+  }}
+>
+  {content}
+</motion.div>
+```
+
+### Good vs. Bad
+
+```css
+/* Good — subtle exit */
+.item-exit {
+  opacity: 0;
+  transform: translateY(-12px);
+  transition: opacity 150ms ease-in, transform 150ms ease-in;
+}
+
+/* Bad — dramatic exit that steals focus */
+.item-exit {
+  opacity: 0;
+  transform: translateY(-100%) scale(0.5);
+  transition: all 400ms ease-in;
+}
+
+/* Bad — no exit animation at all (element just vanishes) */
+.item-exit {
+  display: none;
+}
+```
+
+**Key points:**
+- Use a small fixed `translateY` (e.g., `-12px`) instead of the full container height
+- Keep some directional movement to indicate where the element went
+- Exit duration should be shorter than enter duration (150ms vs 300ms)
+- Don't remove exit animations entirely — subtle motion preserves context
+
+## Contextual Icon Animations
+
+When icons appear or disappear contextually (on hover, on state change), animate them with `opacity`, `scale`, and `blur` rather than just toggling visibility.
+
+### Motion Example
+
+```tsx
+import { AnimatePresence, motion } from "motion/react";
+
+function IconButton({ isActive, icon: Icon }) {
+  return (
+    <button>
+      <AnimatePresence mode="popLayout">
+        <motion.span
+          key={isActive ? "active" : "inactive"}
+          initial={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}
+          animate={{ opacity: 1, scale: 1, filter: "blur(0px)" }}
+          exit={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}
+          transition={{ type: "spring", duration: 0.3, bounce: 0 }}
+        >
+          <Icon />
+        </motion.span>
+      </AnimatePresence>
+    </button>
+  );
+}
+```
+
+### CSS Transition Approach (No Motion)
+
+If the project doesn't use Motion (Framer Motion), keep both icons in the DOM and cross-fade them with CSS transitions. Because neither icon unmounts, both enter and exit animate smoothly.
+
+The trick: one icon is absolutely positioned on top of the other. Toggling state cross-fades them — the entering icon scales up from `0.25` while the exiting icon scales down to `0.25`, both with opacity and blur.
+
+```tsx
+function IconButton({ isActive, ActiveIcon, InactiveIcon }) {
+  return (
+    <button>
+      <div className="relative">
+        <div
+          className={cn(
+            "absolute inset-0 flex items-center justify-center",
+            "transition-[opacity,filter,scale] duration-300",
+            "ease-[cubic-bezier(0.2,0,0,1)]",
+            isActive
+              ? "scale-100 opacity-100 blur-none"
+              : "scale-[0.25] opacity-0 blur-[4px]"
+          )}
+        >
+          <ActiveIcon />
+        </div>
+        <div
+          className={cn(
+            "transition-[opacity,filter,scale] duration-300",
+            "ease-[cubic-bezier(0.2,0,0,1)]",
+            isActive
+              ? "scale-[0.25] opacity-0 blur-[4px]"
+              : "scale-100 opacity-100 blur-none"
+          )}
+        >
+          <InactiveIcon />
+        </div>
+      </div>
+    </button>
+  );
+}
+```
+
+The non-absolute icon (InactiveIcon) defines the layout size. The absolute icon (ActiveIcon) overlays it without affecting flow.
+
+### Choosing Between Motion and CSS
+
+| | Motion (Framer Motion) | CSS transitions (both icons in DOM) |
+| --- | --- | --- |
+| **Enter animation** | Yes | Yes |
+| **Exit animation** | Yes (via `AnimatePresence`) | Yes (cross-fade — icon never unmounts) |
+| **Spring physics** | Yes | No — use `cubic-bezier(0.2, 0, 0, 1)` as approximation |
+| **When to use** | Project already uses `motion/react` | No motion dependency, or keeping bundle small |
+
+**Rule:** Check the project's `package.json` for `motion` or `framer-motion`. If present, use the Motion approach. If not, use the CSS cross-fade pattern — don't add a dependency just for icon transitions.
+
+### When to Animate Icons
+
+| Animate | Don't animate |
+| --- | --- |
+| Icons that appear on hover (action buttons) | Static navigation icons |
+| State change icons (play → pause, like → liked) | Decorative icons |
+| Icons in contextual toolbars | Icons that are always visible |
+| Loading/success state indicators | Icon labels (text next to icon) |
+
+**Important:** Always use exactly these values for contextual icon animations — do not deviate:
+- `scale`: `0.25` → `1` (never use `0.5` or `0.6`)
+- `opacity`: `0` → `1`
+- `filter`: `"blur(4px)"` → `"blur(0px)"`
+- `transition`: `{ type: "spring", duration: 0.3, bounce: 0 }` — **bounce must always be `0`**, never `0.1` or any other value
+
+## Scale on Press
+
+A subtle scale-down on click gives buttons tactile feedback. Always use `scale(0.96)`. Never use a value smaller than `0.95` — anything below feels exaggerated. Use CSS transitions for interruptibility — if the user releases mid-press, it should smoothly return.
+
+Not every button needs this. Add a `static` prop to your button component that disables the scale effect when the motion would be distracting.
+
+### CSS Example
+
+```css
+.button {
+  transition-property: scale;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+
+.button:active {
+  scale: 0.96;
+}
+```
+
+### Tailwind Example
+
+```tsx
+<button className="transition-transform duration-150 ease-out active:scale-[0.96]">
+  Click me
+</button>
+```
+
+### Motion Example
+
+```tsx
+<motion.button whileTap={{ scale: 0.96 }}>
+  Click me
+</motion.button>
+```
+
+### Static Prop Pattern
+
+Extract the scale class into a variable and conditionally apply it based on a `static` prop:
+
+```tsx
+const tapScale = "active:not-disabled:scale-[0.96]";
+
+function Button({ static: isStatic, className, children, ...props }) {
+  return (
+    <button
+      className={cn(
+        "transition-transform duration-150 ease-out",
+        !isStatic && tapScale,
+        className,
+      )}
+      {...props}
+    >
+      {children}
+    </button>
+  );
+}
+
+// Usage
+<Button>Click me</Button>           {/* scales on press */}
+<Button static>Submit</Button>       {/* no scale */}
+```
+
+## Skip Animation on Page Load
+
+Use `initial={false}` on `AnimatePresence` to prevent enter animations from firing on first render. Elements that are already in their default state shouldn't animate in on page load — only on subsequent state changes.
+
+### When It Works
+
+```tsx
+// Good — icon doesn't animate in on mount, only on state change
+<AnimatePresence initial={false} mode="popLayout">
+  <motion.span
+    key={isActive ? "active" : "inactive"}
+    initial={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}
+    animate={{ opacity: 1, scale: 1, filter: "blur(0px)" }}
+    exit={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}
+  >
+    <Icon />
+  </motion.span>
+</AnimatePresence>
+```
+
+Works well for: icon swaps, toggles, tabs, segmented controls — anything that has a default state on page load.
+
+### When It Breaks
+
+Don't use `initial={false}` when the component relies on its `initial` prop to set up a first-time enter animation, like a staggered page hero or a loading state. In those cases, removing the initial animation skips the entire entrance.
+
+```tsx
+// Bad — initial={false} would skip the staggered page enter entirely
+<AnimatePresence initial={false}>
+  <motion.div initial="hidden" animate="visible" variants={...}>
+    ...
+  </motion.div>
+</AnimatePresence>
+```
+
+Verify the component still looks right on a full page refresh before applying this.

package/skills/grok-design-ui/references/performance.md

@@ -0,0 +1,88 @@
+# Performance
+
+Transition specificity and GPU compositing hints.
+
+## Transition Only What Changes
+
+Never use `transition: all` or Tailwind's `transition` shorthand (which maps to `transition-property: all`). Always specify the exact properties that change.
+
+### Why
+
+- `transition: all` forces the browser to watch every property for changes
+- Causes unexpected transitions on properties you didn't intend to animate (colors, padding, shadows)
+- Prevents browser optimizations
+
+### CSS Example
+
+```css
+/* Good — only transition what changes */
+.button {
+  transition-property: scale, background-color;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+
+/* Bad — transition everything */
+.button {
+  transition: all 150ms ease-out;
+}
+```
+
+### Tailwind
+
+```tsx
+// Good — explicit properties
+<button className="transition-[scale,background-color] duration-150 ease-out">
+
+// Bad — transition all
+<button className="transition duration-150 ease-out">
+```
+
+### Tailwind `transition-transform` Note
+
+`transition-transform` in Tailwind maps to `transition-property: transform, translate, scale, rotate` — it covers all transform-related properties, not just `transform`. Use this when you're only animating transforms. For multiple non-transform properties, use the bracket syntax: `transition-[scale,opacity,filter]`.
+
+## Use `will-change` Sparingly
+
+`will-change` hints the browser to pre-promote an element to its own GPU compositing layer. Without it, the browser promotes the element only when the animation starts — that one-time layer promotion can cause a micro-stutter on the first frame.
+
+This particularly helps when an element is changing `scale`, `rotation`, or moving around with `transform`. For other properties, it doesn't help much — the browser can't composite them on the GPU anyway.
+
+### Rules
+
+```css
+/* Good — specific property that benefits from GPU compositing */
+.animated-card {
+  will-change: transform;
+}
+
+/* Good — multiple compositor-friendly properties */
+.animated-card {
+  will-change: transform, opacity;
+}
+
+/* Bad — never use will-change: all */
+.animated-card {
+  will-change: all;
+}
+
+/* Bad — properties that can't be GPU-composited anyway */
+.animated-card {
+  will-change: background-color, padding;
+}
+```
+
+### Useful Properties
+
+| Property | GPU-compositable | Worth using `will-change` |
+| --- | --- | --- |
+| `transform` | Yes | Yes |
+| `opacity` | Yes | Yes |
+| `filter` (blur, brightness) | Yes | Yes |
+| `clip-path` | Yes | Yes |
+| `top`, `left`, `width`, `height` | No | No |
+| `background`, `border`, `color` | No | No |
+
+### When to Skip
+
+Modern browsers are already good at optimizing on their own. Only add `will-change` when you notice first-frame stutter — Safari in particular benefits from it. Don't add it preemptively to every animated element; each extra compositing layer costs memory.