stn.
Get Started Free

The context graph

The context graph is the connective tissue between your work and your codebase. It's what turns a stream of day-to-day work into answerable questions like "who last touched this file and why?" and "what did we decide about the job queue?" — for your team and for the agents querying it over MCP.

What's in it

The graph has a few kinds of node, discovered from your activity and your integrations:

  • Repos — the codebases your work touches, with their branches.
  • Tracker projects — Jira/Linear/ClickUp/Monday projects, and the work items (tickets) inside them.
  • Files & directories — the file tree inside a repo, down to the path#symbol level.
  • People & teams — who's involved.
  • Your entries, decisions, checkpoints, episodes, and bugs, which anchor into all of the above.

Edges and links

Nodes connect two ways. Edges are internal relations — a decision supersedes another, a checkpoint touches a file, work happens in_repo. Links point outward to an external system — a Jira key, a GitHub PR url — and carry live status (open/merged, ticket state) once the matching integration is connected.

You create links explicitly with stn link, and they also accrue automatically from captured git context and inbound webhooks.

How you traverse it

stn search "job queue"                 # find any node by content or identity, with its context
stn file-context app/billing/services.py   # decisions, touchers, and PRs for a file/dir/symbol
stn graph neighbors decision 42        # one hop: everything connected to a node
stn graph path decision 42 --rel supersedes   # walk a chain of one relation

These are documented in full under Decisions & search and Brag, export & graph. The graph fills in as you checkpoint with git context, install ambient capture, and connect integrations — there's nothing to set up by hand.