I have had some success with this by using a distinct agent profile for this role in my agent team.
The agent is instructed to use Laws of UX[0] when reviewing application flows and cite specific laws with changes to the builder agents. Look-and-feel in general still requires some tuning, but I have found that: 1) using a discrete agent in this role that only looks at the flow and is given the end-user context, 2) pointed to a set of guidance has really improved autonomy for UX.
This is still generally a good rule when building with agents, the models are capable of many behaviors. The key is to simply set some bounds on what their "job" is so that most of their finite attention can be spent organizing around the what that role is expected to do.
It certainly is less important as the models get better at meta planning, but this approach is still very useful.
Often all you need to do is define a set of beliefs and values for the role and it will operate much better than rules or guidance.
Yes, 100%. There's some recent research that backs this up.
Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Stream (https://arxiv.org/pdf/2606.01770) talks about this and the efficacy of role- and objective-based agents on unbounded streams of heterogeneous tasks.
I recently wrote down some of my own experience with this: LARPing with Agents (and Why It Works) (https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...) after someone called out my role-based agents as "larping". Short of it: role-based, fully "JIT" agents have increased autonomy in my coding workflows end-to-end. I get very good outputs with few skills required and less human instruction input.
Thanks for linking this. I've reached a point I need to overhaul one of my MacOS apps and these laws are the perfect find.
What's the best approach to applying these in practice? Should I evaluate every screen with each of these laws in mind or should I evaluate the app entirely one law at a time?
Here's the thing. As you're indicating, UI and UX are not the same thing, but they're both subjective.
You can ask the model to implement common patterns for both UI and UX. You can ask the model to correct obvious UI errors.
But you can't really ask the model to have UI taste unless you supply that taste, and you can't ask a model to "do UX" in a vacuum. UX work requires user testing. So any UX workflow that is going to be handled by agents must also include observational data of humans using the software.
There is no set of instructions that can do "UI/UX" without also incorporating human feedback.
The problem I've been having is they just have no sense of systems, which is exhausting once your app scales to anything beyond 1 page. It will happily write features that can't interact together at all, despite being in the same piece of software, and burn tokens to glue them together when you point out the problem.
And obviously you can say, "hey these features need to work together make no mistakes." But for really big projects like professional software, that's a LOT of features with a LOT of possible interactions.
Examples comparing two similar de-slop skills. Flawless vs Impeccable vs Diffui (my own) for the same prompt[1]. Note that I did not prompt for mobile variants of these, so no clue how they'll show up on mobile.
Create three example webpage builds for the following prompt:
"A landing page for a new foldable phone. Colorful dark green and gold theme. Should include a hero section, a build quality section emphasizing the waterproof capabilities, and a pricing section."
Have three separate opus 5.5 cloud agents do this, each running in isolation.
For the first use https://github.com/smokeeaasd/flawless-ui-ux
For the second use https://impeccable.style
For the third use https://diffui.ai
In general with these things, my thoughts are that one-shot/deslop skills should get you to a starting point quicker where you can iterate. Trying to go from 0->100 is usually a losing battle, as all of them will have elements that just don't quite work.
I do think impeccable steers away from slop / ai indicators the most. It aggressively removes standard AI thinks like eyebrows (present in the diffui render) or circle indicators (present in the flawless build). That doesn't mean the output is the best starting point however. It's a unique landing page, but not necessarily the best to convey or sell a waterproof folding phone. It comes at a cost however - impeccable leverages a lot of token spend to aggressively police itself (about $3.56, which is more than the diffui costs even with the image gen it did). Flawless was the cheapest of the three comparisons, but I don't see a significant difference between it and vanilla opus 5.5.
Is there any evidence that skills like this beat training? For example, "Use links for navigation and buttons for actions", is something I imagine any decent model would have picked up already. From my experience, this kind of thing just bloats context and might cause the agent to go off on many rabit trails due to anchoring on keywords in the skill that aren't even relevant to the prompt.
not sure if you count this as evidence, but https://www.whichai.dev has comparisons between default model behavior + model with skills etc. It's very good to assess how strong a model is for frontend tasks.
I only glanced at the repo, but there is an evals/ folder. A good eval would include a no-skill default model+harness (like Claude Code) as a baseline.
Every time I see someone post a skill on HN I'm really not sure what we're expected to be discussing about it. Are we supposed to go check out the markdown files that the author likely never read and comment on them? How are we supposed to know if these skills aren't up to quality with something I could make myself in a one-shot prompt?
And with something as opinionated as design, how am I supposed to trust that this isn't filled with decisions I don't agree with?
Without a demo, a with/without comparison, and evals that include "no skill" as a benchmark it's functionally slop and at best a conversation starter about related topics.
There is no evidence the repo creator is trying to earn anyone's trust. This could be a personal project that they have no intention to try and "sell" to anyone. They may not be trying to earn the public trust and have no interest if anyone besides them uses it.
I don't know how it is currently, but you used to have to make GitHub repos public to access the full feature set (i.e. things like CI runners) on free accounts. Some of us just got in the habit of making things public
Despite almost all of the comments already saying it - I cannot fathom how something selling itself as producing flawless UI/UX.. does not demonstrate it in the README, or one click from it
LMAO... Here is a bunch of stuff that you can get your agent to randomly do, like exfil data. Copy and go. Also, UI-UX but with not _UI_ _UX_ examples is insane
1. why do you have to install an npm package just to download a text skill, when there are multiple tools available (eg. skill.sh) that already do that?
2. skills are worth nothing without proof that they improve outcomes - a website/app build with and without the skill should be an easy comparison to make
Please provide examples (author of project)
People come across so many things in a day you can't expect them to try this skill out without a demo or example to see first.
100% yes this. If we have a few screenshots or example pages to click through, just something we can see.
I'm gonna try this, but looking at the skill it reminds me of a less-specific version of vercel's UI skill
UI is one thing, but agentic UX is actually really hard I've found.
I have had some success with this by using a distinct agent profile for this role in my agent team.
The agent is instructed to use Laws of UX[0] when reviewing application flows and cite specific laws with changes to the builder agents. Look-and-feel in general still requires some tuning, but I have found that: 1) using a discrete agent in this role that only looks at the flow and is given the end-user context, 2) pointed to a set of guidance has really improved autonomy for UX.
[0] https://lawsofux.com/, https://lawsofux.com/llms.txt
This is still generally a good rule when building with agents, the models are capable of many behaviors. The key is to simply set some bounds on what their "job" is so that most of their finite attention can be spent organizing around the what that role is expected to do.
It certainly is less important as the models get better at meta planning, but this approach is still very useful.
Often all you need to do is define a set of beliefs and values for the role and it will operate much better than rules or guidance.
Yes, 100%. There's some recent research that backs this up.
Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Stream (https://arxiv.org/pdf/2606.01770) talks about this and the efficacy of role- and objective-based agents on unbounded streams of heterogeneous tasks.
I recently wrote down some of my own experience with this: LARPing with Agents (and Why It Works) (https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...) after someone called out my role-based agents as "larping". Short of it: role-based, fully "JIT" agents have increased autonomy in my coding workflows end-to-end. I get very good outputs with few skills required and less human instruction input.
Thanks for linking this. I've reached a point I need to overhaul one of my MacOS apps and these laws are the perfect find.
What's the best approach to applying these in practice? Should I evaluate every screen with each of these laws in mind or should I evaluate the app entirely one law at a time?
Give and agent the llms.txt and ask it to read.
I have a dedicated agent profile that specifically owns this task and I tell the other agents to only send screenshots to it and ask for feedback.
I gave it to an agent along with the transcript of Theo's recent hill climbing to fix uis video.
Hoping Jev on open router can save me.
Even "human" UX is actually really hard, mind you. If we haven't figured it out, how would an agent/LLM trained on human output?
From my perspective, the issue is that there can be no formulaic/algorithmic approach to good UX.
Here's the thing. As you're indicating, UI and UX are not the same thing, but they're both subjective.
You can ask the model to implement common patterns for both UI and UX. You can ask the model to correct obvious UI errors.
But you can't really ask the model to have UI taste unless you supply that taste, and you can't ask a model to "do UX" in a vacuum. UX work requires user testing. So any UX workflow that is going to be handled by agents must also include observational data of humans using the software.
There is no set of instructions that can do "UI/UX" without also incorporating human feedback.
The problem I've been having is they just have no sense of systems, which is exhausting once your app scales to anything beyond 1 page. It will happily write features that can't interact together at all, despite being in the same piece of software, and burn tokens to glue them together when you point out the problem.
And obviously you can say, "hey these features need to work together make no mistakes." But for really big projects like professional software, that's a LOT of features with a LOT of possible interactions.
Any examples of the stuff this produces with a few distinct models?
Examples comparing two similar de-slop skills. Flawless vs Impeccable vs Diffui (my own) for the same prompt[1]. Note that I did not prompt for mobile variants of these, so no clue how they'll show up on mobile.
Flawless (4.4M tokens): https://html.non.io/skill-compare-flawless/
Impeccable (6.5M tokens): https://html.non.io/skill-compare-impeccable/
Diffui (2.4M tokens + $0.51 in api spend): https://html.non.io/skill-compare-diffui/
[1] Full prompt:
In general with these things, my thoughts are that one-shot/deslop skills should get you to a starting point quicker where you can iterate. Trying to go from 0->100 is usually a losing battle, as all of them will have elements that just don't quite work.
I do think impeccable steers away from slop / ai indicators the most. It aggressively removes standard AI thinks like eyebrows (present in the diffui render) or circle indicators (present in the flawless build). That doesn't mean the output is the best starting point however. It's a unique landing page, but not necessarily the best to convey or sell a waterproof folding phone. It comes at a cost however - impeccable leverages a lot of token spend to aggressively police itself (about $3.56, which is more than the diffui costs even with the image gen it did). Flawless was the cheapest of the three comparisons, but I don't see a significant difference between it and vanilla opus 5.5.
[narrator] it was, in fact, neither flawless nor impeccable
How are there no demos
Is there any evidence that skills like this beat training? For example, "Use links for navigation and buttons for actions", is something I imagine any decent model would have picked up already. From my experience, this kind of thing just bloats context and might cause the agent to go off on many rabit trails due to anchoring on keywords in the skill that aren't even relevant to the prompt.
not sure if you count this as evidence, but https://www.whichai.dev has comparisons between default model behavior + model with skills etc. It's very good to assess how strong a model is for frontend tasks.
I only glanced at the repo, but there is an evals/ folder. A good eval would include a no-skill default model+harness (like Claude Code) as a baseline.
Every time I see someone post a skill on HN I'm really not sure what we're expected to be discussing about it. Are we supposed to go check out the markdown files that the author likely never read and comment on them? How are we supposed to know if these skills aren't up to quality with something I could make myself in a one-shot prompt?
And with something as opinionated as design, how am I supposed to trust that this isn't filled with decisions I don't agree with?
Without a demo, a with/without comparison, and evals that include "no skill" as a benchmark it's functionally slop and at best a conversation starter about related topics.
I love that this repo, of all repos, doesn't come with screenshots
Seems like quite the flaw in the user experience
Such a pet peeve of mine...
Right? The repo communicates not to trust it.
There is no evidence the repo creator is trying to earn anyone's trust. This could be a personal project that they have no intention to try and "sell" to anyone. They may not be trying to earn the public trust and have no interest if anyone besides them uses it.
[flagged]
Then making it a public repo is a weird thing to do.
I don't know how it is currently, but you used to have to make GitHub repos public to access the full feature set (i.e. things like CI runners) on free accounts. Some of us just got in the habit of making things public
Why? I've never created a private repo on github for any of my personal projects. Stating with dotfiles
Despite almost all of the comments already saying it - I cannot fathom how something selling itself as producing flawless UI/UX.. does not demonstrate it in the README, or one click from it
LMAO... Here is a bunch of stuff that you can get your agent to randomly do, like exfil data. Copy and go. Also, UI-UX but with not _UI_ _UX_ examples is insane
[flagged]
1. why do you have to install an npm package just to download a text skill, when there are multiple tools available (eg. skill.sh) that already do that?
2. skills are worth nothing without proof that they improve outcomes - a website/app build with and without the skill should be an easy comparison to make
Sounds pretentious.