Add design-taste skill 🤖🤖🤖

docs/README.skills.md

@@ -165,6 +165,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [debian-linux-triage](../skills/debian-linux-triage/SKILL.md)<br />`gh skills install github/awesome-copilot debian-linux-triage` | Triage and resolve Debian Linux issues with apt, systemd, and AppArmor-aware guidance. | None |
 | [declarative-agents](../skills/declarative-agents/SKILL.md)<br />`gh skills install github/awesome-copilot declarative-agents` | Complete development kit for Microsoft 365 Copilot declarative agents with three comprehensive workflows (basic, advanced, validation), TypeSpec support, and Microsoft 365 Agents Toolkit integration | None |
 | [dependabot](../skills/dependabot/SKILL.md)<br />`gh skills install github/awesome-copilot dependabot` | Comprehensive guide for configuring and managing GitHub Dependabot. Use this skill when users ask about creating or optimizing dependabot.yml files, managing Dependabot pull requests, configuring dependency update strategies, setting up grouped updates, monorepo patterns, multi-ecosystem groups, security update configuration, auto-triage rules, or any GitHub Advanced Security (GHAS) supply chain security topic related to Dependabot. For pre-commit dependency vulnerability scanning in AI coding agents via the GitHub MCP Server, this skill references the Advanced Security plugin (`advanced-security@copilot-plugins`). Use this skill when an agent needs to scan dependencies for known vulnerabilities before committing. | `references/dependabot-yml-reference.md`<br />`references/example-configs.md`<br />`references/pr-commands.md` |
+| [design-taste](../skills/design-taste/SKILL.md)<br />`gh skills install github/awesome-copilot design-taste` | Apply senior designer judgment to any frontend UI — React, HTML/CSS, Framer, or any web component. This skill is the result of hands-on research into what actually works and what doesn't when giving AI agents design judgment: not theoretical guidelines, but principles battle-tested through real projects and iteration on AI-generated output. Use it whenever the user is building, reviewing, or iterating on UI code and design quality matters. Triggers include: creating components or pages, reviewing existing UI, asking for design feedback, building dashboards or data displays, refining visual hierarchy, working on Framer components, or any task where the output includes rendered interface elements. Even if the user only asks to 'make it look better' or 'clean this up', use this skill — it contains the principles that separate intentional design from generated slop. | `agents/claude.yaml`<br />`agents/openai.yaml`<br />`references/accessibility-review.md`<br />`references/component-taste.md`<br />`references/content-realism.md`<br />`references/frontend-guardrails.md`<br />`references/motion-performance.md`<br />`references/motion-taste.md`<br />`references/page-slop.md`<br />`references/polish-review.md`<br />`references/redesign-audit.md`<br />`references/shadcn-implementation.md`<br />`references/visual-dials.md`<br />`scripts/slop-scan.js` |
 | [desk-journal](../skills/desk-journal/SKILL.md)<br />`gh skills install github/awesome-copilot desk-journal` | Write, append, or read desk journal entries. The journal is persistent memory — what survives session boundaries. A good entry has: what was done, current state, next step. | None |
 | [desk-open](../skills/desk-open/SKILL.md)<br />`gh skills install github/awesome-copilot desk-open` | Create and open a new desk in the workshop. Sets up the folder structure, initial journal, and desk identity so the next session that sits down finds the trail. | None |
 | [devops-rollout-plan](../skills/devops-rollout-plan/SKILL.md)<br />`gh skills install github/awesome-copilot devops-rollout-plan` | Generate comprehensive rollout plans with preflight checks, step-by-step deployment, verification signals, rollback procedures, and communication plans for infrastructure and application changes | None |

skills/design-taste/agents/claude.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Design Taste"
+  short_description: "Senior UI taste for frontend work"
+  skill_file: "skills/design-taste/SKILL.md"
+  default_prompt: "Use $design-taste to refine this interface and make it feel intentional."

skills/design-taste/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Design Taste"
+  short_description: "Senior UI taste for frontend work"
+  default_prompt: "Use $design-taste to refine this interface and make it feel intentional."

skills/design-taste/references/accessibility-review.md

