Launching today

oobo

Launching today

Git layer that preserves the why behind AI-written code

15 followers

Git layer that preserves the why behind AI-written code

15 followers

Visit website

Git clients

Oobo is Git for agents (and humans). It enriches your repo with additional context about AI usage, helping agents and teams understand why something was built, how decisions were made, and what happened around the code, not just in the final diff.

Free

Launch tags:Developer Tools•Artificial Intelligence•GitHub

Launch Team

AppSignal — Full-stack monitoring for errors, metrics, and logs

Full-stack monitoring for errors, metrics, and logs

Promoted

oobo

Maker

📌

We built Oobo because AI is writing more and more of the code, but almost none of the context around that work is preserved in a useful way. You see the final diff, maybe a commit message, but not what the agent was trying to do, why a decision was made, what changed during the process, or how a human and one or more agents got to that result. That started feeling like a real gap. The idea evolved into a Git decorator because we didn’t want to replace Git or force people into a brand new system. Git already owns the code history. What was missing was the extra layer of context around AI usage and build decisions. So Oobo became a way to enrich normal Git workflows with that missing context, making it easier for both agents and humans to understand what happened around the code, not just the code itself.

Report

10h ago

How does Oobo capture and structure AI decision context without significantly increasing repository size or slowing down existing Git workflows?

Report

3h ago

oobo

Maker

Great question @mordrag, three design decisions make this work:

1. Git runs first, Oobo enriches after. Oobo sits in front of git as a transparent proxy (alias git=oobo). When you run git commit or oobo commit, the real git binary executes first and completes at full native speed. Only after a successful commit does Oobo attach metadata such as session links, attribution, token counts. If anything goes wrong with the enrichment step, the commit still succeeds. Oobo never blocks git.

2. Metadata lives on a separate orphan branch, not in your code history. Anchor data is written to an orphan branch (oobo/anchors/v1) using low-level git plumbing commands, so your working tree, index, and code history are never touched. Each anchor is a small JSON file (~1-2 KB) keyed by commit hash. It doesn't show up in git log, doesn't affect diffs, and doesn't bloat your main branch. Entries are sharded by hash prefix (similar to git's own object storage), so concurrent agents writing anchors never create conflicts.

3. Heavy data stays local by default. Full transcripts, search indexes, token analytics, and cross-project queries all live in a local SQLite database, not in the repo at all. Only lightweight metadata syncs through git. Transcript sync is opt-in (we call it "transparency mode") and even then, transcripts are redacted before they leave your machine.

The net effect: a typical commit adds maybe 50-100ms of overhead and a few KB to a branch you'll never look at directly. Your git log, your diffs, your CI are all unchanged.

Report

24m ago

Great question @mordrag, three design decisions make this work:

The net effect: a typical commit adds maybe 50-100ms of overhead and a few KB to a branch you'll never look at directly. Your git log, your diffs, your CI are all unchanged.