If you've felt Cursor go from magic to drifting around prompt 15-20 on a UI task, the cause usually isn't the model. It's that the design intent only lives in the chat. Once the conversation gets long enough that Composer starts trimming history, the spec is the first thing to go. After that you're just re-prompting against a model that no longer knows what you wanted, and it hallucinates dependencies or rewrites unrelated screens.

The fix that actually holds across long sessions is moving the design spec out of chat and into the repo, as a file you u/reference per task. Exact hex values, type scale, spacing system, every screen state, the nav graph. Concrete enough that the model can't drift, durable across as many prompts and Composer trims as you need.

Writing that spec by hand for every screen is friction enough that nobody does it, so I built the references instead. 200 popular apps, each as a structured markdown DESIGN.md, with SwiftUI, Jetpack Compose, and Expo versions for each. Drop one into your repo, u/reference it in Composer or Agent, and your UI work stops degrading at prompt 20.

Repo, MIT, no dependencies: github.com/Meliwat/awesome-ios-design-md

Two questions: which apps would actually help you next, and for Cursor users on long projects, are you holding design intent in .cursorrules, an u/file, or chat? Trying to nail this down.

The biggest reason the UIs Codex builds for you all look the same: you're handing it a vibe, not a spec. "Make it clean and modern" produces the exact same generic gradient-card layout every time, because that prompt has no anchor. The model fills the gap with its own average taste.

The fix that actually works is giving Codex a real app's exact design as the target. Not "like Spotify" in prose. The actual hex values, type scale, spacing system, every screen state, the nav graph. With that, Codex stops averaging and starts matching.

Writing that spec by hand for every screen is tedious enough that nobody does it, which is why the vibe-prompt habit sticks. So I built the references instead: 200 popular apps, each as a structured markdown design spec, with SwiftUI, Jetpack Compose, and Expo versions. Point Codex at the one you want and it has concrete values instead of guessing.

Repo, 200 apps, MIT, no dependencies: github.com/Meliwat/awesome-ios-design-md

Two questions for people building UI with Codex: do you get better results keeping the spec as a repo file Codex reads every run (AGENTS.md style) or pasting it per task? And which apps are worth adding next?

Small numbers, but the pattern might be useful to someone here.

I'm building Spectr, a tool that turns iOS screen recordings into structured design specs. Hard to explain in one sentence, which kept early traffic flat. Direct "here's my tool" posts did almost nothing.

What changed it: I built a free companion repo, a library of 50 popular apps already converted into design specs, and posted about the workflow insight behind it instead of the product. The repo is genuinely useful on its own. The product gets mentioned once, in passing.

Result over ~36h (screenshot attached):

- New users +124.5%

- Active users +115.7%

- Flat baseline to a clear spike on the 12th

- Inbound from Ireland, Brazil, Greece, New Zealand, none of which I targeted

Absolute numbers are still small (110, not 10,000). Not pretending otherwise. But the shape changed, and the mechanism is repeatable: the free artifact does the convincing, the product is the footnote.

What people are actually landing on: spectr.to/gallery, real spec outputs from real apps.

What I'd do differently: I posted two things to the same subreddit too close together. Self-promo flag risk. Space them out.

For people who've run lead-magnet distribution: did the free artifact cannibalize your paid product, or feed it? I'm betting feed, but it's early.

https://preview.redd.it/2bxv4bhuzc1h1.png?width=2044&format=png&auto=webp&s=296db7c40c10f090fa8ab7f2085ca17a3b728c91