Uncodixfy: a rule file for stripping the tells out of generated UI

One markdown file whose job is prohibition

The premise is stated more bluntly than most project descriptions allow. The README opens with the claim that GPT is surprisingly bad at UI design, and then argues that if you ask it to generate interfaces long enough, the same bad design patterns start repeating. Floating cards. Oversized rounded corners. Gradient-heavy dashboards. Decorative labels everywhere. Glass panels. After a while you can recognize a GPT UI immediately.

That list is the whole diagnosis, and it is a useful one because those are patterns with no functional justification. A floating card does not hold data that could not live in a table. A gradient does not communicate a state that a border would not. The reason they appear is that they are common in the training material, and a model asked for a modern-looking interface will reproduce the visual average of that material whether or not it suits the task.

So the approach is subtraction. `Uncodixfy.md` is a rule set that blocks the patterns a model almost always falls back on and pushes it toward what the README calls more normal interfaces. The author is explicit that it does not try to teach the model how to design, and that it mostly just tells it what not to do. That is a much smaller promise than most tools in this space make, and it is the reason the file is short enough to actually read.

Installing it as an agent skill with one command

There are two ways in. The first is to include `Uncodixfy.md` directly in your prompt or system instructions whenever you ask a model to generate UI, which requires no tooling at all and is how you would use it with a chat interface.

The second is the skill route. Uncodixfy is packaged as an agent skill via `SKILL.md`, which the README says works with AI coding agents that support the skill format, naming Codex and Claude Code specifically. Installation is a single command:

npx skills add cyxzdev/Uncodixfy

The README notes that bunx works as well if you prefer it. Once installed, invocation is a slash command:

/uncodixfy

So the practical difference between the two routes is scope. The skill gets registered with the agent and can be invoked on demand inside a coding session, which is useful when you are mid-task and do not want to paste a block of markdown into a chat box. Direct inclusion is better when you are building the system prompt for your own application and want the rules applied to every request without a human in the loop. Nothing about the rules themselves changes between the two.

A repository with four files and a folder of screenshots

The tree is small enough to describe in full:

LICENSE
README.md
SKILL.md
Uncodixfy.md
images/

`Uncodixfy.md` holds the rules and `SKILL.md` is the packaging that lets an agent discover them. `images/` carries the thumbnail plus the before and after comparison shots the README embeds, and the repository is MIT licensed with 2,663 stars and 168 forks. There are no releases published and no open issues on the tracker, which for a project of this shape is not unusual: there is no library API to version, only a document that changes when the author's taste changes.

One naming detail is worth flagging because it affects whether the tool is what you think it is. The repository is `Uncodixfy`, spelled with an extra f, while the rule file itself is `Uncodixfy.md`. The description field carries the unpunctuated spelling as well. It is a small inconsistency, but if you are searching for the project rather than cloning it, both spellings lead to the same place.

What the README proves with before and after images

The evidence offered is visual rather than argued. The README embeds paired screenshots labelled before, typical GPT UI, and after, uncodixified, across two sets of comparisons. This is a reasonable way to make the argument, since the claim is visual taste and a claim about visual taste is hard to support with anything else.

What the images cannot tell you is how the rules interact with an existing design system. The prohibition list is written against generic habits rather than against any particular product language, which is the right default when you have no context, and a poor fit when you do. A team with a house style that happens to include soft shadows and rounded corners would find some rules actively fighting the thing they already built, and there is no configuration mechanism described for scoping the prohibitions.

That is the main practical question to answer before adopting it. If you are generating greenfield interfaces with no established style, the file is a good default. If you are working inside an existing application, you would want to read the rules and remove or amend the ones that conflict, rather than pasting the whole document into a system prompt and then fighting the result.

Why a list of forbiddings can work better than design guidance

There is a reasoning problem underneath this project that is worth stating plainly. Asking a language model to produce good interface design is a request with an enormous solution space and no clear gradient, which is exactly the kind of problem where instruction following is weakest. Asking it to avoid five specific visual patterns is a request with a small set of verifiable violations, and the model is considerably better at that.

So the file converts an open-ended quality judgement into a set of closed checks. That does not mean output becomes good. It means output stops being bad in a recognisable way, and in practice that difference is large enough to matter, because a page with a sensible information hierarchy and no decorative glass panels is usable in a way that a page with a poor hierarchy under three layers of floating cards is not.

The limitation follows from the same design. A prohibition list cannot tell you what to do instead. Once the cards, gradients and oversized corners are gone, the model is left with its own sense of what a plain interface should look like, which is better than before but still not a design system.

A taste document, with a last push from March

The repository is not archived and the last push was on 2026-03-18, so treat this as a document whose author may have moved on rather than a project on a release cadence. There is no changelog, no versioning scheme and no statement about compatibility with any particular model, which for a prompt file is arguably the right amount of ceremony, but it does mean you should read `Uncodixfy.md` yourself before depending on it.

The README also carries a star history chart, a convention borrowed from repositories that want a visual sense of growth over time. It is the only piece of the page that speaks to popularity rather than function, and 2,663 stars suggests the observation behind the file is widely shared: most people generating UI with a model have hit the same wall and recognise the same five patterns.

None of this changes what to do with it. Install the skill, invoke it on a page you are not happy with, and keep the file if the result is better. If it is not, the whole rule set is short enough that you will know which specific prohibition caused the problem.

Editorial conclusion

Uncodixfy does one narrow thing and is candid about it: it enumerates the interface patterns a model reaches for by default and forbids them, without attempting to teach design. That makes it cheap to adopt and easy to reason about, since you can read the entire rule set in one sitting and decide whether you agree with each prohibition. The cost is that it addresses a symptom rather than a cause. A rule file can stop floating cards and glass panels on request, but it cannot tell a model what your design system actually requires, and a team with an existing component library probably needs that file pointed at its own tokens anyway. Start by pasting the markdown into a system prompt on a single page you already dislike, keep the skill installed for agent workflows, and treat the result as a floor rather than a specification.

Frequently asked questions

Official sources

1. cyxzdev/Uncodixfy on GitHub
2. Issues
3. License: MIT
4. README