Show HN: Gnosis, a knowledge base for what the code can't tell you(github.com)
github.com
Show HN: Gnosis, a knowledge base for what the code can't tell you
https://github.com/skorokithakis/gnosis
5 comments
Rejections are usually conditional on the world at the time: a constraint, a dependency, a workaround that exists today. When those conditions change the rejection is stale but the log still reads "we tried this and it failed." How do you think about surfacing stale entries for revisit? Is it on the agent to spot them on its own or is there a manual deprecation step?
There isn't a manual deprecation step, because the agent has no context outside what the human gives it. Deprecation happens when conflicting information is given ("you want to do this but this note says you tried it before and it failed, what do you want to do?").
At that point, either the human decides to go for it and the new decision is noted, and the old decision is superseded/removed, or the human says "wow I'm sure glad I'm using gnosis" and everything is left as-is.
At that point, either the human decides to go for it and the new decision is noted, and the old decision is superseded/removed, or the human says "wow I'm sure glad I'm using gnosis" and everything is left as-is.
Im currently using mintlify, with a section for design decisions, and why i picked evey one. usually i start by discussing the design, comparing options, picking a suitable one with a certain criteria, document it all in an md, and add it to that section. what is the workflow in your case?
Basically, it's an instruction for the agent to search for existing knowledge before implementing, record decisions as they happen, and review what should be captured after finishing.
Time and time again, I've seen teams try to change something to a better way, only to realize why it was done the "worse" way in the first place. Documenting decisions not taken is just really hard, ADRs help but doing it for everything is just too noisy and time-consuming. What's more, most of the decisions just detail what was decided, which is the easy part.
I've been wanting to change this for a long time, and with LLMs, we now can. LLMs are diligent about documenting, and all you need is an instruction in AGENTS.md. That's why I built gnosis.
Simply tell your agent to run it after planning and when done, and gnosis provides the agent with all direction necessary.
Gnosis tells the agent to document only information it got from the human, not anything it can find by itself, and especially to document why alternatives were rejected. It uses a JSONL append-only log and a SQLite index (for retrieval), making it simple, fast, and convenient.
I'd appreciate it if you tried it out and gave me feedback!