@@ -0,0 +1,92 @@
+# Accessibility Review
+
+Use this when working on interactive UI, forms, dialogs, menus, tabs, dropdowns, focus states, icon-only controls, hidden content, or screen reader behavior.
+
+## Priority Order
+
+1. Accessible names.
+2. Keyboard access.
+3. Focus management.
+4. Semantics.
+5. Forms and errors.
+6. Announcements.
+7. Contrast and state clarity.
+8. Media and motion.
+
+## Accessible Names
+
+- Every interactive control needs an accessible name.
+- Icon-only buttons need `aria-label` or `aria-labelledby`.
+- Inputs, selects, and textareas need visible labels or programmatic labels.
+- Links need meaningful text. Avoid "click here".
+- Decorative icons should be hidden from assistive tech.
+- Meaningful images need accurate alt text. Decorative images use empty alt text.
+
+## Keyboard Access
+
+- Use native `button`, `a`, `input`, `select`, and `textarea` before role-based workarounds.
+- Every interactive element must be reachable by keyboard.
+- Focus must be visible for keyboard users.
+- Do not use `tabindex` greater than 0.
+- Escape should close dialogs, menus, popovers, and overlays when applicable.
+- Hover-only content needs a keyboard path.
+
+## Focus And Dialogs
+
+- Modals must trap focus while open.
+- Restore focus to the trigger on close.
+- Set an intentional initial focus inside dialogs.
+- Opening a dialog should not unexpectedly scroll the page.
+- Route or major view changes should move focus to the main content area when appropriate.
+
+## Semantics
+
+- Use landmarks: `header`, `nav`, `main`, `section`, `article`, `aside`, `footer`.
+- Do not skip heading levels for visual styling.
+- Lists should use `ul`/`ol` with `li`.
+- Data tables need table semantics and header cells.
+- Do not add ARIA when native semantics already solve the problem.
+
+## Forms And Errors
+
+- Place errors next to the field.
+- Link error text with `aria-describedby`.
+- Set `aria-invalid` when a field is invalid.
+- Required fields should be announced.
+- Helper text should be associated with the input.
+- Disabled submit actions should explain what is missing.
+- After submit failure, focus the first invalid field or provide an error summary.
+
+## Announcements
+
+- Critical form errors should use `aria-live` or `role="alert"`.
+- Loading regions can use `aria-busy` or visible status text.
+- Toasts should not be the only way to communicate critical information.
+- Expandable controls need `aria-expanded` and, when applicable, `aria-controls`.
+
+## Contrast And States
+
+- Normal text needs at least 4.5:1 contrast. Large text (24 px, or 18.7 px bold) needs 3:1.
+- Icons, input borders and focus indicators that carry meaning need 3:1 against what's next to them.
+- Disabled controls, decorative text and logos are exempt. A disabled control still explains why it's disabled.
+- Measure each text style on each surface it appears on: hover backgrounds, tinted rows, cards on cards.
+
+## Targets
+
+- WCAG 2.2 AA (2.5.8): at least 24×24 CSS px, or enough spacing that a 24 px circle centred on each target doesn't touch another. Inline links in text are exempt.
+- 44×44 is Apple's HIG and WCAG AAA (2.5.5): use it for primary actions on touch screens, not as a rule for every icon in a dense tool.
+- Don't report a 20 px icon button with room around it as an AA failure; report it as a touch comfort issue if the screen is touch-first.
+- Focus, hover, selected, disabled, loading, and error states must be distinguishable.
+- Do not communicate state by color alone.
+- Never remove focus outlines without an equally visible replacement.
+
+## Motion And Media
+
+- Respect `prefers-reduced-motion`.
+- Avoid autoplaying media with sound.
+- Video with speech should provide captions when relevant.
+- Do not rely on motion alone to convey information.
+
+## Tool Boundaries
+
+Prefer minimal targeted fixes. Do not refactor unrelated UI or migrate primitive libraries unless the user asked for that.

skills/design-taste/references/component-taste.md

