DEV Community: Manan Sharma

I built Github actions workflow for cxgrd

Manan Sharma — Sat, 22 Aug 2026 17:53:24 +0000

I recently built and shipped GitHub Actions workflow for cxgrd. I built it to automate the scanning of project directory by the scan command and blast radius analysis by the check command, on every PR created.

What it does

When ever a PR is created,

The project dependencies and cxgrd are installed
The project is scanned with cxgrd scan
check command is used to run blast radius analysis and compiler checks
The results (risk level, affected files, changed types ) are posted as a comment to the PR.

The comment is updated on every subsequent run, instead of posting a new comment.

How I built this

The check command already had BlastRadiusAnalyzer being used for posting CI check results to DB and team dashboard. The only thing was to create a --json flag to extract the result in json format and post it as a comment.
The thing I found interesting was, I didn't have to use auth for posting the comment. While I was designing the flow, I came across something new: GITHUB_TOKEN, which Actions inject into every PR, and is scoped to the specific repo, with permissions to comment. So, I just needed to write a small JS script, something like this:

permissions:
  pull-requests: write

steps:
  - uses: actions/checkout@v4
  - run: cxgrd check --json > result.json
  - uses: actions/github-script@v7
    with:
      script: |
        const fs = require('fs');
        const result = JSON.parse(fs.readFileSync('result.json'));
        await github.rest.issues.createComment({
          owner: context.repo.owner,
          repo: context.repo.repo,
          issue_number: context.issue.number, // PR number, auto-available
          body: `## CXGRD Blast Radius\n\nRisk: ${result.risk}\n...`
        });

inside the .yml file.

Why I built this

I thought, the reason behind low adoption of cxgrd is that the users have to run CLI commands on their own. So I wrapped the core feature inside a CI workflow file.

Maybe this will help cxgrd grow.

Checkout the GitHub Action here.

I am open to any feedback which will help me and my tool grow.

How cxgrd differs from AI agent-based code review tools

Manan Sharma — Sat, 15 Aug 2026 09:33:23 +0000

In my previous post, I introduced the CLI tool CXGRD which I built to prevent agents from breaking architecture.

CXGRD computes blast radius using dependency graph traversal — a deterministic analysis of real import, call, and reference relationships in your codebase. This post explains what that means and how it differs from AI agent-based code review tools.

The core difference

AI agents (like an LLM-based code review tool) reads a diff and predicts what might be affected, based on pattern matching over the code it's shown. The output is a judgment — probabilistic, and it can miss relationships that aren't visible in the diff it was given, or hallucinate connections that don't exist.

CXGRD instead builds an explicit graph of your codebase's real dependencies — which files import which, which functions call which — and traces a change through that graph mechanically. A dependency edge either exists in the graph or it doesn't. There's no inference step where an edge could be missed or invented.

Why this matters in practice

	AI agent interpretation	CXGRD dependency graph
Basis	Model's reading of the diff	Actual import/call relationships
Consistency	Can vary between runs on the same input	Same input always produces the same result
Failure mode	Can miss or hallucinate a relationship	Can only miss relationships the graph itself doesn't model (e.g. dynamic imports)
Explainability	"The model flagged this as risky"	"File X imports function Y, which changed" — a traceable path

Where AI still adds value

CXGRD isn't anti-AI — Pro and Team tiers use an LLM (Groq) for prompt enrichment: turning a computed blast radius into a clear, readable prompt for feeding into an AI coding assistant's context window. The graph traversal that determines what is affected stays deterministic; the LLM's job is limited to explaining that result in natural language, not deciding it.

This is where CXGRD complements tools like Cursor or Claude Code rather than competing with them: those tools govern the actions an AI agent takes while writing code, while CXGRD governs the consequences of a change once it exists — checking blast radius before merge, regardless of whether the code was written by a human or an AI assistant.

See how CXGRD works here.

Why AI Coding Agents Fail on Large Repos: The Stateless Context Problem

Manan Sharma — Fri, 10 Jul 2026 11:52:24 +0000

Let's be honest - stateless AI tools are incredibly powerful, but they have terrible short term memory, and are context-limited. They look at your repo through a keyhole — whatever's visible in that one session is all they know.

You've probably seen your AI tool trying to fix one thing and break several others. This happens because they don't know what else in your codebase depends on that particular module it is editing.

Modern codebases are deeply interconnected, and as repos grow, it gets harder for AI agents to track every dependency, architectural layer, and downstream effect.

I ran into this constantly while building a PR reviewer tool. Every time I asked AI to fix one thing or add a feature, it would quietly break something else. I wondered if it was possible to provide a complete dependency map to the entire codebase which can tell AI something like, "Hey, you just changed what this method returns, but you forgot about these 3 modules importing it".

To fix this problem, I built a CLI which I call CXGRD . It maps your code, builds dependency graphs, calculates blast radius and provides enriched prompts for AI tools, while at the same time verifying the changes made by performing compiler-backed checks. It's free to try — npm install -g cxgrd and run cxgrd scan on any repo.

Would genuinely love feedback from anyone who's hit the same "fix one thing, break three" problem.

GitHub : https://github.com/cxgrd