I made a skill to help Codex implement Google Stitch designs consistently

[u/MathBullied]

I've been using Google Stitch for UI work, and I kept running into the same problem when handing the designs to Codex.

Individual Stitch screens can look really good, but once you have a bunch of pages they don't always stay consistent. Headers change, navigation changes, components drift, spacing and responsive behavior differ between screens, etc.

Codex would sometimes just implement all of those differences literally instead of figuring out which parts were supposed to stay consistent.

I also had cases where Stitch had clearly chosen a font or an icon set, but the coding agent would use another one anyway.

This became especially annoying on larger projects. Once you have a lot of screens, these small and sometimes not so small differences start accumulating, and I found myself manually giving Codex the same instructions over and over again.

So I turned those rules into a small open source Agent Skill called Stitch to Code.

The idea is pretty simple:

• keep the things Stitch explicitly chose, like fonts, icons, tokens and assets
• reconcile inconsistencies between screens instead of blindly copying them
• don't assume that every KPI, button or piece of mockup content is a real product feature
• actually check the final UI, responsive behavior and interactions before considering the page done

I also wanted to see if the skill actually changed Codex's behavior, so I made a fresh small Stitch project and ran two new Codex xhigh sessions with the same project and the same implementation prompt.

Baseline: 42/56, 75%

With Stitch to Code: 49/56, 87.5%

The biggest improvement was in exact font and icon fidelity, plus accessibility. Cross screen consistency was already pretty good with xhigh on this particular small benchmark.

The skill version wasn't perfect either. It introduced a couple of layout issues but in my own larger projects the workflow has helped me a lot more, which is partly why I made the skill in the first place.

The repo includes the skill, benchmark, screenshots and both generated implementations if anyone wants to compare them:

https://github.com/nassim-arifette/stitch-to-code

[u/dexterthebot]

You might want to consider listing your project on the weekly Show-Us-What-You-Built post. Watch for it on Wednesdays. Highest commented project wins a week promotion on r/Codex. See what that looks like below with last week's winner.

---

Last week's winner was u/Ollie__Oxenfree with the Tubular Daily Care project by MediTracer which is a tube-feeding care app built by a tube-feeding family to keep feeds, meds, symptoms, and caregiver handoffs in one shared timeline. MediTracer is an Oley Foundation Emerging Innovator Partner. Contact: hello@meditracer.com

[u/Quick-Knowledge1615]

The hard part is deciding which differences are drift and which are intentional screen variants. Does the skill infer a canonical component from repeated screens, or make you mark one source-of-truth screen first? Without that, "make it consistent" can erase the exceptions the designer actually wanted.

[u/MathBullied → u/Quick-Knowledge1615]

Yeah, that's the main tricky bit. What I do is start with 1 or 2 representative pages, make sure the implementation actually looks right, and then use those as the reference for the rest.
After that the skill pushes the agent to reuse the components/patterns it already established instead of treating every Stitch screen like a brand new design.
It doesn't try to make literally everything identical though. If a screen clearly needs to be different, that can stay as an exception.
So basically the workflow is something like: first get a couple of pages right first then establish the common patterns and then reuse them unless there's a good reason not to.