Your agent edits blind.
Glaux gives it sight.

Giving your agents the muscle memory of a senior engineer — churn, coupling, and blast radius on every file.

Request Your Repo

See what Glaux surfaces for these repos

tobi/qmdtransformerlab/transformerlab-app

Same bug. Two approaches.

without glaux
❯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
●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:
Graph context from Glaux
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). Changes here ripple.
src/qmd.ts — 76 commits, highest churn file. 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

What Glaux surfaces

Co-change coupling

Knows which files always change together — so agents check coupled files before editing, not after the build breaks.

Hub detection

PageRank identifies high-impact files that sit at the center of your codebase. Touch them carelessly, everything downstream breaks.

Blast radius

Linked issues and PRs show ripple effects. Agents see how far a change travels before writing a single line of code.

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

Muscle memory for coding agents. Context before code.

Request Your Repo