I got tired of being the person who reviews the file. So I shipped a plugin that does it.

In December I was renaming screens in a file one at a time, and asked a colleague whether it was worth automating. The answer was correct: good if you can do it, once the two things above it are done. So it sat.

The second was the same shape. Every review opened with the same findings — wrong font weight, a colour near a token but not the token, a radius someone eyeballed. None of it is interesting to catch, all of it has to be caught, so a senior person spends the first ten minutes of every review being a linter.

Parked since December, picked up in late March, built the same day. Renaming one frame was never the problem. Renaming eighty is, and that is the scale it works at.

What made it useful was not the renaming. It was that the convention stopped being something written down somewhere and became a state the file could be put into.

Encoding it also forced decisions the written version had been comfortably vague about for years — the launch thread became a long back and forth with another designer about what the rule actually said. First two words capitalised, the rest lowercase. Product and feature names all caps. Then the interesting one: is HOME a screen or a funnel? A funnel, so it is capitalised, the same way ONB is.

That distinction lived in everyone's head and nowhere else until a plugin needed to be told. Writing the tool was fast. Getting the team to agree on what it should do was the work.

Sauron reads a file against Bright's design system and reports what does not match. Select a frame, run a check, get a count and an annotation on every offending layer.

I did not introduce it as a linter or a QA utility. I introduced it to the team as their new peer reviewer, which is exactly the job it was taking over.

Both went out together in May under a shared Bright plugins banner rather than passed around as private files. Design leadership took it from there: a deck, a mailer to the wider company, then a slot in the internal news deck.

I built them, published them, and handle the fixes. That the distribution was someone else's enthusiasm rather than my own pushing is the evidence I would point at.

In July a designer was asked to run their work through Sauron before review. They came back having found and fixed two copy issues on their own. That exchange happened without me in it, about a tool I had shipped and stopped talking about. For an internal tool that is the whole scoreboard.

A recurring team problem is usually not a documentation problem. If the fix is a behaviour change across a group of people, build the thing that makes the right behaviour the cheapest one, then get out of the way.