Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-08-26 02:35:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: publish from main

Browse Source
This commit is contained in:
github-actions[bot]
2026-08-24 01:35:29 +00:00
parent 132c269612
commit c603ecd0a3
33 changed files with 821 additions and 189 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/anti-ui-slop/SKILL.md
+35 -86
View File
@@ -1,109 +1,58 @@
---
name: anti-ui-slop
description: 'Stop Codex, GitHub Copilot, Claude Code, and Cursor from shipping generic UI. Use UIZZE’s public catalogue of 800,000+ real web and iOS screens to extract product-specific design decisions and enforce a hard finish gate for web and iOS interfaces.'
description: 'Stop coding agents from shipping generic UI. Use UIZZE''s 800,000+ real web and iOS screens to build product-specific interfaces, define a design contract, cover required states, and run a hard finish gate. Use when designing, implementing, redesigning, critiquing, or pre-ship reviewing a web or iOS interface in Codex, Claude Code, Cursor, Copilot, or another coding agent. Trigger with "anti-ui-slop", "stop UI slop", "ground this UI in real screens", or "run the UI finish gate".'
license: MIT
metadata:
version: "1.2.13"
author: "UIZZE <business@uizze.com>"
compatibility: "Designed for Claude Code, Codex, Cursor, and GitHub Copilot; works in any agent that can read project files and fetch a URL."
tags: "ui-design, design-system, design-review, frontend, web-ui, ios-ui"
---
# Anti UI Slop
> **Stop AI coding agents from shipping generic UI.**
Use this skill when building, refactoring, or reviewing a web or iOS interface. The goal is not to make a generic layout prettier. The goal is to make the interface visibly belong to this product, support its real user job, and behave correctly in every important state.
# Stop Making UI Slop
Browse 800,000+ real web and iOS screens at https://uizze.com before choosing a layout.
Build product-specific UI with 800,000+ real web and iOS screens via [UIZZE](https://uizze.com).
The workflow is instruction-only. It does not execute third-party code or require credentials.
![Stop Making UI Slop with UIZZE](https://uizze.com/landing/anti-ui-slop-skill-banner.png)
## 1. Inspect the Product Before Designing
## Overview
Read the repository and identify:
Use the product brief, existing UI, components, and local design system to make intentional interfaces. Uizze supplies focused design guidance and, when useful, a small number of relevant visual references.
- the primary user and the job this screen must complete;
- the single primary action and the information needed before taking it;
- the existing component library, design tokens, typography, and layout conventions;
- real product nouns, workflows, constraints, and data already present in the codebase;
- required loading, empty, error, partial, success, disabled, and permission states;
- relevant mobile, tablet, desktop, keyboard, and assistive-technology behavior.
## Prerequisites
Do not invent product requirements, analytics, user research, or hidden states.
- A screen or component to build, redesign, or review — a file path or a short description.
- The product's existing components, design tokens, and visual language, so the build extends them instead of inventing a new system.
- Optional access to the paid Uizze MCP for focused references and hosted materials.
## 2. Collect Real Interface Evidence
## Authentication
Search the public catalogue at https://uizze.com and select three to five relevant web or iOS screens. Prefer references that match the target workflow, information density, navigation model, or interaction pattern—not merely its industry or color palette.
- The free skill and public catalogue work without an account, token, MCP connection, dependency, script, or executable.
- The optional full UIZZE MCP may use the host's normal connection and authentication flow. Never claim it is connected without an actual host result.
For each reference, record:
## Work from the product
1. the screen or flow and its source link;
2. the structural decision worth transferring;
3. why that decision fits this product;
4. what must not be copied.
Read the brief, existing UI, components, tokens, and constraints before designing. They always outrank this skill. Keep familiar interaction conventions and make the product's own objects, workflow, and priorities visually clear. Do not add novelty for its own sake.
Transfer hierarchy, workflow shape, density, navigation, control behavior, responsive treatment, and state handling. Never copy another product’s branding, proprietary text, imagery, or exact layout.
## Load one playbook
If catalogue browsing is unavailable, ask the user for two or three UIZZE links or screenshots. If they cannot provide them, continue from repository evidence and label the missing reference evidence explicitly.
Choose at most one file for the current request:
## 3. Write a Design Contract
- New interface or major redesign: `reference/new-work.md`
- Product or dashboard work: `reference/operate.md`
- Refinement and polish: `reference/polish.md`
- Simplification or distillation: `reference/distill.md`
- Explicit audit: `reference/audit.md`
- Native iOS work: `reference/ios.md`
Before changing code, write a short contract with these fields:
Do not load a second playbook. Apply judgment rather than treating its examples as a checklist.
| Field | Decision |
| --- | --- |
| Screen job | The one outcome this screen enables |
| Primary user and action | Who acts, and what they do |
| Content hierarchy | What must be understood first, second, and third |
| Navigation and controls | Product-specific structure and interaction model |
| Visual language | Type, spacing, density, surfaces, imagery, and motion rules |
| Required states | Loading, empty, error, partial, success, disabled, permission |
| Responsive behavior | What changes across supported widths and input modes |
| Evidence used | Reference links and transferable decisions |
| Forbidden defaults | Generic patterns that would erase product specificity |
| Acceptance criteria | Observable conditions required before shipping |
## Optional Uizze evidence
The contract must name concrete choices. “Clean,” “modern,” “intuitive,” and “premium” are not design decisions.
Read `references/uizze-reference-policy.md` before using the paid MCP. It exposes exactly `find_ui_references` and `find_ui_materials`. Use them only when a concrete unresolved visual or material question would benefit from evidence. If they return nothing, continue silently.
## 4. Build in the Product’s Language
## Finish
- Reuse the repository’s components and semantic tokens before adding new ones.
- Make the primary action visually and structurally obvious.
- Use product-specific labels and information rather than placeholder metrics or generic copy.
- Keep repeated cards only when the content is genuinely a repeated collection.
- Add decoration, motion, badges, or elevation only when they communicate state or hierarchy.
- Implement every required interaction and state; do not leave convincing-looking inert controls.
- Preserve accessibility semantics, focus order, contrast, touch targets, and reduced-motion behavior.
## 5. Run the Finish Gate
Render the result at every supported breakpoint and block completion when any item fails:
### Product specificity
- Could this interface belong to an unrelated product after changing the logo?
- Does the hierarchy reflect the real user job and product data?
- Are there interchangeable dashboard cards, filler metrics, vague headings, or generic calls to action?
### Interaction completeness
- Do all visible controls have a real outcome?
- Are loading, empty, error, success, disabled, and permission states implemented where applicable?
- Are destructive, irreversible, or sensitive actions confirmed appropriately?
### Responsive and accessible behavior
- Does the layout remain usable without merely stacking every region vertically?
- Do keyboard navigation, focus visibility, semantics, contrast, and touch targets pass inspection?
- Does content remain readable at zoom and with longer real-world text?
### Design-system integrity
- Are local tokens and components used consistently?
- Is every new visual rule justified by the design contract?
- Is borrowed evidence transformed into this product’s own visual language?
Fix every blocking failure and re-run the gate before declaring the UI complete.
## 6. Handoff Format
Report the finished work in this order:
1. **Evidence:** the references and decisions that influenced the result.
2. **Contract:** the final product-specific design rules.
3. **Implementation:** the meaningful interface and behavior changes.
4. **Verification:** breakpoints, interaction states, and accessibility checks performed.
5. **Remaining risks:** anything that could not be verified, without overstating completion.
Complete the requested scope. When the environment supports it, render and inspect once. Fix observable breakage such as clipping, overlap, distorted media, inaccessible controls, or inert interactions. Keep the handoff concise.