Your agent doesn’t know this file breaks everything

Agents read the file, understand the code, and make an educated change. But without churn history, co-change awareness, or linked issues — educated isn’t the same as informed.

Free for open source

Free for open source maintainers. We seed your repo, host the analysis, keep it updated. No setup, no cost.

Request Your Repo
Without Glaux
claude code
I want to fix https://github.com/tobi/qmd/issues/56
Bash(gh issue view 56)
├ title:    [BUG] error: handelize: path has no valid filename content
├ state:    OPEN
├ author:   Emasoft
└ +48 lines (ctrl+o to expand)
Searched for 2 patterns, read 1 file (ctrl+o to expand)
Now I understand the issue. The handelize function throws when filenames like [.md or ₂.₅.md don't
contain letters, digits, or $. The fix should be to not throw — instead, generate a usable handle from
whatever content is there.
★ Insight
[.md has filename [ which has no \p{L}, \p{N}, or $ — so it throws
₂.₅.md — these are mathematical symbols, not letters (\p{L}) or numbers (\p{N})
– The right fix: instead of throwing, use a content-hash fallback so indexing continues
The problem is on line 971–973. Instead of throwing, we should generate a fallback handle. Let me check
how this is used in indexing to understand what a good fallback looks like.
Searched for 2 patterns (ctrl+o to expand)
The handle is derived from the relative file path. For files with no "valid" content in the filename,
we should use a hash-based fallback. Let me look at existing tests too.
Searching for 2 patterns… (ctrl+o to expand)
└ "handelize"
★ Mulling… (32s · ↓ 511 tokens · thought for 4s)
qmdonmain|Opus 4.6
With Glaux
claude code
Skill(glaux-impact-check)
└ Successfully loaded skill
Bash(git remote get-url origin)
└ https://github.com/tobi/qmd.git
glaux — glaux_file_intel (MCP)(repo: "tobi/qmd", filePath: "src/store.ts")
└ {
"path": "src/store.ts",
"churn": {
… +111 lines (ctrl+o to expand)
glaux — glaux_file_intel (MCP)(repo: "tobi/qmd", filePath: "src/qmd.ts")
└ {
"path": "src/qmd.ts",
"churn": {
… +110 lines (ctrl+o to expand)
Searching for 1 pattern… (ctrl+o to expand)
Here's what Glaux told me:
src/store.ts — High PageRank (0.14), 62 commits, hub file. Co-changes strongly with
src/qmd.ts (35 times) and src/llm.ts (9 times). This means changes here ripple — I need to be surgical.
src/qmd.ts — 76 commits, highest churn file. Also tightly coupled to store.ts and llm.ts.
Key takeaway: Both files are central hubs. I should:
1. Prefer surgical edits — don't restructure the Store type
2. Check src/llm.ts too — it co-changes with both files
3. Keep the fix localized to hybridQuery
This is why I was hesitating on the "add reconnect()
to Store" approach — it would change the Store type,
which is a hub interface. A more contained fix would be better.
qmdonmain|Opus 4.6

Glaux didn’t write the code.
It changed the reasoning.

3 metrics surfaced

PageRank 0.14 (hub file), 62 commits (high churn), co-change coupling with qmd.ts (35×) and llm.ts (9×).

3 engineering decisions made

Prefer surgical edits. Check llm.ts too. Keep the fix inside hybridQuery — don’t touch the Store type.

Blast radius contained

The agent self-corrected away from reconnect() — the approach that would have broken 2 downstream files. Zero lines written, zero damage done.

Try it live

See which files in your codebase are fragile, tightly coupled, and high-churn.

Without vs. with Glaux

Without
  • Reads the file. Edits the file. Ships.
  • No awareness of 62 prior commits.
  • Doesn't know 3 files always change together.
  • Changes a hub type — breaks downstream.
  • Learns about blast radius from the build error.
With Glaux
  • Reads the file. Queries Glaux. Then decides.
  • Knows this file has high churn + PageRank.
  • Sees co-change coupling: qmd.ts (35×), llm.ts (9×).
  • Avoids type change — keeps fix localized.
  • Understands blast radius before writing a line.
Glauxglaux.dev

File intelligence for coding agents. Context before code.

Request Your Repo