chore(skills): retire generic design skills superseded by emilkowalski/skills (#1279)
mobile-ux-core triggers on *.dart / *.swift / *Activity.kt, paths that do not exist in this repo, and its guidance is covered by design.md's accessibility section. scout-design filed Linear tickets while this project files GitHub issues; loop-design-scan is the same scan with the right output, so its sibling cross-reference is updated too. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jakob Wennberg
co-authored by
Claude Opus 5
Claude Opus 5
parent
0df05c83c6
commit
8571f9235b
@@ -6,8 +6,7 @@ description: Local loop that scans a given area of the Accounted UI against the
|
||||
# loop-design-scan
|
||||
|
||||
**Goal:** for one area of the app, surface concrete, design-system-grounded UI/UX improvements and file
|
||||
them as GitHub issues (deduped). This is the GitHub-Issues sibling of the `scout-design` skill (which
|
||||
targets Linear). Read `.claude/loops.md` first. **Runs locally**: it needs to render the UI.
|
||||
them as GitHub issues (deduped). Read `.claude/loops.md` first. **Runs locally**: it needs to render the UI.
|
||||
|
||||
## Why local
|
||||
A headless cloud session can't see the UI. This loop starts `npm run dev` and drives Chrome to render
|
||||
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
name: Mobile UX Core
|
||||
description: Universal mobile UX principles for touch-first interfaces. Enforces touch targets, safe areas, and mobile-specific interaction patterns.
|
||||
metadata:
|
||||
labels: [mobile, ux, design, accessibility, cross-platform]
|
||||
triggers:
|
||||
files:
|
||||
[
|
||||
'**/*_page.dart',
|
||||
'**/*_screen.dart',
|
||||
'**/*_view.dart',
|
||||
'**/*.swift',
|
||||
'**/*Activity.kt',
|
||||
'**/*Screen.tsx',
|
||||
]
|
||||
keywords: [mobile, responsive, SafeArea, touch, gesture, viewport]
|
||||
---
|
||||
|
||||
# Mobile UX Core
|
||||
|
||||
## **Priority: P0 (CRITICAL)**
|
||||
|
||||
Universal UX principles for mobile applications.
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **Touch Targets**: Min 44x44pt (iOS) / 48x48dp (Android). Add padding if needed.
|
||||
- **Safe Areas**: Wrap content in `SafeArea`/`WindowInsets`. Avoid notches.
|
||||
- **Interactions**: Use active states (no hover). Haptic feedback (short).
|
||||
- **Typography**: Min 16sp body. Line height 1.5x.
|
||||
- **Keyboards**: Auto-scroll inputs. Set `InputType` (email/number) & `Action`.
|
||||
|
||||
## Code Examples
|
||||
|
||||
```dart
|
||||
// ✅ Correct Target
|
||||
IconButton(icon: Icon(Icons.close), padding: EdgeInsets.all(12))
|
||||
|
||||
// ❌ Too Small
|
||||
Icon(Icons.close, size: 16)
|
||||
```
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- **No Hover Effects**: Mobile has no cursor. Use pressed states.
|
||||
- **No Tiny Targets**: All clickable elements ≥44pt.
|
||||
- **No Fixed Bottom**: Account for Home Indicator & Keyboard.
|
||||
- **No OS Mix**: Use Material (Android) & Cupertino (iOS) conventions.
|
||||
|
||||
## Related Topics
|
||||
|
||||
mobile-accessibility | mobile-performance | flutter-design-system | react-native-dls
|
||||
@@ -1,149 +0,0 @@
|
||||
---
|
||||
name: scout-design
|
||||
description: "Scan a specific area of the app for design issues and improvement opportunities, then create Linear tickets for approved findings. Usage: /scout-design <area> (e.g., /scout-design settings, /scout-design bookkeeping). Evaluates against the Accounted design system for consistency, missing states, animation gaps, accessibility, and visual polish."
|
||||
---
|
||||
|
||||
# Scout Design
|
||||
|
||||
You are a design auditor for gnubok. Your job is to scan a scoped area of the application, identify design issues and improvement opportunities, and create Linear tickets for the ones the user approves.
|
||||
|
||||
## Step 1: Resolve Scope
|
||||
|
||||
The user provides an area name as an argument (e.g., "settings", "bookkeeping", "invoices").
|
||||
|
||||
Map the area to these file locations:
|
||||
- **Pages**: `app/(dashboard)/{area}/` (all page.tsx, layout.tsx files recursively)
|
||||
- **Components**: `components/{area}/` (all .tsx files recursively)
|
||||
|
||||
If the area also has sub-routes (e.g., `invoices/new`, `invoices/[id]`), include those too.
|
||||
|
||||
Valid areas based on the project structure:
|
||||
`bookkeeping`, `customers`, `expenses`, `invoices`, `supplier-invoices`, `suppliers`, `transactions`, `receipts`, `reports`, `settings`, `kpi`, `deadlines`, `help`, `pending`, `import`, `extensions`, `onboarding`, `login`, `register`
|
||||
|
||||
If the user provides an invalid area, list the valid areas and ask them to pick one.
|
||||
|
||||
## Step 2: Read and Analyze
|
||||
|
||||
Read ALL files in the resolved scope (pages + components). For each file, evaluate against the checklist below.
|
||||
|
||||
### Design Audit Checklist
|
||||
|
||||
**Consistency & Design System**
|
||||
- Are spacing values consistent (using Tailwind scale, not arbitrary values)?
|
||||
- Are colors from the design system palette (grayscale, sage green, terracotta, ochre) or are there off-palette colors?
|
||||
- Are font sizes/weights consistent with the typography system (Hedvig Letters Serif for display headings, Geist for body)?
|
||||
- Are `tabular-nums` applied to all financial/numeric data?
|
||||
- Are shadcn/ui components used where appropriate, or are there custom implementations that should use shadcn?
|
||||
- Are icon sizes consistent (15px nav, larger for empty states)?
|
||||
- Are borders full-opacity `border-border` on cards/surfaces (no opacity-suffixed border classes like `border-border/60`)?
|
||||
|
||||
**Locked UI-migration conventions (2026-07; full list in `.claude/rules/design.md`)**
|
||||
- Frame layout intact: content lives inside the rounded page panel; no per-page restyling of `MAIN_PANEL_CLASS`, no `window`-scroll assumptions on dashboard pages.
|
||||
- Page title via `PageHeader` (24px/32px serif); buttons keep the app-wide pill radius (no per-call-site `rounded-*` overrides on `<Button>`).
|
||||
- Cards are flat: no `shadow-*`, `rounded-lg` only; shadows survive only on dialogs/popovers.
|
||||
- Table rows are one line; secondary info belongs in the detail view or a click-popup, never sub-rows.
|
||||
- Chips mark exceptions only: normal states render as muted text; the same Badge on every row means the chip is wrong.
|
||||
- Attention is one ochre `.attn` sentence, never a banner; max one per page.
|
||||
- Help lives behind the "?" button after the H1; no instructional copy in the page flow.
|
||||
- One context picker per page, far right in the toolbar (`FyPicker` / `ContextPicker` chip-dropdown).
|
||||
- Primary action in the page header; actions that post or send confirm up front in a dialog instead of writing outcome text into the page.
|
||||
- `.stagger-enter` on list/table content entry (server render and client-fetch alike).
|
||||
- Overlays: centered modal to create/confirm, right slide-over to review an object.
|
||||
- Settings speak Fönster: flat hairline rows (`SettingsRows.tsx`), switches not checkboxes, dirty-only sticky save bar.
|
||||
|
||||
**Loading & Empty States**
|
||||
- Does the page/component have a loading state? (skeleton, spinner, or shimmer)
|
||||
- Is there an empty state when no data exists? (illustration, message, CTA)
|
||||
- Are loading states using skeletons (preferred) rather than plain spinners?
|
||||
|
||||
**Error Handling UI**
|
||||
- Are there error boundaries or error states shown to the user?
|
||||
- Do forms show inline validation errors?
|
||||
- Are error messages helpful and in Swedish?
|
||||
|
||||
**Animation & Motion**
|
||||
- Are list items stagger-animated on entry?
|
||||
- Do interactive elements have hover/active transitions?
|
||||
- Are transitions using the project default (`transition-colors duration-150`) without spring/overshoot?
|
||||
- Is `prefers-reduced-motion` respected?
|
||||
- Are there abrupt state changes that would benefit from a transition?
|
||||
|
||||
**Accessibility**
|
||||
- Do interactive elements have visible focus rings?
|
||||
- Is color contrast WCAG AA compliant (4.5:1 text, 3:1 UI)?
|
||||
- Is color never the sole indicator of state (paired with icons/text/shape)?
|
||||
- Are form inputs labeled (via label element or aria-label)?
|
||||
- Are clickable areas large enough for touch targets?
|
||||
|
||||
**Layout & Responsiveness**
|
||||
- Does the layout work on mobile widths?
|
||||
- Are tables horizontally scrollable on small screens?
|
||||
- Is whitespace generous but not wasteful?
|
||||
- Does dense data (tables, ledgers) use tighter but non-cramped spacing?
|
||||
|
||||
**Polish & Details**
|
||||
- Are numbers right-aligned in tables?
|
||||
- Are monetary values formatted consistently (Swedish format with kr)?
|
||||
- Are dates formatted consistently?
|
||||
- Are positive/negative amounts visually distinct?
|
||||
- Are interactive elements obviously interactive (cursor, hover state)?
|
||||
- Are disabled states visually clear?
|
||||
|
||||
## Step 3: Present Findings
|
||||
|
||||
After scanning, present findings as a numbered list. For each finding:
|
||||
|
||||
```
|
||||
### #{number}: {Short title}
|
||||
|
||||
**Area**: {area name}
|
||||
**File(s)**: {file path(s) with line numbers if relevant}
|
||||
**Category**: {Consistency | Loading State | Error Handling | Animation | Accessibility | Layout | Polish}
|
||||
**Severity**: {High | Medium | Low}
|
||||
|
||||
**What's wrong**: {1-2 sentences describing the current state}
|
||||
**What it should be**: {1-2 sentences describing the desired state}
|
||||
**Implementation notes**: {Brief technical guidance on how to fix it}
|
||||
```
|
||||
|
||||
Sort findings by severity (High first).
|
||||
|
||||
After listing all findings, ask the user:
|
||||
> "Found {N} design improvements. Create Linear tickets for: all, none, or specific numbers? (e.g., '1,3,5')"
|
||||
|
||||
## Step 4: Create Linear Tickets
|
||||
|
||||
For each approved finding, create a Linear issue using the `mcp__claude_ai_Linear__save_issue` tool with:
|
||||
|
||||
- **team**: `Gnubok`
|
||||
- **title**: Short, actionable title prefixed with area. Example: `[Invoices] Add loading skeleton to invoice list`
|
||||
- **description**: Markdown formatted:
|
||||
```markdown
|
||||
## Problem
|
||||
{What's wrong, current state}
|
||||
|
||||
## Proposed Change
|
||||
{What it should be, desired state}
|
||||
|
||||
## Implementation
|
||||
**File(s):** {file paths}
|
||||
**Category:** {category}
|
||||
|
||||
{Implementation notes}
|
||||
|
||||
---
|
||||
*Generated by /scout-design*
|
||||
```
|
||||
- **labels**: `Improvement`
|
||||
- **priority**: Map severity: High → 2, Medium → 3, Low → 4
|
||||
|
||||
After creating tickets, list them with their Linear identifiers so the user can reference them.
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Be specific. "The button looks off" is not actionable. "The primary button in InvoiceForm overrides the app-wide pill radius with `rounded-lg`" is.
|
||||
- Reference exact Tailwind classes, component names, and line numbers.
|
||||
- Don't flag things that are intentional design choices documented in `.claude/rules/design.md` or `DECISIONS.md` (e.g. the LedgerGraph always-dark panel and SalaryCalendar's categorical absence colors are sanctioned exceptions).
|
||||
- Don't suggest adding features, only flag design/UX issues with what already exists.
|
||||
- Keep findings focused on visual design, interaction design, and frontend polish. Not code quality or architecture.
|
||||
- If a component is very small or trivial (e.g., a simple redirect page), skip it.
|
||||
Reference in New Issue
Block a user