DEV Community: Brian Lim

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

Brian Lim — Mon, 13 Jul 2026 05:03:52 +0000

This is a submission for Weekend Challenge: Passion Edition

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 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; and 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

Install

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…

View on GitHub

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

How AI saved my life instead of destroyed it, with monorepository, architecture and patterns (Part One)

Brian Lim — Sat, 04 Jul 2026 05:22:33 +0000

(Free code and how to support me at the end!)

Two years ago I was like all of you at that time. I sat down to try and figure out what to create with this AI hype. I was apprehensive and didn't know what to make of it. So this thing, it can code, and replace me? The knee-jerk reaction was to say, human quality would always be better. But I knew that was a fragile argument. It might be true, it might not be, but if AI was getting better over time, I would be in a rat race not only with people now but with machines. Rise of the Machines.

The machines are coming. They're faster, smarter and sexier than you.

I knew that I had to take advantage of AI no matter what.

The main thing was I wanted to create some store of code that would last the rest of my life. Some way to bring my project to life. I won't talk very much about my specific project here, because it's not relevant to the point. What's the point is I wanted to reuse code, structure the code and create the code in such a way that AI could understand it and use it. AI that I told what to do, because I was the boss.

Most importantly, I wanted it to be mine. I wanted to own it, to do whatever I wanted with it, to sell it, to throw it out. I wanted it to be the capstone artifact of my entire career, to carry the lessons forward. I wanted to keep using it, forever.

This was long before MCP connectors and I'm fairly certain long before the Claude Code plugin for VSCode (at least I am 99% sure!) There was also an absolutely tiny context window of a few thousand tokens in Claude.

I also found that the Web UI, not being able to access my GitHub repository, needed the context not just of previous features but the architecture itself. To me, the entire point of having a machine do it all was consistency. Why do it myself, if a machine could do it and follow the rules? The point was to make it all mechanical, so I could focus on the code I wanted to or the work I wanted to and make a process all the work that I didn't want to.

So I made some immediate decisions

I wanted a monorepo. I never fully bought the idea of everything into one repository, but I was certain I wanted the code to be shared. But at the same time I wanted it all loosely coupled and zero dependency. I also wanted a shared CI/CD (if I wanted to make CI/CD). I was well aware of the simplicity and power of new repos every single time and working with Github Actions. But I knew that AI should have access to all the surrounding code and I thought maybe it would help
I wanted a monorepository packaging tool for caching, dependency management and folder structure
I wanted to use TypeScript and centralize all the typescript config files. Separate typescript config files for public and private, and separate typescript config files for each type of package such as library packages, backend packages, frontend packages and so on.
I wanted frontend and backend code in the same repository. But frontend and backend code have totally different packaging needs. So I would need separate configuration, but still centralized
I wanted to "manage the AI" somehow. Not just review the code, but make sure that the AI remembered what was happening between contexts.

I began in a very naive way cut ad pasting entire packages between new chat contexts. Since I wanted a foundation of code for potentially the rest of my life (ha) it had to start from zero dependencies. I had no idea what the database layer would be like, so I wanted to be database agnostic. I settled on an oldie but goodie -- the repository design pattern. But underneath it wouldn't be an ORM or anything like that. This was going to be raw, unrestricted power.

