With the pipeline decided, the next question was what it should feel like to use. A terminal loop — y/n/skip — reads as work no matter how it’s dressed up, so the app became a local browser page instead: bracket buttons, a visible score, Claude’s one-line reasoning next to each file. The ten-files-a-session cap got the same treatment as an interface decision, not a technical limit — enough to feel productive, not enough to feel like a project. The constraint is the feature.
Visual design got the same seriousness a purely local, single-user tool doesn’t usually earn. Nobody else was ever going to open this app, which made it tempting to ship the default dark theme and move on. It didn’t, on the theory that a personal tool should feel like it belongs to the same system as everything else — so it borrowed the site’s palette, mono type, and bracket-button convention instead of inventing its own look. The catch: the first pass got those details wrong, eyeballing colors and font from memory instead of pulling them from the site’s actual theme file. The mismatch wasn’t caught until a later verification pass, which is its own small lesson about approximating a design system instead of reading it.
Main takeaways
- The game metaphor only works with a UI — a terminal prompt can’t shed the feeling of being a chore.
- A session cap is a UX decision, not a limitation: bounding scope on purpose is what keeps a chore feeling like a habit.
- A personal, single-user tool still benefits from deliberate visual design — it’s part of what makes it feel owned rather than default.
What I got wrong
- The first visual-design pass approximated the site’s colors and font from memory instead of pulling the real tokens, and got both wrong — caught only later, during a direct comparison against
theme.css. - Still don’t know if the ten-file cap holds up once the backlog is large enough that it barely dents it in a day.
