I love this. Thanks for sharing. Would be great to generalize to documentation in general, not just slides.
My LLM workflow is documentation-heavy, and that works great for getting projects off the ground and managing very large projects. But just like human-driven development, more documentation = more likelihood of being stale. Unlike humans, LLMs don’t resent time spent updating docs.
So, if you’re taking feature requests, I would love to see this head towards full lifecycle documentation management. The tricky part is figuring out whether the docs or code drifted. Sometimes misalignment means the code was built wrong, sometimes it means the docs are stale and changes are intentional. A HITL model should maybe help?
Great idea on generalising this beyond just slides - v1.1 is now out with Markdown support :)
This invisible citation comment (<!-- slideops data-src="app/main.py:40-58"...) is added to Markdown documents to help with tracking changes and keeping them it sync with the codebase.
The framing that the test suite is the documentation stuck with me: executing the examples removes the duplication rather than tracking it. Taking ideas from this, thank you!
I love this. Thanks for sharing. Would be great to generalize to documentation in general, not just slides.
My LLM workflow is documentation-heavy, and that works great for getting projects off the ground and managing very large projects. But just like human-driven development, more documentation = more likelihood of being stale. Unlike humans, LLMs don’t resent time spent updating docs.
So, if you’re taking feature requests, I would love to see this head towards full lifecycle documentation management. The tricky part is figuring out whether the docs or code drifted. Sometimes misalignment means the code was built wrong, sometimes it means the docs are stale and changes are intentional. A HITL model should maybe help?
Great idea on generalising this beyond just slides - v1.1 is now out with Markdown support :)
This invisible citation comment (<!-- slideops data-src="app/main.py:40-58"...) is added to Markdown documents to help with tracking changes and keeping them it sync with the codebase.
On the topic of generlaising to documents, for a moment I wish I named the skills "DocOps", but that's already a thing: https://www.writethedocs.org/guide/doc-ops/
I wrote a bunch of custom tooling for iommi, I have a write up of it here: https://kodare.net/2025/08/08/documentation-that-is-never-wr...
The framing that the test suite is the documentation stuck with me: executing the examples removes the duplication rather than tracking it. Taking ideas from this, thank you!
We did it the other way around first, but it was a huge hassle and very hacky. Since we flipped it we've been much more satisfied with the system.
It's somewhat inspired by literate programming, but a bit flipped.