Same, I've added a .#screenshots derivation. High up-front effort but almost zero maintenance afterwards.

Bonus: since you're generating screenshots programmatically anyway, you can generate a pair of each with your app's light/dark theme, and swap them in/out depending on prefers-color-scheme: dark. <picture> elements work in GitHub READMEs, too: https://github.com/CyberShadow/CyDo#readme

I approve of this approach.

The docs for Textual (TUI library for Python) build screenshots along with the docs. Technically not really screenshots, they are SVGs, but principle is the same. They never get out of date.

https://textual.textualize.io/widgets/markdown/#example

Very cool.

For the small casual games I've been vibe coding, I always start from a place where the application has a CLI where it can run headless, rendering to offscreen texture, with a a screenshot command as well as performance instrumentation. It takes no time to include all this, and gives the agent a way to automate the ui and inspect important things. It also lets me trivially have the agent update screenshots.

Not as neat as being part of the build process, but I will now add that.

This is very useful in mobile projects.

App stores require screenshots, but generating N images for NUMBER_OF_SCREEN_SIZES times NUMBER_OF_LOCALIZATIONS can be a chore.

In the past I wrote my own scripts for that, today tools like Fastlane[1] help.

I use Fastlane for my logic puzzle game Nonoverse[2], you can see sample screenshots in its App Store page.

I also automated App Preview video recording, complete with multiple scenes. If anyone wants to read more let me know, perhaps this is a good topic for an article.

[1]: https://fastlane.tools/

[2]: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...

I've needed this so many times. BTW this should be a meme: "I think this might be the neatest thing I’ve built in X that nobody will ever notice."

Plus we had a visual diff on the top of that as a part of the CI pipeline. It prevented a bunch of mishaps ;)

This is neat. I wrote https://github.com/zombocom/rundoc. It has a similar feature. The main driver is to produce tutorials so it also puts the output of commands run back in the document.

> Then you change the UI slightly – tweak a colour, move a button, update some copy – and suddenly every screenshot that includes that element is stale. You know they’re stale. Your users might not notice, but you know, and it gnaws at you.

F

Related: Sabotaging projects by overthinking, scope creep, and structural diffing – https://news.ycombinator.com/item?id=47890799

Bravo. This is incredibly useful, and really improves the quality of documentation, especially for many applications whose design and UI are always in flux.

Nice! I actually started to build this exact thing a couple years back, and ended up abstracting it out to something more generic with https://picshift.io/. That said, I still love the screenshot use case - the original name of this project was ScreenSync ;)