Lore – Give your coding agent the decisions your team made

ttcballard about 3 hours ago 24 commentsRead Article on github.com

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

50% Positive

Analyzed from 693 words in the discussion.

Discussion (24 Comments)Read Original on HackerNews

philbo•about 2 hours ago

1. Write ADRs (or get agents to write them)

2. Commit ADRs to git

3. Mention ADRs in AGENTS.md

mzhaase•16 minutes ago

I have been doing this to great effect and it's maybe five lines instructions total.

tcballard•about 2 hours ago

I agree, that method might work if you are working solo or in a small team - but for organisations the ability to centrally manage and gate this sort of ruleset avoids drift.

bitlad•9 minutes ago

Yup. This works.

cisrockandroll•about 2 hours ago

Bad timing either way epic games release

tcballard•about 2 hours ago

Different beast — Epic's is version control, this grounds your agent in your team's decisions. Installs as rac either way, so the name's not load-bearing. But yeah, timing's a coincidence... just thought the name was cooler :D

slopinthebag•about 1 hour ago

LLM generated comments go against site guidelines.

tcballard•about 1 hour ago

I wrote this, I just spend enough time with LLMs to sound like one

messh•about 1 hour ago

Seems a bit similar to spec driven development. How does it differ?

tcballard•about 1 hour ago

So the line shifts, but I see it as SDD manages the change (spec → tasks → ship, then archive it); Lore holds the durable decisions that every change after it has to respect.

think of it as a layer above SDD and not a competitor, so basically you point your spec tool at the constraints Lore enforces.

alexmartos•about 2 hours ago

How does this compare to CLAUDE.md and other Rules you can put in markdown?

etoxin•about 2 hours ago

Or spec-driven AI development.

brainless•about 2 hours ago

I started building an app with similar goals but with the very different approach. I work on my own coding agent, https://github.com/brainless/nocodo, where I have been trying to build a provenance based engine that will generate or modify prompts to point to the decisions that a team has made. That work is in the branch: feature/praxis_agent_runtime

While working on this I figured what if I build a proxy for coding agents - Claude Code, opencode, Codex, etc. support a proxy. This proxy would edit prompts and tool_calls and feed context from an internal index it will maintain. That index will contain git logs, GitHub/JIRA/etc tickets/epics, PRD or other documents, tech stack setup.

It is just an idea and may not work but working at the proxy layer means this can be deployed at a team level, needs no MCP install and can re-shape prompts for everyone depending on the project. Wild idea perhaps.

tcballard•about 2 hours ago

I think the proxy angle is genuinely appealing for the reasons you give: team-level, no per-dev install, reshape every agent's context from one place. We went down that exact fork and chose against it (wrote up the reasoning as an ADR if you want it). Instead of intercepting and rewriting prompts/tool_calls, Lore does context-supply + post-edit enforcement.

Two things drove it:

One, a proxy that silently rewrites what the agent sees is hard to audit so you can't review an injection that never lands anywhere, and when it misfires you're debugging an invisible middle layer. We wanted the injected context to be a file in the PR diff (a generated CLAUDE.md/rules file) and the rest to be explicit read tools the agent chooses to call.

Two, and this is the part I'd flag for your index, the hard problem isn't delivery, it's knowing which decision is still current. An index built from git logs + tickets + PRDs is mostly stale or contradictory text; if a call got reversed six months ago, a fuzzy index will happily re-inject the old one. So that's where we spend the complexity budget: typed, human-reviewed decisions where "superseded" is enforced in CI, so the agent never gets handed a ruling you already overturned.

Which is why I think these compose rather than compete. Your proxy is a delivery mechanism; it still needs a trustworthy source for "the decisions this team made." That's what Lore is, and it exports for exactly this — rac export --documents (JSONL) or --graph to feed an index, --agent-rules for the injection layer. Stay fuzzy and convenient at recall, point back at a deterministic source for the part that has to be exactly right. Keen to see where praxis_agent_runtime goes — provenance-first is the right instinct.

tcballard•about 3 hours ago

Author here! Coding agents kept reworking decisions we'd already settled - reviving an approach we ruled out in an ADR, redoing something a requirement already pinned. The context was in the repo; the agent had no current view of it.

Lore serves your team's durable knowledge - requirements, decisions, designs, roadmaps, prompts - all as typed Markdown, read-only to Claude Code / Cursor over MCP, so the agent cites your decisions instead of contradicting them.

The bet: retrieval is deterministic. No embeddings, no vector store, no model call to pick what's relevant — same query, same bytes, same result, offline. It's not a RAG competitor; it composes — recall fuzzily, then verify the EXACT, CURRENT decision in Lore (it declines the ones you've superseded). Runs in CI (rac validate / rac gate) too.

  pipx install rac-core
  rac quickstart
  claude mcp add lore -- rac mcp

What it isn't: a search index, a memory layer, or an AI feature — the engine makes no LLM calls, no telemetry unless you opt in. Early, and my corpus is small, so I'd like to hear where deterministic grounding breaks down for you vs. where fuzzy recall is enough.

(Lore is the product; the engine under it is RAC — Requirements as Code, the `rac` package.) Apache-2.0, typed.