A design skill is a set of instructions. Its value depends on the job you give it, the agent that reads it and the information in the starting project. A skill can help an agent write a more precise review while leaving the screenshot unchanged. It can also make an attractive screen worse by pushing the task off the phone. We wanted to separate those possibilities before telling someone which tools to install.
The older Unvibed benchmark asked mostly whether outputs were correct. On twenty-one paired tasks the kit won two, tied seventeen and lost two. That result was useful for checking basic behavior, but it left little room to distinguish a default template from a product with a clear hierarchy. We changed the question. Given two anonymous desktop and phone renders of the same starting screen, which looks like a real product for the stated task? The judge sees both sides, chooses a preference on a seven-point scale and explains what it saw. It repeats the comparison with the sides reversed.
What the individual trials can show
The skill trial compares one public skill with a plain agent on a selected best-fit screen. Both get the same user task. The plain result is a real competitor: an agent with no added skill can produce a clear design. The report retains the raw order, preferences and reasons, and identifies the source version. A skill is not awarded a win simply because its instructions sound relevant. The full kit is a separate treatment. Combining the two sets of numbers would count different interventions as if they were the same product.
Read “keep” as a reason to keep the procedure in this workflow, “optional” as a conditional or inconclusive result, and “skip” as a reason not to choose it for this tested job. None is a global ranking of an author's work. One run on a web feed is a particularly weak test of an Expo or Swift skill. A still image cannot prove that an animation interrupts cleanly or a screen reader announces a state. Even an emphatic visual preference should not be used to make either claim.
Read the source before installing everything
Several of these procedures overlap. In a proof list you can make the status more legible by changing type, grouping or copy. Sending three different commands to do that job at once makes it hard to learn which decision helped. Try the smallest relevant skill first. Keep the same fixture and viewport, then ask another person to find the proof awaiting approval. That practical check can contradict the model's preference, and you should take the contradiction seriously.
The names below credit the repository maintainer recorded at the pinned revision. The linked source identifies the actual input, even when a repository hosts many skills. Each result refers only to the matched trial. Open the benchmark and its limitations for the preference scale, treatment definitions and detailed methodology.
Emil Kowalski · emilkowalski/skills
animate: skip (2, 2). The treated proof got more room, but the plain version connected approval more directly to version 02 and the resulting status.
animate-expo: skip (2, 2). The alphabet preview improved, but the treatment pushed the specimen details and save action out of the first mobile view.
animation-performance: skip (3, 3). The richer character preview came with a wrapped brand and a taller introduction. The plain version reached reading content sooner.
animation-vocabulary: skip (2, 2). The treated desktop layout grouped proof and approval more tightly. On the phone it clipped the version, client and status.
apple-design: skip (3, 3). The specimen gained a useful alphabet sample while its save action slipped partially below the phone viewport.
ask-sonner: skip (2, 2). The treatment's navigation looked more distinct. The plain form kept the retained endpoint and full-width retry action visible together.
break-ui: skip (2, 3). The studio-name limit added useful specificity. Floating demonstration controls obscured the form and made retry harder to find.
emil-design-eng: keep (6, 5). The approval panel named version 02 and explained the state change. The plain mobile proof retained more supporting context.
find-animation-opportunities: keep (5, 5). The mobile specimen flowed from letterform to description to save, with the next specimen visible. The plain button was more prominent.
improve-animations: skip (2, 2). The proof gained prominence, but the plain version made clearer what approving version 02 would change. Neither still proved reduced motion.
mobile-native: skip (3, 3). A generous letterform preview helped identify the typeface, but the description and smaller save control became detached from the mobile card.
pick-ui-library: skip (2, 2). Workspace navigation improved, but the treated save button did not name the retry. The plain version kept the recovery action visible.
prototype: keep (6, 6). The treatment put the reading room, crate W-12 and Continue together. An unexplained presentation selector competed with setup.
remove-animations: optional (5, 3). The treatment grouped identifier, title and description and separated the save control. The wider plain button remained easier to spot.
review-animations: skip (2, 2). The revised proof had more space. The shorter status and separate version label made the approval decision less explicit.
write-swift: keep (5, 5). The treated mobile specimen named the face above the letterform and kept Save visible. This was a web screen, not a Swift app.
Dick Wu · dickwu/apple-design-skill
apple-design-hig: skip (2, 2). A roomier contact form placed its failed-save alert below the phone fold. The plain screen put the alert before the fields.
Jakub Krehel · jakubkrehel/skills
better-accessibility: skip (2, 2). The treated tinted recovery notice stood out, but the plain form put the person who could reissue the invitation beside the expired heading.
better-colors: skip (2, 3). The added copy-count control helped explain the plans. Its panel also pushed the first plan action below the phone fold.
better-interface: skip (2, 2). The treatment used larger type on Atlas, but the taller card moved the review action down and added an unnecessary date qualifier.
better-layout: skip (2, 2). The stacked shipment cards emphasized the dock. The plain compact table kept all three destinations and departure times visible on a phone.
better-typography: optional (6, 3). The treated invoice list led with the overdue record and kept its amount, issue date and status together on mobile.
better-ui: skip (3, 3). Stronger input borders helped identify editable fields, but the taller form lost the notification destination from the first mobile view.
better-writing: keep (5, 5). The kiln and shift were grouped more clearly with the next inspection action. Shortening the empty message also removed its shift scope.
break: skip (2, 2). The treated endpoint had more room, but an extra failed-save row competed with retry. The plain alert identified which choices remained.
build-design: skip (2, 1). Shorter cards cut duplication. They also lost the client name and separate review queue, while a gradient greeting delayed the work.
explain-interface: skip (2, 2). The compact review banner brought search higher but used an unlabeled arrow where the plain version named the review action.
interface-review: skip (2, 2). The treatment avoided repeating Atlas in a second card. A large preview pushed the actual review action down on mobile.
state-machine: skip (2, 3). A useful instruction to keep the page open appeared in the treatment, alongside a detached failed-save control competing with the form.
teardown: skip (2, 2). Large recipe figures helped reading, but the treated headline delayed the dose selector and dropped the cumulative-water instruction.
variant: skip (2, 2). The copy-count input added useful context. A separate structure selector distracted from the actual $18 versus $42 decision.
Leonxlnx · Leonxlnx/taste-skill
design-taste-frontend: keep (6, 6). The treatment connected $6,550 to the open and overdue split, bringing the decision behind the invoice tool higher on mobile.
Lucas Markes · lucasmarkes/hairline
hairline-adopt: skip (2, 2). The desktop recipe breathed more easily. On a phone its larger headline delayed the dose selector and cumulative-water instructions.
hairline-create: skip (3, 2). The recipe card grouped ratio and water more clearly. The plain chart explained why the reader should keep the scale running.
Nutlope · Nutlope/hallmark
hallmark: keep (6, 6). The treatment paired a specific debt headline with $6,550 owed and $2,800 overdue. The plain introduction was more visually expressive.
Paul Bakaus · pbakaus/impeccable
impeccable: skip (2, 2). A stronger review button and less duplication helped Atlas. The treated card omitted the proof number and left its destination less precise.
Try one finding on your own app
Choose a screen that already has enough real information to make a decision. For instance, a reviewer can judge whether overdue invoices are visible when the fixture contains both paid and overdue records. A dashboard with four empty cards is a weaker test. Keep a known task and avoid changing data between the two versions. If you want to test a motion skill, add an interaction recording or timing trace; the evidence here does not substitute for either.
Write down one protected behavior before applying a skill. On the client portal it could be that an approval survives a reload. On a feed it might be that saving a post leaves the reader in the same place. Compare the captures, then try that action again. A new heading may make the screen look more deliberate while hiding the original control. Treat that as a regression even if a reviewer likes the picture.
The 36 verdicts here still describe the one-shot trials. Our repo benchmark asks a different question: what happens when an agent can edit a real Next.js app, see both rendered widths and try again? It includes ten domains and checks whether unrelated outputs repeat one look. The repo study recorded 1 kit win, 3 tied or split and 6 plain wins. The per-domain results and both votes are published separately. A kit win or loss there does not change an individual author’s verdict here.
Finally, credit what you used. Link to the original repository and pin the revision when a team depends on its behavior. Keep the procedure's license and any distribution requirements separate from your evaluation of its usefulness. Naming an author is not a substitute for permission to redistribute their work, and a trial result is not an endorsement from that author. The useful output is a short list of procedures you understand well enough to test again.
Use the free UI audit to collect a graded starting report for your own screen. Reproduce each priority finding before assigning a repair.