| name | uncodixfy |
| description | Anti-Codex UI correction skill for removing generic AI/Codex visual patterns from app screens: soft gradients, glass panels, oversized radii, fake dashboards, decorative copy, hero blocks inside products, blue-purple SaaS defaults, and overdesigned AI-looking UI. |
| layer | utility |
| category | design |
| triggers | ["/uncodixfy","uncodixfy","uncodexify","uncodexy","fix codex ui","codex ui","generic ai ui","ai looking ui","ai-generated ui","too generic","looks ai generated","make it less ai","remove ai aesthetic","boring dashboard","overdesigned ui","uncodexify ui"] |
| linksTo | ["ultra-ui","ux-compiler","ui-polish","design-kit","accessibility"] |
Uncodixfy
Use this skill whenever UI work risks looking like default AI/Codex output. It is not a prettier-theme pass. It is a start-of-work reasoning gate that forces the agent to identify generic visual habits, reject them before layout decisions, and build a product-specific interface from the existing app context.
Inspired by cyxzdev/Uncodixfy (MIT) and merged with the UltraThink ultra-ui pipeline.
Required Flow
-
Start with the Uncodixfy gate.
Before writing UI code, naming components, selecting colors, or sketching layout, write:
- What would Codex probably generate by default?
- Which of those moves are banned for this screen?
- What normal product pattern will replace each banned move?
- Which existing app tokens/components should be reused?
- Which docs/design sources are product-relevant, token-only, architecture-only, guideline-only, stale, or ignored?
-
Inspect the current product surface.
Read existing layout, tokens, components, typography, navigation, density, and interaction patterns before inventing a style.
-
Write the smell pass into the task ledger.
For substantial UI work, save the gate in the task ledger or generated UNCODIXFY.md. Do this before implementation, not as a final polish note.
-
Separate design contracts cleanly.
Keep DESIGN.md as the token and visual-system contract. Put product intent, user journey, IA, page shell, states, accessibility, implementation constraints, Codex rules, and anti-patterns in DESIGN-CONTRACT.md.
-
Chain the design reasoning.
For non-trivial UI, run ux-compiler -> ultra-ui -> uncodixfy before coding. Keep the user journey and anti-generic constraints visible while implementing.
-
Normalize the product structure.
Prefer normal application UI: durable sidebar or header when needed, clear page titles, direct controls, simple tables/forms/lists, predictable responsive zones, and real states.
-
Use existing design tokens first.
Existing project colors, spacing, radius, typography, components, and icon systems win. If no system exists, choose a restrained palette and document why.
-
Implement only purposeful polish.
Every visual layer must clarify hierarchy, state, affordance, trust, or product identity. Remove decoration that only makes the UI look expensive.
-
Verify against the anti-Codex checklist.
If a local app can run, use screenshots. Otherwise do a file-level review of layout, tokens, states, and copy.
Start Gate Template
# Uncodixfy Start Gate
## Lazy Codex Output I Must Avoid
- Structure:
- Surface:
- Shape:
- Copy:
- Data display:
- Motion:
- Color/type:
## Replacements
- Structure:
- Surface:
- Shape:
- Copy:
- Data display:
- Motion:
- Color/type:
## Existing Product Sources
- Tokens:
- Components:
- Accepted product/page docs:
- Token-only docs:
- Architecture/codebase docs:
- Ignored/stale docs:
- Navigation/layout:
- Typography:
- States:
## Banned For This Screen
- ...
Hard Bans
- No glassmorphism, floating gradient shells, frosted panels, random blur haze, glows, conic donuts, or bokeh decoration by default.
- No oversized radii, pill overload, dramatic shadows, gradient borders, hover transforms, or animated shape gimmicks.
- No dashboard hero sections, startup-eyebrow copy, decorative page subtitles, fake command-center language, or generic SaaS marketing prose inside product UI.
- No KPI-card grid, fake charts, quota/progress panels, badge spam, status dots, or trend indicators unless the product workflow truly needs them.
- No blue-purple dark SaaS default, beige sandwich mobile stack, muted gray-blue contrast wash, or invented palette when the app already has tokens.
- No nested card-in-card panel stacks or detached sidebars unless the existing product architecture requires them.
- No uppercase eyebrow labels, letter-spaced muted labels, decorative mini-notes, explanatory section slogans, or "live pulse/operator checklist" voice unless it is product-native.
- No default font shortcut such as Inter/Roboto/Arial/system-safe "premium" typography unless the project already uses it.
- No decorative right rails, workspace promos, quota panels, progress bars, nav badges, trend chips, colored dot pseudo-elements, or footer meta lines unless they are functional.
- No leaking docs paths, architecture terms, guideline names, internal feature labels, or repository taxonomy into user-facing copy.
Smell Taxonomy
| Area | Codex Default | Uncodixfy Replacement |
|---|
| Structure | Hero strip, KPI grid, detached rail, nested panels | Object-first app shell, clear work area, only useful context rails |
| Surface | Glass, gradients, glows, blur haze, dramatic shadows | Solid surfaces, 1px borders, small shadows only when depth is functional |
| Shape | Pills everywhere, 20-32px radii, rounded shells | 8-12px component radius, square enough to feel like software |
| Copy | Eyebrows, slogans, decorative section notes | Plain labels, action-oriented headings, product-native language |
| Data | Fake charts, quota bars, status badges, trend chips | Real data density, simple tables/lists, fewer labels with stronger hierarchy |
| Motion | Translate-on-hover, bouncy reveals, sliding tabs | 100-200ms color/opacity/focus changes |
| Color | Blue-purple SaaS, gray-blue low contrast, random accents | Existing tokens first, restrained palette second, semantic contrast always |
| Sources | Treating any DESIGN.md or docs path as page intent | Classify docs first; use architecture only for constraints and design docs only for tokens unless page-specific |
Normal UI Standard
- Sidebars: 240-260px, fixed when needed, solid surface, simple border, no floating shell.
- Headers: direct h1/h2 hierarchy, useful actions near the object they affect, no ornamental labels.
- Buttons: solid or bordered, 8-10px radius, clear icon/text usage, no gradients unless brand-native.
- Cards: 8-12px radius max, subtle border, low shadow, one responsibility per card.
- Forms: clear labels, stable dimensions, visible validation, simple focus rings.
- Tables/lists: readable rows, left-aligned content, functional filters/sorting, no filler badges.
- Motion: 100-200ms opacity/color/focus changes; no transform movement unless it explains state.
- Icons: existing library first, 16-20px, consistent stroke, decorative icon containers only with a real semantic role.
Conversion Rule
When you catch a banned move, do not merely delete it. Convert it:
- Gradient hero -> normal page header plus first real workflow object.
- KPI card grid -> compact status row, table summary, or task list tied to current work.
- Decorative right rail -> inspectable details panel only when selected state needs it.
- Fake chart -> actual chart with provenance, or a simple list if no data exists.
- Badge spam -> one semantic status column or filter.
- Hover transform -> color, border, or focus state.
- Copy slogan -> direct object label or action instruction.
Quality Gate
Before delivery, answer:
- What generic AI UI move did I remove?
- Which existing app token/component did I reuse?
- What user workflow became clearer?
- Which states are covered?
- Would this still make sense without decorative polish?
If the answer is mostly "colors, shadows, radius, and animation", the UI still looks Codex-generated. Rework it.