committed-aesthetic

Featured

How to write — and how to use — a skill that IS one aesthetic rather than a catalogue of them. A catalogue lets an agent pick, and it picks the modal option; a committed aesthetic makes it execute one thing precisely, against rules you can check. Use when a design keeps coming out competent and forgettable, when starting a new brand surface with no reference, or when authoring a house style you want executed the same way twice.

Code & Development 92 stars 13 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
66
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# A committed aesthetic beats a catalogue ## The problem this exists for `ui-ux-pro-max` ships 84 styles, 161 palettes and 57 font pairings, and `design-advisor` is wired to all of it. The catalogue is not the bottleneck. The bottleneck is that **a catalogue lets a model pick, and an unconstrained pick is the modal one.** Asked for a landing page with no brand, any model reaches for the same safe centre: a soft gradient, a large sans heading, three rounded cards with a left accent border, generous neutral grey. Every input in the training distribution votes for it. Nothing in a catalogue entry saying *"Swiss minimalism — clean, grid-based, generous whitespace"* is specific enough to override that, because that sentence describes the safe centre too. Compare a rule from a committed aesthetic: > every dimension is `calc(fraction * 100vw)` against a baseline width, so one > page at 1024px reads as a perfect scaled-down of the same page at 1920px You can **check** that. A design either obeys it or does not. That is the whole difference: a catalogue entry is a *label*, a committed aesthetic is a *constraint*. ## The form A committed-aesthetic skill has five parts. The first is the one that does the work. ### 1. Transferable DNA — numbered, specific, falsifiable Between 8 and 14 rules. Each must be checkable by someone who was not in the room. Test every rule against this: **could two designers disagree about whether a page obeys it?** If yes, it is a vibe, rewrite it. |...

Details

Author
avelikiy
Repository
avelikiy/great_cto
Created
5 months ago
Last Updated
today
Language
JavaScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

aesthetic-instrument

great_cto's own committed aesthetic — the instrument panel. Dark five-step surface ladder, exactly one accent, two faces divided by MEANING (Geist speaks, Geist Mono is machine-truth), tabular numerals, and a dash that is not a nought. Twelve checkable rules measured from packages/board and greatcto.systems, not designed for this file. Use when building or extending any great_cto surface — the board, the site, a report, a share page.

92 Updated today
avelikiy
Web & Frontend Listed

frontend-aesthetics

Raises the visual quality of agent-generated UI so it stops reading as AI slop, and audits existing UI against a catalog of tells. Use BEFORE writing the first line of markup for any user-facing surface (landing page, marketing site, dashboard, app screen, docs site) - not after, when the defaults are already baked in. Also use whenever a UI is described as looking generic, templated, "AI-generated", soulless, or "like every other site", when asked to make something look better/more premium/less default, when redesigning or critiquing an existing interface, or when reviewing UI a model produced. Ships a deterministic linter (scripts/slop_check.py) for the countable tells; the judgment calls stay human. Not for chart/data-viz design, and not for layout BUGS (that is debugging, not taste).

1 Updated 1 weeks ago
anton-winter-arch
Web & Frontend Listed

frontend-aesthetics

Raises the visual quality of agent-generated UI so it stops reading as AI slop, and audits existing UI against a catalog of tells. Use BEFORE writing the first line of markup for any user-facing surface (landing page, marketing site, dashboard, app screen, docs site) - not after, when the defaults are already baked in. Also use whenever a UI is described as looking generic, templated, "AI-generated", soulless, or "like every other site", when asked to make something look better/more premium/less default, when redesigning or critiquing an existing interface, or when reviewing UI a model produced. Ships a deterministic linter (scripts/slop_check.py) for the countable tells; the judgment calls stay human. Not for chart/data-viz design, and not for layout BUGS (that is debugging, not taste).

0 Updated 2 days ago
thefilesareinthecomputer