@@ -0,0 +1,191 @@
+# Component Taste Guide
+
+Framework-agnostic reference for common UI patterns. For each component: what good looks like, and the mistakes AI-generated UI consistently makes.
+
+---
+
+## Cards
+
+**Good taste:**
+- Generous internal padding. Content breathes, doesn't press against edges.
+- Clear hierarchy: one heading, one supporting detail, one action. In that order.
+- Visual weight concentrated at the top (image or heading) with details flowing downward.
+- Consistent card dimensions in a grid. Alignment communicates system.
+- Subtle shadow for elevation — soft and nearly invisible. For convincing depth, layer two shadows: a tight ambient shadow plus a softer directional one.
+- Avoid visible borders for containment. Shadows feel lighter and more modern.
+- Hover state that's subtle (slight shadow increase), not dramatic.
+- Color accents belong *inside* the card (colored titles, values, or small dot indicators next to labels). Never as a colored top-border on a rounded card.
+
+**Common AI mistakes:**
+- Cramming 5–6 elements into one card (badge + icon + title + subtitle + description + two buttons + status + timestamp). No hierarchy, just inventory.
+- Every card has a different internal structure, breaking grid rhythm.
+- Loud, saturated gradient backgrounds on every card.
+- Equal visual weight on all text; no distinction between heading and metadata.
+- Rounded corners so large the card looks like a pill.
+- Colored top-border accents on rounded cards. The straight accent line clashes with curved corners and reads as dated.
+- Using `border: 1px solid` for card containment instead of a soft shadow.
+
+---
+
+## Modals / Dialogs
+
+**Good taste:**
+- One focused task or decision. A modal should do one thing.
+- Clear title that states the action ("Delete this project?" not "Confirm").
+- Obvious dismiss path: close button AND clicking overlay AND escape key.
+- Overlay with backdrop blur preserves spatial context.
+- If not using blur, overlay contrast sufficient to separate modal from page (typically 50–70% opacity black).
+- Primary action button reflects the action's nature (destructive = red, confirmation = primary color).
+
+**Common AI mistakes:**
+- Using modals for content that should be a page (long forms, multi-step flows, scrollable content).
+- No visual hierarchy inside. Flat list of fields or text with uniform styling.
+- Confirmation modals that say "Are you sure?" without stating what will happen.
+- Two buttons that look identical for destructive vs. safe actions.
+- Missing escape hatch — no way to close without making a decision.
+
+---
+
+## Tables / Data Grids
+
+**Good taste:**
+- Right-aligned numbers, left-aligned text. Column alignment matches data type.
+- Clear header row with visual weight distinguishing it from data rows.
+- Alternating row backgrounds OR subtle row dividers, not both.
+- Cell padding that allows scanning without cramming (minimum 12px vertical per row).
+- Sortable columns indicated clearly (icon + current sort state visible).
+
+**Common AI mistakes:**
+- Everything center-aligned regardless of data type.
+- Dense rows with no breathing room.
+- Every column the same width regardless of content.
+- Heavy borders on every cell creating a spreadsheet feel.
+- No distinction between primary data columns and secondary/metadata columns.
+
+---
+
+## Forms
+
+**Good taste:**
+- Logical grouping. Related fields together, separated by spacing or section headings.
+- Labels above inputs (not placeholder-as-label, which disappears on focus).
+- Error messages adjacent to the field, not in a banner at the top.
+- Clear required vs. optional distinction (mark the minority).
+- Progressive disclosure. Don't show 20 fields when 5 are relevant to start.
+
+**Common AI mistakes:**
+- Flat list of fields with no grouping or visual rhythm.
+- Using placeholder text as labels (accessibility failure + UX failure).
+- All fields same width regardless of expected content.
+- Submit button that doesn't reflect the action ("Submit" instead of "Create Account").
+- No indication of progress in multi-step forms.
+
+---
+
+## Navigation
+
+**Good taste:**
+- Clear indication of current location. Active state visually distinct — not just a color change, use inversion for strongest signal.
+- Reasonable depth. Primary nav visible, secondary nav revealed in context.
+- Consistent position. Nav shouldn't move or restructure between pages.
+- Mobile nav that's accessible and doesn't require complex gestures.
+
+**Common AI mistakes:**
+- Too many items at the top level (8+ primary nav items competing for attention).
+- Active state is a subtle font-weight or color change that's hard to spot.
+- Icon-only nav with no labels and no tooltips.
+- Hamburger menu on desktop when there's room for visible navigation.
+- Dropdowns nested 3+ levels deep.
+
+---
+
+## Buttons
+
+**Good taste:**
+- Clear primary/secondary/tertiary hierarchy. One style dominates, others support.
+- Button text describes the action ("Save Changes" not "Submit", "Delete Project" not "OK").
+- Size proportional to importance and context.
+- Adequate padding. Horizontal padding > vertical padding.
+- The "Label, Qualifier" pattern for primary CTAs: "Get Started, It's Free" or "Download, No Credit Card."
+- Disabled state clearly non-interactive (reduced opacity + cursor change).
+
+**Common AI mistakes:**
+- Multiple button styles with no clear hierarchy (filled + outlined + ghost + icon all at the same level).
+- Generic labels ("Submit", "OK", "Click Here", "Yes").
+- Primary buttons too small to tap on mobile (under 44px height); anything under 24px without spacing fails WCAG AA.
+- Decorative button treatments (gradients, shadows, animated borders) on every button.
+- "Cancel" and "Delete" styled identically.
+
+---
+
+## Empty States
+
+**Good taste:**
+- Explains what will appear here and how to populate it.
+- Single clear CTA to take the first action.
+- Tone matches the product — warm and encouraging, not clinical.
+- Illustration or icon is supplementary, not the focal point.
+- Vertically centered in the available space.
+
+**Common AI mistakes:**
+- Just "No data" or "No results found" with no guidance.
+- Generic illustration with no relationship to the feature.
+- Empty state styled completely differently from the populated state.
+- Multiple CTAs competing in a single-focus moment.
+- Tiny text lost in a huge empty container.
+
+---
+
+## Status Indicators / Badges
+
+**Good taste:**
+- Semantic color: green=success, yellow=warning, red=error, blue=info, gray=neutral.
+- Readable at small sizes. Sufficient contrast between badge background and text.
+- Consistent shape and size across the application.
+- Used sparingly. If every item has 3 badges, none of them stand out.
+- Text labels that are scannable ("Active", "Pending", "Failed").
+
+**Common AI mistakes:**
+- Rainbow of badge colors with no semantic meaning.
+- Badges so small the text is illegible.
+- Too many badges per item — status + category + priority + type = noise.
+- Using badges for information that should be in a column.
+- Inconsistent styling across badges in the same UI.
+
+---
+
+## Toasts / Notifications / Alerts
+
+**Good taste:**
+- Minimal. Just enough text to confirm the action or communicate the issue.
+- Auto-dismiss for confirmations (3–5 seconds). Persist for errors until dismissed.
+- Positioned consistently (top-right or bottom-center — pick one).
+- Don't block interaction with the page underneath.
+- Semantic styling for success/error/warning/info.
+
+**Common AI mistakes:**
+- Toast text that's a full sentence when 3 words would do.
+- Stacking 5+ toasts that obscure page content.
+- Error toasts that auto-dismiss before users can read them.
+- Using toasts for validation errors that should be inline.
+- Identical styling for success and error, only differentiated by text.
+
+---
+
+## Dashboards
+
+**Good taste:**
+- Clear information hierarchy. KPIs/summary at the top, detailed data below.
+- Cards sized proportional to importance.
+- Scannable at a glance. Overall status readable in 3 seconds.
+- Consistent card styling within the dashboard.
+- Meaningful empty space between sections.
+- A subtle gradient bloom behind the primary chart area adds warmth without competing with data.
+
+**Common AI mistakes:**
+- Every card the same size regardless of content importance.
+- Too many metrics with no hierarchy (12 KPI cards that all look identical).
+- Charts with no context (a line going up — is that good or bad?).
+- Dense layout with no breathing room between sections.
+- Decorative chart types (3D pie, radial gauges) that obscure rather than clarify.
+- Color-coding that requires a legend to decode instead of using semantic colors.

