ui-redesign
Skill0 starsChanged 3 months agoMITView on GitHub
Transform a website's UI from generic/"AI-generated"-looking to professional, considered, designer-and-developer-quality — for ANY language, framework, or CMS. Detects the existing stack (or asks which language/framework/CMS if starting fresh), checks for and applies any other installed design skills (e.g. frontend-design), audits the current UI against a checklist of "looks AI-generated" tells, proposes a lightweight creative direction (palette, type, layout/motion principles) for approval, then implements the full redesign across the site. Trigger this whenever the user asks to make a site "look more professional", "not look AI-generated", "look like it was designed by a real designer", wants a UI/UX overhaul, visual redesign, or a "make this look better" pass — regardless of the tech stack involved.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- Achref23illi/ui-redesigntheir own version, first seen Nov 8, 2026
- rashee1997/ui-redesigntheir own version, first seen Oct 17, 2026
- neeraj181-dot/ClaudeSkillstheir own version, first seen Aug 25, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- Achref23illi/ui-redesign★ 3same name
- rashee1997/ui-redesign★ 2same name
- neeraj181-dot/ClaudeSkills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository2 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 5 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Check the project for what it's actually built with before assuming anything:
- Very specific: line 19
If none of this is found (empty/new project), ask the user which language/framework/CMS to use before doing anything else — don't assume …
- Very specific: line 27
Read through the current site's key pages/components and check them against references/ai-generated-tells.md.
- Distinctive: line 33
Keep this audit short — a few bullet points, not an essay.
- Distinctive: line 37
Ask a *short* set of lightweight questions to inform direction — but don't block on them:
- Distinctive: line 44
If the user skips or gives a thin answer, don't stall — make a bold, considered creative call yourself based on the project's actual …
- Distinctive: line 59
Write or rewrite copy where it's genuinely generic/placeholder, in the business's actual voice — but don't invent facts about the business.
- Very specific: line 71
No screenshot/visual-QA step in this skill — judgment is based on code/markup/design-token review, not rendered screenshots.
- Very specific: line 73
If the project already has a frontend-design (or similar) skill installed, its constraints win where the two overlap (e.g.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Professional UI Redesign & Enhancement
Goal: take a site that looks templated/AI-generated and make it look like it was designed by a skilled UI/UX designer and built by a skilled developer — working in whatever language/framework/CMS the project actually uses. This is a two-phase skill: propose creative direction first, implement only after approval.
Step 0 — Detect the stack, or ask if starting fresh
Check the project for what it's actually built with before assuming anything:
package.json→ React/Next.js/Vue/Nuxt/Svelte/Astro + which CSS approach (Tailwind config, CSS Modules, styled-components, plain CSS/SCSS)composer.json/wp-config.php/ theme folder → WordPress (check for apd_-style custom theme, ACF, block theme vs classic)Gemfile→ Jekyll,config.rb→ Middleman, other static-site generators- Plain
index.html/css/→ static HTML/CSS/JS site - CMS config files (
sanity.config,contentful,payload.config, etc.)
If none of this is found (empty/new project), ask the user which language/framework/CMS to use before doing anything else — don't assume Next.js or any default.
Step 1 — Check for other installed design skills and use them
Before designing anything, check what other skills are available in this environment (e.g. via the skill listing, /mnt/skills/, or an .agents/skills/ directory) for anything design-related — most importantly frontend-design if installed, but also any brand-guidelines, design-system, or component-library skill. Read and apply their guidance (design tokens, styling constraints, brand colors/fonts) as the foundation — this skill's job is the creative direction and full-site execution on top of that foundation, not a replacement for it.
Step 2 — Audit the current UI
Read through the current site's key pages/components and check them against references/ai-generated-tells.md. Note specifically, with examples from the actual codebase (not generic complaints):
- Which layout patterns feel templated (uniform centered sections, identical card grids, etc.)
- What the current color palette and type choices actually are, and whether they're generic framework defaults
- Where copy is generic/safe vs. specific to the business
- What's already good and should be kept, not just what's wrong
Keep this audit short — a few bullet points, not an essay. It sets up Phase 1, it isn't the deliverable.
Step 3 — Phase 1: Propose creative direction (lightweight ask, then defaults)
Ask a short set of lightweight questions to inform direction — but don't block on them:
- Industry/what the business actually does (skip if already obvious from the project content)
- Any existing brand constraints: must-keep colors, logo, fonts, or is this a full creative reset?
- Any reference sites/aesthetics they admire (optional)
- Overall vibe in a word or two if they have one (e.g. "warm and editorial", "sharp and technical", "minimal luxury") — optional
If the user skips or gives a thin answer, don't stall — make a bold, considered creative call yourself based on the project's actual content/industry (from Step 0-2), and say so plainly rather than defaulting to something generic.
Then present a concise creative direction, short enough to approve in one read:
- Palette: primary + 1-2 accents + neutral scale, with actual hex values and why they fit the business — not generic SaaS-purple
- Type pairing: display/heading face + body face, and why they contrast well
- Layout/motion principles: 2-4 concrete rules this redesign will follow (e.g. "break the centered-grid habit in the hero and one feature section", "vary section density instead of uniform padding", "one recurring visual motif: ___")
- One differentiating idea: something specific that will make this site not look like every other one in its category
Wait for approval or tweaks before writing any implementation code. Small requested changes to the direction are fine to fold in without re-asking everything.
Step 4 — Phase 2: Implement, in the project's real language/framework
Once the direction is approved, implement it across the site using the project's actual stack (from Step 0) and any design-system skill from Step 1:
- Establish real design tokens (colors, type scale, spacing scale, radii, shadows) as actual variables/config in the project's idiom (Tailwind config, CSS custom properties, SCSS variables, theme.json for WP block themes, etc.) — not one-off inline values
- Rebuild components/templates to follow the approved layout/motion principles, not just reskin colors on the existing generic structure
- Write or rewrite copy where it's genuinely generic/placeholder, in the business's actual voice — but don't invent facts about the business; ask if unsure
- Carry the approved palette/type/motif through consistently: hero, nav, cards, forms, footer, states (hover/focus/empty/error) — inconsistency is itself a tell
- Respect accessibility: real contrast ratios, focus states, semantic markup — a professional design is an accessible one
Work through the site systematically (page by page or component by component) rather than one giant unreviewable diff, especially on larger sites.
Step 5 — Self-review before calling it done
Re-check the finished work against references/ai-generated-tells.md — specifically the "what NOT-AI-generated looks like instead" section. If several tells are still present, don't call it finished — go back and fix them. Note any places you deliberately kept something "generic" because it was the right call (e.g. a standard, accessible form pattern), and why.
Notes
- No screenshot/visual-QA step in this skill — judgment is based on code/markup/design-token review, not rendered screenshots. Be extra rigorous in Step 5 to compensate: read the actual spacing values, actual hex codes, actual component structure, don't just skim.
- This skill is intentionally stack-agnostic. Don't default to React/Tailwind out of habit — use what Step 0 found, or what the user chose for a fresh project.
- If the project already has a
frontend-design(or similar) skill installed, its constraints win where the two overlap (e.g. its color-token rules, its available Tailwind classes) — this skill supplies the creative direction and site-wide execution around that foundation.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

