I totally second that; I especially like that, because they focus on a single decision, most of the actual text in there is context.
Also, I’ve been growing into the idea that there’s great value in documenting the solutions you considered but did not pick, which is something that fits perfectly in an ADR.
That being said, I haven’t found ADRs by themselves to be satisfactory because, once you start superseding things, it becomes hard to picture the final state (much like understanding a repo’s current state from just looking at the git log); I’ve found that keeping a lightweight description of the system architecture and features helps a lot, especially with a small glossary that describes the domain.
This could then be linked back to the ADRs.
On a final thought/question, is there some standard tooling currently in use for creating diagrams?
I’ve had good experiences using PlantUML, as it’s text based (i.e. good for version control) and usually good enough for high-level diagrams (i.e. it produces weird layouts when there are too many blocks and connections).
Riffing off of @braden 's recent documentation updates, this could be something that would be integrated into the documentation site’s build.