See it as a diagram
Everything below, as a diagram you can edit. Describe yours and see it in seconds.
No account needed · Editable canvas, not a picture
What plan comments cover, and where they stop
A plan comment is a list of resource actions. It is authoritative about the three things that matter most, whether something is created, replaced, or destroyed, and reading it is not optional. Diagram tools that render the plan as a picture add colour to that list, which helps when a change touches many resources at once.
The list format is also the limitation. Reach is a graph question: a one-line change inside a shared local module lands in every stack that calls it, and the diff shows the module file rather than the four consumers downstream. Shape is a structural question: adding a dependency between two previously independent modules reads as unremarkable in a unified diff and is exactly the kind of change worth a second opinion.
A project is bound to a branch, which is the whole trick
A Datadef repository connection targets a repository plus a branch or a tag. The usual setup is one project on main, synced daily, which is the living picture of the platform. For a change that is structural rather than cosmetic, connect the feature branch as a second project and you have the before and the after side by side: modules as zones, references resolved through outputs into labelled edges, registry modules with their source and version.
Comparing them is a visual diff at the level people actually reason about. A new zone means a new module. A new arrow between two zones means a coupling that did not exist yesterday. A resource that moved from one zone to another means a boundary changed, which is the review comment worth writing.
What this is not, stated plainly
Datadef does not post comments on pull requests, does not run as a CI bot in your pipeline, and does not read plan files. If a bot commenting a rendered plan on every PR is what you need, that is a different category of tool and you should buy that one.
What exists is the repository connection, a daily and on-demand sync, and an MCP server exposing two repository tools. repo_status answers which repository and which branch or tag a project tracks, when it last synced, the commit it currently reflects, and whether daily sync is on. repo_refresh starts a sync, which usually takes one to three minutes, and both are restricted to the owner of the repository connection. A coding agent session in Claude Code, Cursor, or Claude Desktop can therefore close the loop at the moment that matters most: right after an infrastructure change merges, when the shared diagram is most likely to be wrong. See Datadef for coding agents for how that is wired.
The merge-time habit that actually holds
Refresh the main project when an infrastructure pull request merges. Doing it at merge rather than on a review cadence is what keeps the diagram trustworthy, because the interval where the picture is wrong shrinks from weeks to minutes.
The cost of doing this on every merge is close to zero, by design. Each sync hashes the parsed draw plan into a structure fingerprint, and a merge that changed a README, a comment, a test, or a provider patch version leaves that hash unchanged, so generation is skipped. Only merges that actually moved the architecture redraw anything, which also means the regeneration history doubles as a log of real structural changes.
For the review checklist itself, the things worth checking before approving, see how to review a Terraform pull request. For turning the habit into a gate rather than a memory, docs checks in CI covers the pipeline side.
FAQ
Can Datadef post an architecture diagram as a pull request comment?
How do I see the architecture a feature branch produces?
Does it read terraform plan output?
Will a documentation-only merge redraw the diagram?
How do I trigger a refresh right after a merge?