In order to ensure that the architecture was adhered to in the early days, I used an architectural document, examples document, progress tracker and code style document. When uploading the packages got too big (this was before Sonnet's 200k tokens) I vibe coded a summary tool. It would look at a package, extract all the function and class signatures and give the next context the calling surface, inputs and outputs. A lot of my architectural decisions began to pay off, like asking for pure functions with no side effects, and the strictest possible typescript settings. I began to realize that there was no way a human or a human team could maintain this discipline across dozens of packages without machine help. Either a linter would work or more likely the architecture would drift.

I had to conduct a major pivot from one cloud provider to another, and in fact to a completely different platforms (web to desktop then to web again). Some would call this learning, and maybe even a waste of time. But if you're reading this, you know that certain things can only be found out by doing it. It is not obvious, especially in the beginning, what kind of tech stack you should use. And you should be ready to pivot away from your tech stack, if a better choice comes available for the use case. Not just use what you know or what you're comfortable with.

It is now two years later and I have the following high quality of life for my side projects

Monorepository tooling that builds backend and frontend in seconds
Hundreds if not thousands of unit tests, for a project that has real staying power. I deliberately picked a topic that AI should have complete and total mastery on, where the examples are abundant and the field well understood for decades.
Deploy, revert and testing of database schema.
A future path for web, desktop and mobile applications, all in the same repository (I will talk about this more in a future article about how I am setting up the frontend and how the frontend will talk to the backend through shared React hooks)
Consolidated TypeScript and other configs so I would never have to setup config files again (yeah right)
An almost mechanical way of improving the architecture and design of my packages and monorepository. Paste handoff, list the required packages, ask the AI to "avoid technical debt and leaky abstractions", get a summary of the work, correct the AI as it made assumptions or mistakes and if satisfied with the work generate a handoff for the next context.
Constant progress towards my personal life goals

I truly think that without this, without doing this, I might be lost in a sea of despair looking at the future of AI as removing me from my work someday. Not everyone does machine learning. A lot of us are frontend developers, devops people, even just ordinary software engineers who use AI but don't make AI. There has to be a future for us, right?

In guerilla warfare, you try to use your weaknesses as strengths. They're big and you're small. You're mobile and they're slow. You capture your weapons and use them against them. That way they're supplying you.

Here is the free bit. Configuration files for your monorepository, to centralize all your Vite and Typescript configuration along with instructions. Adapted from my existing monorepository and cleaned for your use.

brian-lim-42 / typescript-config-public

Public TypeScript Configurations for a Monorepository for Libraries, Frontend and Backend

@yourscope/typescript-config

Centralized TypeScript, build, and test configuration for a monorepo. One place to define how strict your types are, how your packages build, and how your tests run -- every package extends from here instead of hand-rolling its own tsconfig.json.

Rename @yourscope to your actual npm scope before publishing. Everything else works as-is.

Why centralize this

In a monorepo, config drift is the default outcome, not an edge case. Twenty packages means twenty chances for one tsconfig.json to quietly diverge from the rest -- a missing strict flag here, a different module target there -- and nobody notices until a build breaks in a way that only reproduces in one package. Centralizing it doesn't just save you from writing the same JSON twenty times; it means a change to your standards is one edit, not twenty, and every package is provably consistent because they all extend the same file.

…

View on GitHub

And of course here is the shill. You had to know it was coming. I packaged the past two years of learnings and pivots and lessons into SKILL.md format, with commands and an actual mechanical workflow for building. For a small fee you can have it all. If you want it and you can't actually afford it (say you were laid off or you have a lot of obligations or commitments) contact me and I will give it to you free. If you buy it and you aren't satisfied, I will refund it. If you buy it, you'll be supporting someone like you, a coder, and fighting the good fight. And also getting two years of lessons and dead ends and false starts in a mechanical, systemic and repeatable process. I will be updating it as time goes on, so you will be getting a lifetime process that will update and grow with you.

All you have to do is install it with the python script into your git repository, and you can /kickoff and go. A few questions later and your feature or bug is dealt with by Claude Code.

(please click below)

Claude Code hooks and skills that mechanically block edits to files the agent hasn't read this session. Not a checklist but a working system for features and bugs.

Description: Claude Code doesn't fail loudly. It fails by being confidently, plausibly wrong — stating something about your code it never actually checked, assuming a shared type's shape instead of reading it, editing a centralized config without knowing what else depends on it. A green test suite doesn't catch this. A code review doesn't always catch it either, especially when you're the only reviewer. This kit is the discipline that does. It isn't a set of prompts to remember or a checklist to follow through willpower — it's two hooks that mechanically block an edit to a file Claude hasn't read this session, and nine skills that run the discipline instead of describing it: one that scopes a new feature or migration from a few keywords automatically, one that enumerates every real consumer of a file before you touch it, one that reads your own diff like a stranger would before you call it done. All of it was tested end-to-end against real Claude Code payloads before it shipped — not just described — including a TypeScript example that actually compiles under --strict and an installer verified against four real scenarios, including a project that already has its own hooks. Behind the mechanics is a twelve-stage methodology and six real failure patterns, generalized from two years of exactly this kind of work, so every rule comes with the reasoning for why it exists — not just the instruction to follow it. What you get: Two Python hooks enforcing read-before-edit, zero dependencies, tested against six real allow/block scenarios Nine Claude Code skills — six auto-invoke on their own when the situation fits, no command to remember METHODOLOGY.md — twelve stages from scope to handoff, including the closing-the-loop step most kits like this skip: verifying your own last session's handoff before trusting it LESSONS.md — six real failure-pattern case studies, each tied to the specific rule or skill that catches it faster A one-command installer, tested against four scenarios including a project with pre-existing hooks — never overwrites what you've already built A plain-text version for ChatGPT, Cursor, or any tool without hooks or skills Private GitHub repo access after purchase (invited within a week or two if GitHub User is provided to my email) — updates land there as the system improves, not a zip you download once and it goes stale An invite to a Discord server that's just getting started for buyers — comparing notes on what your own sessions catch, and a say in what gets built next, not an existing community to browse

briandev5.gumroad.com

Thanks for reading and may we all survive in the AI age. In Part Two and later I will go into specifics in later parts about the frontend, the backend, perhaps even talk about the project and how it evens the playing field between AI and humans. Sauce for the goose.

Good vibing everyone.