Contributing to CGraph takes three steps: pick an open issue, build the project locally with CMake and vcpkg, and open a pull request that keeps extraction deterministic and adds smoke coverage. This guide walks through each so your first contribution lands cleanly, whether you're fixing a language edge case or adding an export format.
CGraph is an open-source engine that builds a queryable graph of any codebase, so contributing to it means working on the tooling that other developers use to understand their own code. That's a satisfying kind of leverage.
1. Pick an issue
Start on the issue tracker. Issues labeled good first issue mark friendly entry points — self-contained work that doesn't require deep knowledge of the whole system. Language-extraction gaps, export-format tweaks, and documentation fixes are common on-ramps.
If you're unsure whether an issue is a good fit, say so in a comment before you start. A quick "I'd like to take this, here's my plan" saves everyone time.
2. Fork and build
Clone your fork and get a local build working before you change anything:
- Configure with CMake + vcpkg — vcpkg pins the C++ dependencies so your environment matches ours.
- Run the smoke suite to verify your setup extracts graphs correctly on known inputs.
Getting a green smoke run first means that when something breaks later, you know it was your change and not your environment.
3. Keep extraction deterministic
This is the one rule that matters most. CGraph's extraction is deterministic — the same source tree always produces the same graph. That property is what makes it safe to diff graphs on every PR and trust the results in CI. Any change that introduces nondeterminism (map iteration order, timestamps, absolute paths leaking into output) is a regression, even if the graph "looks right."
When in doubt, extract the same fixture twice and diff the output. It should be byte-identical.
4. Add smoke coverage and open a PR
New behavior needs a smoke test that exercises it — a small fixture and the expected graph. This is what lets us review quickly and merge with confidence. Then open the PR with a short description of what changed and why.
We aim to review promptly. Keep PRs focused: one concern per pull request is far easier to review than a sweeping change.
Why bother
Contributing to a tool like CGraph is a fast way to build real skills — parsing with tree-sitter, graph data structures, deterministic systems, and the MCP interface that connects it to AI coding agents. And every improvement compounds: it helps everyone who uses the graph to understand their codebase.
Ready to start? Browse the open issues and find one with your name on it. More on how CGraph works is in our writing.