A week ago I opened a piece of code Claude Code had written for me. Looked at it and asked: "Wait — why did I tell it to do it this way?"

I couldn't remember.

I asked Claude again. The session was already closed. The new agent shrugged: "Not sure why, but merging these seems fine."

I blamed my memory at first. Started taking notes in Notion. Quit within a week — when you commit 30+ times a day with AI, hand-curated notes don't scale.

Eventually I had to admit it: this isn't a memory problem. It's a missing tool.

The blank git has never filled

git has recorded what changed almost perfectly for 20 years. But right next to it sits a blank that's never really been filled — why you changed it, and which alternatives you rejected.

When humans wrote code, that blank was invisible. The author carried the answer. You could ask the engineer across the desk, or even six months later they'd remember most of it.

The moment AI started writing code, the carrier vanished.

Agents review dozens of alternatives in a single session. They pick one. They discard the rest. Then the session closes and that reasoning is gone forever — not buried in some archive, just gone. The context
window evaporates with the session.

If you've been using Claude Code, Cursor, or any AI coding agent daily, you've probably felt this. Code you "wrote" last week feels foreign. Six months from now? You'll just rewrite it.

What I built

I started small. A hook that ran after every git commit, asking Claude Code to dump three things to a file:

1. The original prompt I sent
2. The alternatives Claude considered
3. Why it picked the one it did

Two months in, that single hook was saving me hours every week. Every "wait, why did I do this?" moment turned into a 30-second lookup instead of a half-hour archaeology dig.

Then I started wondering:

• What if a team could read this together?
• What if a past session's reasoning could auto-inject into the next session's context?
• What if a PM, who never opens the IDE, could see why today's decisions were made — in plain prose?

That hook became a product. It's called AIFlare.

How it works (the interesting part)

AIFlare is three layers:

1. Claude Code Hooks that fire on specific lifecycle events
2. A local stdio MCP Server that Claude Code spawns per session
3. A backend that stores entries and powers a shared web timeline

Layer 1: Hooks

Claude Code's hook system lets you attach scripts to lifecycle events. AIFlare attaches to four:

PostToolUse  (matcher: Bash + git commit)   →  capture context after commit
PostToolUse  (matcher: AskUserQuestion)     →  track when the agent asks the user
UserPromptSubmit                             →  accumulate prompts within a session
Stop / SessionEnd                            →  finalize session record

The most important is the first. The moment you run git commit, the hook fires a small Node.js script that:

1. Reads the latest commit hash via git rev-parse HEAD
2. Reads the cumulative prompts captured during this session
3. Asks Claude Code (via its internal context-capture Skill) to summarize intent, considered alternatives, and rejected paths
4. POSTs the result to the AIFlare backend, authenticated via per-user API key

All of this runs in the background — there's no manual step in the developer's flow. You commit, the entry appears in the timeline a few seconds later.

Layer 2: MCP Server

The local MCP server is a Node.js process spawned per Claude Code session via .mcp.json:

{
"mcpServers": {
  "aiflare": {
    "command": "node",
    "args": [".claude/mcp-server/dist/index.js"]
  }
}
}

It exposes 12 tools across 6 categories — session summary, daily/weekly digest, session compare, prompt evaluation, and a why lookup. Each category has both a fetch tool and a save tool. So when you run
/summarize inside Claude Code, the flow is:

1. MCP get_session_summary → returns structured aggregates from backend
2. Claude Code reads that, drafts a human-readable Markdown summary
3. MCP save_session_report → persists the Markdown back to the backend

This split matters: the LLM produces the prose, while the backend produces the facts. The two never confuse each other.

Layer 3: Backend

The backend is Kotlin + Spring Boot 4 with PostgreSQL (entry storage), Redis (session cache), and JWT auth for the web console + HMAC-SHA256 API keys for the hook and MCP.

Resource hierarchy is Org → Team → Project, scoped via a UserScopedRole table and a ScopedPermissionEvaluator wired into Spring's @PreAuthorize. Soft delete via @SQLRestriction, JPA auditing for
createdBy / updatedBy, virtual threads on Java 21 for the OTel collector pipeline.

The web console is Next.js 16 + React 19 + Tailwind 4 + Zustand. Server components for SEO-facing pages, client components for the dashboard.

Nothing exotic in the stack. The interesting part is the data model and the capture loop, not the framework choice.

Context Inject: closing the loop

Here's the feature that turned the tool from "useful notes" into something I rely on daily.

When you finish a session with /summarize, the Markdown report is stored to the backend with a sessionId. Days or weeks later, in a fresh Claude Code session, you can run:

/context-inject <sessionId>

The MCP tool fetches that past session's report and injects it directly into the new session's context. The new agent now knows what the last session decided, why, and what was rejected — before you've even typed
your first prompt.

This breaks the "every session starts from zero" problem. The decision history accumulates, and the agent gets smarter not from training, but from your team's actual record.

Future ideas (not built yet):

• Auto-inject relevant past sessions based on the files you're editing
• Warn the agent before it suggests a previously-rejected approach
• Enriched git blame that includes the original intent

What it looks like

(Cover image / inline screenshot would go here — timeline view, showing intent + alternatives + linked prompts in one card.)

Each entry is a card with:

• Intent — what the agent was trying to do
• Changes summary — auto-generated, more readable than raw diff
• Alternatives considered — including the ones rejected and why
• Linked prompts — the full user/AI conversation that led to this commit
• Files affected, tags, comments, favorites

The timeline reads more like a project blog feed than a git log. That's intentional — non-engineers should be able to follow along.

Stack summary

Installer is a single Node.js script that places hooks, skills, and the MCP server into .claude/ and a pre-push hook into .git/hooks/. One curl command, cross-platform.

Open beta — free, no card

I launched as open beta two days ago. Free, no card required. Korean / English / Chinese from day one.

What I'd most love isn't praise. It's the brutally honest version:

Here's exactly why I wouldn't use this.

That's the single most useful thing I can hear right now. If you try it and bounce, please tell me what made you bounce. Bug reports, "this is dumb because X," "I'd use this if Y" — all of it.

You can try the web demo or install in one line at https://aiflare.dev.

What I'm learning so far

A few things have already surprised me from early users:

1. Non-engineers care more than I expected.
I thought this was a tool for engineers. Two PMs and a designer asked to be added to the beta in the first 48 hours, saying they wanted to follow team decisions without bothering engineering. That's a use case I
underweighted.

2. The "rejected alternatives" piece is the wedge.
People think they want better commit summaries. What they actually want is to know what the agent didn't do, and why. That's the unique value I almost missed when scoping the MVP.

3. MCP + hooks together is more than either alone.
Hooks capture passively. MCP exposes actively. Either alone is half the story — passive capture without active retrieval is just a graveyard, and active tools without passive capture means manual data entry. The
combo is what makes the loop work.

Thanks for reading

If you've got a minute — try it at https://aiflare.dev, poke around the timeline, and send me the harshest, most specific feedback you can.

Or if you just have a thought from reading this, drop it in the comments. I'll read every one.