I built a kit to stop AI agents from lying about reading your code - then had to rebuild it for a tool that didn't exist yet
DEV Community

I built a kit to stop AI agents from lying about reading your code - then had to rebuild it for a tool that didn't exist yet

What I Built

The goal was to convert an existing Claude skill to Google AI. Gemini is no longer available for the free plan, so this is Google Antigravity.

Every AI coding agent has the same failure mode, no matter which model is behind it: it will state something about your codebase with total confidence and be wrong, because confidence and verification are different things, and nothing in a typical session forces the second one. It assumes a fallback path is safe because it looks like it should be. It calls a change to a shared type "additive" because the diff looks additive, without checking who actually imports it. It reports a green test suite as proof behavior is preserved, when all a green suite actually proves is that behavior is preserved for the inputs someone already thought to write down.

This isn't a smart-enough-model problem. It gets worse as sessions get longer, not better, because context fills up with things that feel true simply because they were said ten minutes ago.

The Session Discipline Kit

The Session Discipline Kit exists because "double-check your work" is an instruction an agent can nod along to and then quietly not follow, the same way a person under deadline pressure can. Prose rules get followed inconsistently. Mechanisms don't.

So instead of one more paragraph in a context file asking the agent to verify before it edits, this kit wires the rule into the environment itself: a hook that blocks any edit to a file the agent hasn't actually opened and read in the current session - full stop, regardless of how confident it sounds. That one mechanism catches an entire category of mistake before it ships, rather than three weeks later when it surfaces as "weird, rare, hard to reproduce" behavior that takes four times as long to track down as the missing read would have taken.

Verification is the floor, not the whole system. The rest is nine skills that map onto the actual shape of a real change, in the order it actually happens:

  • Stating a scope specific enough to be falsifiable before any code gets written, so there's something concrete to check a diff against later
  • Enumerating every real consumer of a shared file before touching it, because in a monorepo the diff always looks small and the blast radius is the number that doesn't
  • Scaffolding golden-snapshot tests for anything where correctness is about the shape of an output rather than one boolean, which is exactly where a green suite ships a real regression because the broken input never made it into anyone's hand-picked set
  • Reviewing a diff the way a stranger would, with no memory of writing it and no credit for reasoning that felt sound at the time
  • Regenerating a handoff document from the actual current repo state at the end of a session, not from what the conversation remembers about itself

That last one is worth sitting with, because it's the problem the rest of the kit ultimately exists to protect. A new AI session starts with zero memory of the last one, and everything about that situation pushes toward the agent either re-deriving context it already had - slow - or quietly assuming things it hasn't actually re-checked - fast, and eventually wrong. A handoff built from git status and a real diff, instead of from a conversation's memory of itself, breaks that cycle at the root: the next session inherits verified state instead of someone else's unverified confidence, however well-intentioned it was.

None of it is guesswork about what tends to go wrong. It's built from six real, generalized failure patterns, staged into a twelve-point methodology that names exactly which stage of a change each rule is protecting, plus a dedicated deep-dive on where it all bites hardest: centralized configuration in a TypeScript monorepo, where a small, confident, wrong edit reaches every downstream consumer before anyone notices.

Install it, wire the two hooks into Antigravity's hook system, and point your context file at one line. The discipline stops being something you have to remember to ask for every session, and starts being something the environment just enforces.

Demo

python3 install.py /path/to/repo

Code

brian-lim-42 / session-discipline-kit-antigravity

Stops AI coding agents from confidently guessing - hooks that block unverified edits, skills that scope work and hand off cleanly across sessions.

Session Discipline Kit for Antigravity CLI

Stops Antigravity from confidently guessing - hooks that block unverified edits, skills that scope work and hand off cleanly across sessions.

The problem

An AI coding agent starting a new session has no memory of the last one, no built-in sense of how far a change to a shared file reaches, and no mechanism forcing it to actually read a file before making claims about it. Left alone, that produces a specific, recurring set of failures:

  • Fallback paths that silently absorb cases they were never designed for
  • Additive-looking changes to centralized files that break four other packages
  • Green test suites that shipped a real regression because the broken input just wasn't in the set anyone thought to write down
  • Sessions that drift from a one-line bug fix into an unreviewable six-file change with no stated scope to check it against

None of this is…

How I Built It

That timeline is the shape of it - here's the texture. The kit didn't start as an open-source project. It started as a private discipline system for one developer's actual daily work: a solo founder building a compiler-heavy TypeScript platform, tired of watching an AI coding agent confidently state things about a codebase it hadn't actually checked. It lived quietly in a .claude/ folder, doing its job, until the ground it was built on shifted - a platform transition on Google's side cut off the free-tier access the next tool in line depended on, and what had been a working setup for one tool suddenly needed to work for a different one entirely.

The porting process is where it stopped being a routine rewrite. The first target, Gemini CLI, turned out to share a lot of DNA with the original - same JSON-over-stdin hook contract, same event-driven shape - right up until it didn't: the hook config went in confidently, and the CLI's own startup output immediately flagged an event name as invalid. Not a guess corrected by more research, but a real tool refusing a real config and saying exactly why. The fix went in, and a second, subtler mismatch showed up the same way - a tool's internal name didn't match its display name, a naming quirk the platform's own team had filed a bug about.

Then, before that version even finished settling, the platform itself got sunset for free-tier accounts and replaced with something new: a separate, closed-source rewrite with a barely-documented hook system that different sources described inconsistently, sometimes contradicting each other outright. There was no clean primary source to check against this time, so the response was to build for the disagreement instead of guessing past it - register the hook under every plausible naming convention, make the verification logic care about file state instead of tool-specific names wherever possible, and say plainly, in the code itself, which parts were confirmed and which were a reasonable bet.

Which is the part worth sitting with: a kit whose entire purpose is refusing to trust an unverified claim was built by applying that exact standard to itself, at every step. Nothing about a target platform's hook schema got accepted because a blog post said so confidently - it got checked against what the live tool actually did, the same way this kit insists an agent check a file instead of trusting its memory of one. Where that check failed the first time, it got corrected the same way a session drifting off course gets corrected: not by trying harder to guess right, but by looking at the real output and updating.

The methodology didn't just get built and then, separately, proven to work. Building it was the first real test of it.

Prize Categories

Best Use of Google AI

Comments

No comments yet. Start the discussion.