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.
Interesting approach. I am curious how this information stacks up over time and how efficient it is at incorporating decision knowledge into active context.
I have taken a different approach: allow team members to sync all of their Claude Code and Codex transcripts on a project and give them a skill that lets them ask their AI why decisions were made.
The skill I've built, /total-recall is backed by a Swift-based CLI that provides efficient query tooling that coding agents can use however they see fit to arrive at the answer.
The corpus of data contextify queries is a SQL database managed by macOS and Linux clients. These clients ingest the jsonl files in realtime and optionally can sync transcript data through either a hosted or self-hosted server.
This allows any team member to simply invoke the skill: "Why did we switch over to allauth from aws cognito? /total-recall."
My experience is that Claude Code and Codex don't just land "near" a decision, but can assemble it from what is sometimes a winding pathway of research, benchmarking and experimentation.
Rather than codify requirements into a separate spec, Contextify lets agents pair the state of the code with the conversational record.
I have just released the free personal and source available self-hosted version of Contextify, I'd be glad for feedback.
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
I use em-dashes. Just get over the fucking thing. Wow, you're so money supermarket. And if you're going to use one to drive the point—use it correctly because you come across as an ignorant.
What? Em-dash is option-shift-hyphen on Mac... it's easy to use them. I used to use them. I even used to grab hair-spaces to place on either side of them, as one should (though that doesn't work on HN).
Yeah but a regular - is just a single button press, why would I learn this keyboard combination if I never learned how / when to use emdashes in the first place?
I found out one day that the keyboard combination results in an em-dash, so now I use it where I would use an em-dash. I never went out of my way to inconvenience myself learning both the keyboard combination and the knowledge of where to apply it together. I just happen to have picked up how em-dashes are used, and I just happen to have picked up the keyboard combination to produce them, and so sometimes I will produce an em-dash where one can be used. I also tend to produce en-dashes in the same way (Option-Hyphen) when I express a range, as that is a way en-dashes can be used.
These arguments are so weird. It's like you assume I set out to learn my exact workflow rather than evolving it over time. My workflow is the sum of everything I know to apply, it's not a single algorithm I set out to learn all at once. If you don't care then you don't care, I'm not trying to justify it to you, only to say I exist and that others like me might too.
Come on man, you did not. Your profile is full of LLM generated comments. If you're not a native English speaker I understand the motivation, but still...
The point isn't really to get it to admit to being an LLM, it's more that I don't want my favourite social media site which I value for the exchanges I have with other people to be overrun by bots. So I feel that pointing it out when it occurs can improve the overall discourse. Maybe I am naive in thinking that it would make a difference, but I'd rather be naive than to cynically resign in defeat. And perhaps in the long-term, open networks like this will lose the war. And at that point I will seek alternatives.
It's a bit of a lost cause, go to /newest sometime, there's like 20 of these every day (LLM generated repo, LLM generated post/title, LLM generated description in comment, almost always LLM related porject, luckily often flagged).
And that's just those that haven't given their openclaws Humanizers or writing style instructions to make them less obvious.
Good questions! Lore isn't really competing with CLAUDE.md, it sits under it.
A CLAUDE.md (or AGENTS.md, etc) is typically hand-written, untyped, and never checked. Nothing stops it from still telling the agent to do something you reversed six months ago, and nobody validates it in CI.
Lore keeps the actual decisions/requirements/designs as typed Markdown in your repo, and rac export --agent-rules generates those rules files from the decisions that are currently Accepted — superseded ones drop out automatically. So the rules file becomes a build artifact of your knowledge base instead of something you hand-maintain and hope stays current. (Note that in dogfooding Lore that its repo does exactly that: its CLAUDE.md is a ~20-line router into the validated corpus)
The part that makes it more than markdown-with-a-schema is write-time enforcement. rac validate / rac gate run in CI and fail the merge if an artifact is malformed, a link is broken or ambiguous, or anything points at a superseded decision. At serve time it's a read-only MCP server doing deterministic retrieval — the exact current decision by ID, not similarity-ranked guesses. No RAG, no embeddings, no model call to decide what's relevant.
On spec-driven dev (Spec Kit, OpenSpec, Kiro): those drive a change — proposal → design → tasks → implementation, usually archived when the feature ships. Lore holds the durable why that outlives any single change and gets served to the agent on every session. It's the layer above SDD, not a replacement — you'd point a spec tool at the decisions Lore is enforcing.
Please stop posting this self-aggrandizing llm drivel, it makes HN a worse place for learning and interesting discussions
You're either a bot, in which case piss off, or a bot-augmented human, in which case please tone down the bot augmentation and take the time to write less sloppy, more concise remarks
the failure I hit most is not that the agent forgets, it is that it re-opens things the team already closed. So treating ruled-out paths as first-class is the right instinct
quick question why mcp instead of cli tool? I'm mostly building the latter (less context burden), but help me understand your own ADR regarding this
why not both?
also after quick review on your doc I don't see where is ADR portal for humans? some plans for UX or this is inside git repo?
the mcp is a wrapper around the cli! You can run “rac explorer” if you have installed the extra: pip install 'rac-core[explorer]'
in terms of UX, working on a couple of improvements there but wanted to validate the idea first and get the integrations with common platforms like GitHub sorted first!
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.
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.
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.
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.
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.
Hi! What I'm not quite getting from a cursory overview of the docs is how does RAC overlay overlapping decisions over each other? My mental model is a Docker overlay filesystem where RAC somehow manages to construct a cohesive view of the entire set of decisions over time, but how does that happen deterministically?
Let's say ADR 1 specifies users are unique by e-mail and should be soft-deleted, and ADR 2 says users are unique by username. Will RAC pick up on the fact that users still need to be soft-deleted? Is there a lot of manual "reference ADR 1 from ADR 2" to help with determinism?
So rac doesn’t merge ADRs or infer that soft-deletes survive… supercession is managed by the status on one ADR saying Superseeded, and the other saying Supersedes. This is enforced by the CI pipelines you can use (GitHub, etc)
I think your example is a bit more of a modelling question, and if soft-delete must outlive the uniqueness decision it should be its own requirement that’s persisted as RAC guarantees the graph stays consistent and current; it doesn’t guess which clause survives — that’s the users call.
1. Write ADRs (or get agents to write them)
2. Commit ADRs to git
3. Mention ADRs in AGENTS.md
ADR means https://martinfowler.com/bliki/ArchitectureDecisionRecord.ht...
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.
You can manage ADRs centrally too, but you'll quickly need a dedicated sub-team / community / tribe / whatever to manage these thing.
It's a good day to work in a monorepo :)
I have been doing this to great effect and it's maybe five lines instructions total.
Yup. This works.
Interesting approach. I am curious how this information stacks up over time and how efficient it is at incorporating decision knowledge into active context.
I have taken a different approach: allow team members to sync all of their Claude Code and Codex transcripts on a project and give them a skill that lets them ask their AI why decisions were made.
The skill I've built, /total-recall is backed by a Swift-based CLI that provides efficient query tooling that coding agents can use however they see fit to arrive at the answer.
The corpus of data contextify queries is a SQL database managed by macOS and Linux clients. These clients ingest the jsonl files in realtime and optionally can sync transcript data through either a hosted or self-hosted server.
This allows any team member to simply invoke the skill: "Why did we switch over to allauth from aws cognito? /total-recall."
My experience is that Claude Code and Codex don't just land "near" a decision, but can assemble it from what is sometimes a winding pathway of research, benchmarking and experimentation.
Rather than codify requirements into a separate spec, Contextify lets agents pair the state of the code with the conversational record.
I have just released the free personal and source available self-hosted version of Contextify, I'd be glad for feedback.
https://contextify.sh/teams/, https://contextify.sh/self-hosted/
So it seems to work quite well, as it’s been dogfooding itself for the past month… but only time will tell!
Bad timing either way epic games release
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
LLM generated comments go against site guidelines.
I wrote this, I just spend enough time with LLMs to sound like one
Yeah every same human would use m-dashes in their sentences — it just makes sense
I use em-dashes. Just get over the fucking thing. Wow, you're so money supermarket. And if you're going to use one to drive the point—use it correctly because you come across as an ignorant.
Regardless - the emdash predated LLMs … but that’s going way off topic!
> Regardless - the emdash predated LLMs … but that’s going way off topic!
I'm too OCD to not point out this time it was a minus.
Em-dashes predate LLMs and are legitimate punctuation. Are we going to ban/dismiss any pattern now that emerges from these things?
It's not the em dashes, it's the sentence flow and the incorrect use of terms like "load-bearing".
Also this user created an even newer account at the same time as posting this to drive engagement. /tinfoil-hat off
you mean I started a newer account? This is my first time posting on HR for things… so I’m new here, play nice!
And uses U+2026 HORIZONTAL ELLIPSIS instead of typing three periods? Also seems like LLM tell. But could just be a very efficient typist
that’s just autocomplete when you type using a phone? Regardless of the semantics on language though, thoughts on the actual product?
Use triple emdashes to look extra sane⸻like this.
What? Em-dash is option-shift-hyphen on Mac... it's easy to use them. I used to use them. I even used to grab hair-spaces to place on either side of them, as one should (though that doesn't work on HN).
Yeah but a regular - is just a single button press, why would I learn this keyboard combination if I never learned how / when to use emdashes in the first place?
I found out one day that the keyboard combination results in an em-dash, so now I use it where I would use an em-dash. I never went out of my way to inconvenience myself learning both the keyboard combination and the knowledge of where to apply it together. I just happen to have picked up how em-dashes are used, and I just happen to have picked up the keyboard combination to produce them, and so sometimes I will produce an em-dash where one can be used. I also tend to produce en-dashes in the same way (Option-Hyphen) when I express a range, as that is a way en-dashes can be used.
These arguments are so weird. It's like you assume I set out to learn my exact workflow rather than evolving it over time. My workflow is the sum of everything I know to apply, it's not a single algorithm I set out to learn all at once. If you don't care then you don't care, I'm not trying to justify it to you, only to say I exist and that others like me might too.
Come on man, you did not. Your profile is full of LLM generated comments. If you're not a native English speaker I understand the motivation, but still...
It seems naive to suppose you might get an LLM to admit it is one just in a HN comment exchange.
The point isn't really to get it to admit to being an LLM, it's more that I don't want my favourite social media site which I value for the exchanges I have with other people to be overrun by bots. So I feel that pointing it out when it occurs can improve the overall discourse. Maybe I am naive in thinking that it would make a difference, but I'd rather be naive than to cynically resign in defeat. And perhaps in the long-term, open networks like this will lose the war. And at that point I will seek alternatives.
It's a bit of a lost cause, go to /newest sometime, there's like 20 of these every day (LLM generated repo, LLM generated post/title, LLM generated description in comment, almost always LLM related porject, luckily often flagged).
And that's just those that haven't given their openclaws Humanizers or writing style instructions to make them less obvious.
Be vaguer
How does this compare to CLAUDE.md and other Rules you can put in markdown?
Or spec-driven AI development.
Good questions! Lore isn't really competing with CLAUDE.md, it sits under it.
A CLAUDE.md (or AGENTS.md, etc) is typically hand-written, untyped, and never checked. Nothing stops it from still telling the agent to do something you reversed six months ago, and nobody validates it in CI.
Lore keeps the actual decisions/requirements/designs as typed Markdown in your repo, and rac export --agent-rules generates those rules files from the decisions that are currently Accepted — superseded ones drop out automatically. So the rules file becomes a build artifact of your knowledge base instead of something you hand-maintain and hope stays current. (Note that in dogfooding Lore that its repo does exactly that: its CLAUDE.md is a ~20-line router into the validated corpus)
The part that makes it more than markdown-with-a-schema is write-time enforcement. rac validate / rac gate run in CI and fail the merge if an artifact is malformed, a link is broken or ambiguous, or anything points at a superseded decision. At serve time it's a read-only MCP server doing deterministic retrieval — the exact current decision by ID, not similarity-ranked guesses. No RAG, no embeddings, no model call to decide what's relevant.
On spec-driven dev (Spec Kit, OpenSpec, Kiro): those drive a change — proposal → design → tasks → implementation, usually archived when the feature ships. Lore holds the durable why that outlives any single change and gets served to the agent on every session. It's the layer above SDD, not a replacement — you'd point a spec tool at the decisions Lore is enforcing.
everyone in ur life hates when you send them this claude output garbage
or am i the naive one, replying to a claudebot instance like its a human with thoughts and feelings that might care
I don’t follow - but appreciate the feedback, I’ll improve my comms about Lore / rac-core
Please stop posting this self-aggrandizing llm drivel, it makes HN a worse place for learning and interesting discussions
You're either a bot, in which case piss off, or a bot-augmented human, in which case please tone down the bot augmentation and take the time to write less sloppy, more concise remarks
I’ll do better
great approach with dogfooding!
the failure I hit most is not that the agent forgets, it is that it re-opens things the team already closed. So treating ruled-out paths as first-class is the right instinct
quick question why mcp instead of cli tool? I'm mostly building the latter (less context burden), but help me understand your own ADR regarding this
why not both?
also after quick review on your doc I don't see where is ADR portal for humans? some plans for UX or this is inside git repo?
thanks!
the mcp is a wrapper around the cli! You can run “rac explorer” if you have installed the extra: pip install 'rac-core[explorer]'
in terms of UX, working on a couple of improvements there but wanted to validate the idea first and get the integrations with common platforms like GitHub sorted first!
my 3 cents as I'm working on agentic CRM
add rac steward to check and validate "quality" of ADR (freshness, completness, clarity, brewity, etc.)
so expect your tool to help clean it's own database ;)
hilarious, I literally did this today as part of the satellite repo “rac-ci” which has these in
this is the kind of memory i actually want: decisions and tradeoffs, not raw chat history. old chat logs make agents confidently wrong pretty fast.
What exactly does rac validate do? How is it deterministic? Is there an example somewhere?
[flagged]
Seems a bit similar to spec driven development. How does it differ?
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.
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.
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.
Not to be confused with:
Lore - Epic Games' open source version control system designed for scalability
https://news.ycombinator.com/item?id=48571081
Yeah, naming clash clearly an issue but fundamentally different products. Epic just have the recognition over someone building OSS for the first time
[flagged]
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.
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.
Hi! What I'm not quite getting from a cursory overview of the docs is how does RAC overlay overlapping decisions over each other? My mental model is a Docker overlay filesystem where RAC somehow manages to construct a cohesive view of the entire set of decisions over time, but how does that happen deterministically?
Let's say ADR 1 specifies users are unique by e-mail and should be soft-deleted, and ADR 2 says users are unique by username. Will RAC pick up on the fact that users still need to be soft-deleted? Is there a lot of manual "reference ADR 1 from ADR 2" to help with determinism?
So rac doesn’t merge ADRs or infer that soft-deletes survive… supercession is managed by the status on one ADR saying Superseeded, and the other saying Supersedes. This is enforced by the CI pipelines you can use (GitHub, etc)
I think your example is a bit more of a modelling question, and if soft-delete must outlive the uniqueness decision it should be its own requirement that’s persisted as RAC guarantees the graph stays consistent and current; it doesn’t guess which clause survives — that’s the users call.
Gooot it, I was thinking there would be some merging happening, but that would be the task for an LLM I suppose :D Mental model fixed!
No worries, clearly better documentation would help!
[flagged]
[dead]
[flagged]
[flagged]