4 tools I built because I don't trust AI to check AI's work

If you've spent any real time working with coding agents, you've
probably watched one of them touch a file that had nothing to do with
the task. Or seen a schema quietly change underneath a tool you
depend on. Or tried to figure out, after the fact, which one of 500
subagents actually caused a run to go sideways.

The obvious fix is "have another AI check it." I didn't want that fix.
An LLM judging LLM output costs tokens on every single run, its
reasoning is a black box you can't fully audit, and it can be wrong in
ways that are hard to catch precisely because it sounds confident.

So I built four small tools that do the boring, deterministic version
of the same job instead — AST parsing, graph algorithms, statistics.
No model in the loop. Same answer every time, for free.

TL;DR

Tool	Catches	Cost per run
skillcheck	broken SKILL.md files agents rely on	$0
mcp-schema-watch	breaking changes in MCP servers you depend on	$0
pr-blast-radius	PR scope creep, via import-graph analysis	$0
swarm-trace-viewer	where a large agent swarm actually diverged	$0

All four are MIT licensed. Here's what each one actually does.

skillcheck — a linter for the files your agents read

Claude Code, Codex, and Cursor agents all read SKILL.md files to
learn how to do something. Nobody lints those files. skillcheck does:
missing frontmatter, broken relative links, descriptions that are too
short to be useful or too long to fit in context comfortably, and a
hard token budget so one skill file can't quietly eat half an agent's
context window before it's done anything.

Ships as a CLI and a composite GitHub Action, so it runs in CI the
same way ESLint does.

github.com/DIYA73/skillcheck

mcp-schema-watch — breaking-change detection for MCP servers

MCP servers can change their tool schemas without any warning, and if
your code depends on one, that shows up as a silent failure in
production, hours after the actual change happened. This polls the
servers you configure, snapshots each tool's schema, and diffs it
against the last snapshot on every run — classifying every change as
either breaking (a required param appeared, a param was removed,
a type changed) or informational (a description changed, an
optional param was relaxed). Slack only fires on the former.

Postgres for history, BullMQ for scheduling, a small REST API to
manage what's being watched.

github.com/DIYA73/mcp-schema-watch

pr-blast-radius — scope creep, proven with a graph, not a vibe

This is the one I'm most attached to. It parses the real AST of every
file in your repo, builds the import graph, and checks whether the
files changed in a PR are actually connected to each other:

Blast radius (connected-components mode)

  ✓ src/userService.ts
  ✓ src/utils.ts
  ✗ src/paymentService.ts  Not import-connected to the main
                            group of changed files (group size: 1)

3 source file(s) changed, 1 flagged

Two files that import each other are obviously part of the same
change. A third file with no import relationship to either one, sitting
in the same PR? That's worth a second look — and unlike a model's
opinion, this verdict comes from the actual dependency graph, so it's
the same answer every time you run it.

It also excludes high fan-in "hub" files (a shared types.ts, a
barrel index.ts) from the connectivity check first — otherwise every
file in a codebase that imports the same central file looks
"connected," and the whole check becomes noise. Runs as a GitHub
Action that comments on the PR and updates that comment on every
push, instead of leaving a trail of duplicates behind.

github.com/DIYA73/PR-Blast-Radius-

swarm-trace-viewer — finding the one agent that actually broke

The newest of the four, and still just the foundation layer. When an
orchestrator fans out into hundreds of subagents, a run failing
doesn't tell you much on its own — was this agent the actual cause,
or just downstream of something that failed three levels up?

This builds the full agent tree from a flat event list, then walks it
to separate root-cause failures from cascades, and flags
statistical outliers among sibling agents — the one subtask that took
10x longer than its five siblings for no obvious reason. It ships with
a fully deterministic synthetic trace generator, seeded so the same
input always produces the same trace, since there's no public
1,000-agent orchestrator to record real traces from yet.

Live streaming and the actual tree/timeline UI are next.

github.com/DIYA73/swarm-trace-viewer

The pattern

None of these are clever. That's kind of the point — a z-score, an
import graph, and a tree walk will give you the same verdict at 2am as
they will at 2pm, and they'll do it without a bill. As agents write
and orchestrate more of our code, I think there's real room for tools
that check that work the boring way.

All four repos are open for issues and PRs. If one of these solves a
problem you actually have, I'd genuinely like to know.