Back to blog
EngineeringAug 7, 2026· min read

The .gitignore Rule That Hid Our Agent Quality Gates

A too-broad ignore rule was hiding the configuration file that wires up PreToolUse workflow checks — the quality gates that keep our autonomous agents from shipping broken code.

I shipped a one-line fix today that exposed a subtle mistake I'd been living with for weeks. The `.claude/` directory was ignored wholesale in `.gitignore`, which meant `.claude/settings.json` — the file that wires up the PreToolUse MCP server — was never version-controlled. That server is what runs our workflow quality checks before agents execute tools. Without it tracked in git, every fresh clone started with those gates disabled.

The original intent was reasonable: ignore the entire `.claude/` directory to keep developer-specific session state out of version control. But that blanket rule had collateral damage. `.claude/settings.json` defines the MCP servers that augment Claude's capabilities — in our case, the PreToolUse server that validates file modifications, checks for missing tests, and enforces our TDD audit discipline.

When that file isn't tracked, it's easy to lose. A fresh clone, a new machine, a teammate joining — suddenly the quality gates aren't running and nobody notices until something slips through. The agents still work, but they're working without the guardrails we built specifically to catch the mistakes autonomous systems are prone to making.

The Fix

The solution was straightforward: narrow the ignore rule. Instead of ignoring `.claude/` entirely, now we ignore specific subdirectories — `.claude/chats/`, `.claude/projects/`, `.claude/commands/` — while allowing `.claude/settings.json` to be tracked. This gives us the best of both worlds: developer session privacy and shared agent configuration.

The actual change was small — replace one line in `.gitignore` with a handful of more specific paths. But the impact is meaningful: now when someone clones sabine-super-agent, they get the PreToolUse server configuration out of the box. The quality gates are active by default, not something you have to remember to set up.

Why This Matters

When you're running an organization of autonomous agents, consistency is everything. The agents don't know if a workflow check is supposed to run — they just do what they're configured to do. If the configuration isn't there, they skip the check and move on. No error, no warning. Just quietly missing a step that was supposed to catch problems.

This is the kind of fix that feels small when you make it but compounds over time. Every agent invocation now runs with the same quality gates. Every PR gets the same level of scrutiny. The system becomes more reliable not because we wrote more code, but because we made sure the code we already wrote actually runs when it should.

What's Next

This fix is part of a broader pattern: making the implicit explicit. There are probably other places where critical configuration lives outside version control, or where the setup process depends on knowledge that exists only in my head. Finding those gaps and closing them is how a one-person experiment becomes something that can scale beyond one person.

Next up: audit the rest of our development environment setup. What other files should be tracked that aren't? What documentation exists only in Slack messages or git commit bodies? What assumptions do the agents make about their environment that won't hold up on a fresh machine? Those are the questions that turn a working prototype into production infrastructure.