You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Export context graph to Mermaid.js / Graphviz DOT format for visual inspection #1287
Is your feature request related to a problem? Please describe.
Currently, while the tool effectively maps out the code context and relationships, there is no quick, native way to visualize the generated graph. For large codebases, reading raw context data or JSON/text outputs can be overwhelming for developers trying to understand architectural boundaries or dependencies.
Describe the solution you'd like
I propose adding an export flag (e.g., --export-format=mermaid or --export-format=dot) that allows users to output the context graph into a standard visualization format.
Mermaid.js: Would allow users to paste the output directly into GitHub Markdown or Notion to visualize the context.
Graphviz DOT: Would allow for complex, locally rendered graph images.
Describe alternatives you've considered
Currently, users have to write custom parsers to translate the standard output of CodeGraphContext into a visual graph, which disrupts the workflow.
Additional context
This feature would make the tool much more accessible for onboarding new developers to a codebase, as they could instantly generate an architecture map based on the parsed context.
mermaid vs dot isn't really what decides whether this helps onboarding. a graph you export once and paste into a readme is accurate until the next refactor, then it quietly lies to the new contributor it was meant to help. the axis that actually matters is regeneration cadence, not render format. a static architecture map from three sprints ago onboards people into a codebase that no longer exists, and they trust it precisely because it looks authoritative. whatever export you ship, the value lives in how cheaply it re-runs as the graph drifts.
That's a fair point. A stale architecture diagram can definitely become misleading if it's treated as documentation rather than a generated artifact.
My intention with this feature isn't to encourage maintaining static diagrams manually, but to make the existing context graph easier to inspect and consume. Mermaid/DOT would simply be export targets for the graph that CodeGraphContext already generates.
I agree that regeneration cadence is the more important factor for onboarding. Ideally, exported diagrams would be generated on demand (or even as part of CI/docs workflows) so they stay aligned with the current codebase rather than becoming a snapshot that slowly drifts.
From that perspective, I see visualization and freshness as complementary concerns:
Export formats improve accessibility and understanding.
Automated regeneration ensures the visualization remains trustworthy.
The feature request is mainly focused on lowering the friction of turning the generated graph into something developers can quickly explore, while keeping graph generation as the source of truth.
Activity
github-actions commentedon Jun 19, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
Neelr1912 commentedon Jun 19, 2026
/assign gssoc
m13v commentedon Jun 24, 2026
mermaid vs dot isn't really what decides whether this helps onboarding. a graph you export once and paste into a readme is accurate until the next refactor, then it quietly lies to the new contributor it was meant to help. the axis that actually matters is regeneration cadence, not render format. a static architecture map from three sprints ago onboards people into a codebase that no longer exists, and they trust it precisely because it looks authoritative. whatever export you ship, the value lives in how cheaply it re-runs as the graph drifts.
Neelr1912 commentedon Jun 24, 2026
That's a fair point. A stale architecture diagram can definitely become misleading if it's treated as documentation rather than a generated artifact.
My intention with this feature isn't to encourage maintaining static diagrams manually, but to make the existing context graph easier to inspect and consume. Mermaid/DOT would simply be export targets for the graph that CodeGraphContext already generates.
I agree that regeneration cadence is the more important factor for onboarding. Ideally, exported diagrams would be generated on demand (or even as part of CI/docs workflows) so they stay aligned with the current codebase rather than becoming a snapshot that slowly drifts.
From that perspective, I see visualization and freshness as complementary concerns:
The feature request is mainly focused on lowering the friction of turning the generated graph into something developers can quickly explore, while keeping graph generation as the source of truth.
feat: vector-resolve visibility, complexity CI gate, dead-code confid…
fix(cli): register diagram in the canonical-command smoke matrix; sto…