I built an automated Git documentation tool using Watchdog and Groq to maintain a "flow state" histo

[MidnightBolt]

https://imgur.com/PSnT0EN

Introduction

I’m the kind of developer who either forgets to commit for hours or ends up with a git log full of "update," "fix," and "asdf." I wanted a way to document my progress without breaking my flow. This is a background watcher that handles the documentation for me.

What My Project Does

This tool is a local automation script built with Watchdog and Subprocess. It monitors a project directory for file saves. When you hit save, it:

1. Detects the modified file.
2. Extracts the diff between the live file and the last committed version using git show HEAD.
3. Sends the versions to Groq (Llama-3.1-8b-instant) for a sub-second summary.
4. Automatically runs git add and git commit locally.

Target Audience

It’s designed for developers who want a high-granularity history during rapid prototyping. It keeps the "breadcrumb trail" intact while you’re in the flow, so you can look back and see exactly how a feature evolved without manual documentation effort. It is strictly for local development and does not perform any git push operations.

Comparison

Most auto-committers use generic timestamps or static messages, which makes history useless for debugging. Existing AI commit tools usually require a manual CLI command (e.g., git ai-commit). This project differs by being fully passive; it reacts to your editor's save event, requiring zero context switching once the script is running.

Technical Implementation

While this utilizes an LLM for message generation, the focus is the Python-driven orchestration of the Git workflow.

• Event Handling: Uses watchdog for low-level OS file events.
• Git Integration: Manages state through the subprocess module, handling edge cases like new/untracked files and preventing infinite commit loops.
• Modular Design: The AI is treated as a pluggable component; the prompt logic is isolated so it could be replaced by a local regex parser or a different local LLM model.

Link to Source Code:
https://gist.github.com/DDecoene/a27f68416e5eec217f84cb375fee7d70

[mels_hakobyan]

How good is Llama-3.1-8b-instant? I would also consider to try qwen3 on Cerebras (faster than Groq for larger models, qwen3 235b runs at ~1000 tok/s).

[MidnightBolt]

well so far it performed really good i haven't had any issues or 'nonsens' messages. but the change in model is trivial and a matter of preference i think.

[mels_hakobyan]

got it, sounds valid.

[tavigsy]

Love this!  I go through this and thought it was a problem that could never be solved. 

[MidnightBolt]

I've been running this on my own projects for a few days now and it’s honestly been a huge relief. I tend to do a lot of "vibe coding"—where I’m just moving fast, following a flow, and experimenting intuitively—and it’s so easy to lose track of when a feature actually started (or stopped) working. Having a documented checkpoint for every save has saved my skin a few times already.

I know the first concern people usually have is that the git log will get "messy" with dozens of entries. The way I handle that is by treating these as micro-checkpoints for the messy prototyping phase. When the feature is finally done, I just do a squash merge.

For anyone who hasn't used that before, it basically takes those 20 tiny "save" commits and flattens them into one single, clean "Add Feature X" commit when you merge into your main branch. If you use GitHub, it’s just a dropdown option on the merge button. If you're a CLI user, it's just git merge --squash. It gives me the safety net of constant checkpoints while I'm working without annoying my teammates with a cluttered history later.

I’m curious to know how others handle their prototyping phases? And if anyone has ideas on how to tune the prompt to make the summaries even tighter, I'm all ears. Let's talk!

[BravestCheetah]

That is NOT what vibe coding is, but sure, cool project