skills/design-taste/references/content-realism.md

@@ -0,0 +1,88 @@
+# Content Realism
+
+Use this when generating copy, examples, mock data, names, metrics, testimonials, product labels, empty states, errors, or placeholders.
+
+## Principle
+
+Mock content should feel like draft production content, not filler. Users judge quality through words and data as much as layout.
+
+## Names And Brands
+
+Avoid:
+
+- John Doe, Jane Smith, Sarah Chan.
+- Acme, Globex, Nexus, SmartFlow, Nova, Apex when they are contextless.
+- Generic team names like Design Team, Product Team, Marketing Team when specificity would help.
+
+Use:
+
+- Names that fit the product's locale, market, and audience.
+- Brand names with a concrete category or metaphor.
+- Team names tied to actual workflows: Revenue Ops, Claims Review, Studio Booking, Vendor Risk.
+
+## Metrics And Data
+
+Avoid:
+
+- `99.99%`, `50%`, `100%`, `$100.00`, `1234567`.
+- Identical dates across lists.
+- Perfectly round chart values.
+- Tables where every row is the same length and shape.
+
+Use:
+
+- Organic but plausible values: `47.2%`, `18.6 days`, `$98.40`, `1,284`, `+12.7%`.
+- Mixed dates, durations, and statuses.
+- Numbers that support the story of the interface.
+- Tabular figures for data-heavy UI.
+
+## Copy
+
+Avoid:
+
+- Elevate, Seamless, Unleash, Next-Gen, Game-changer, Delve, Tapestry, Revolutionary, Cutting-edge.
+- "Oops!" for serious errors.
+- Exclamation marks in routine success messages.
+- Placeholder Latin text.
+- Button labels like Submit, OK, Click Here, Learn More when a clearer verb exists.
+
+Use:
+
+- Concrete verbs: Create, Save changes, Invite vendor, Review claim, Export CSV, Start check.
+- Direct errors: "Connection failed. Try again." or "Password must be at least 8 characters."
+- Helpful empty states: what belongs here, why it is empty, and the one next action.
+- Sentence case by default unless the design system specifies otherwise.
+
+## Avatar And Media Placeholders
+
+Avoid:
+
+- Reusing the same avatar for multiple people.
+- Generic user icons for people-heavy products.
+- Unreliable image URLs.
+- Stock-looking imagery when the product requires trust or inspection.
+
+Use:
+
+- Unique seeds per person or object.
+- Realistic initials or generated avatars when photos are not appropriate.
+- Product-specific placeholder imagery.
+- Consistent art direction across all media.
+
+## Empty States
+
+An empty state should answer:
+
+- What will appear here?
+- Why is it empty right now?
+- What can the user do next?
+
+Keep it short. One primary action is usually enough.
+
+## Error And Success Tone
+
+- Be calm and specific.
+- Explain recovery.
+- Do not blame the user.
+- Do not over-celebrate routine actions.
+- Put the message near the relevant control when possible.