Back to News
Advertisement
ddivitsheth about 4 hours ago 12 commentsRead Article on github.com

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

Hey HN! This is Divit from Almanac (YC S26). We built CodeAlmanac, a wiki for your coding agents that updates as you talk to them. It is open-source, local, and free.

Here’s a demo: https://www.youtube.com/watch?v=XNQWV3TFBWM

Your CC/Codex conversations contain a LOT of knowledge that is forgotten because it was never documented. People have their own methods of documenting their chats. We used to make Markdown files like MANUAL.md and DESIGN.md, and would prompt Claude to keep them updated. The problem is that these files quickly become outdated and messy, and there’s only so much you can put in a single file.

So we set out to build CodeAlmanac. We wanted something that was 1) maintained automatically, 2) lived inside our repository, and 3) used our existing Codex/Claude Code subscriptions.

CodeAlmanac maintains an almanac/ folder inside your repository. It contains connected Markdown pages that cover things not documented in the codebase, including decisions you have made and why the codebase is shaped this way.

The pages are indexed in SQLite and are queryable through a CLI. We add instructions to AGENTS.md or CLAUDE.md so future sessions automatically search the wiki before they start coding.

Every five hours, CodeAlmanac uses the Codex/CC SDK to spin up an agent that reads your new conversations and updates the relevant pages. We went with a time-based trigger instead of commits because we saw people commit very frequently, which would lead to high token costs.

We originally made CodeAlmanac for individual developers, but the team use case has become much more obvious to us while using it ourselves. We are a team of three, and each of us works with our own coding agents. Before this, I would make some change after a lot of thinking and then later have to call my cofounders and explain why it looked this way. There is almost a sense of relief now knowing that the decisions I made are written down somewhere their agents will actually read.

It’s live today for everyone to try. Please let me know your feedback and I’ll be here to answer any questions. Would also love to hear how you all maintain context across conversations today!

Advertisement

⚡ Community Insights

Discussion Sentiment

85% Positive

Analyzed from 505 words in the discussion.

Trending Topics

#guidance#more#wiki#found#working#models#support#token#without#human

Discussion (12 Comments)Read Original on HackerNews

ajrouvoetabout 2 hours ago
Although I’d like this to work, I have not seen evidence that AIs extract good reusable knowledge from sessions without strong guidance.

I do R&D work in comp sci and usually write software and reports or papers in parallel. I have been using Opus in a controlled human-in-the-loop fashion to (significantly) speed up the work. While I’m at times surprised how high-level input steers output the right way, no high level ideas emerge from the AIs output. Many attempts to abstract from the concrete are wrong.

As a consequence, most writing is poor on content and form. It writes about the wrong things and crosses abstraction levels all the time. It cannot keep implementation details and conceptual leaps apart.

I don’t know what this means for the aim of this project to maintain important info for agents. Perhaps there are enough low-hanging fruits. That said, I’m skeptical that the resulting wiki is good documentation for human contributors.

reveriedevabout 2 hours ago
We've found Opus/Gpt are really bad at technical writing. We've found ways around this by having guidelines like https://www.openalmanac.org/ai-patterns-to-avoid.md, which have worked quite well for us.

Understanding what is relevant to be documented vs not is definitely tricky and something we've spent a lot of time on. We found being more prescriptive about what should be documented is helpful, we incorporated guidance from diataxis for it (https://diataxis.fr/)

Also the wiki is primarily for your agents and not for people. Although we're working to improve the prose quality and structure so it is well written for humans too.

ajrouvoetabout 2 hours ago
Do you mean that specifically those models perform badly without guidance or do all models need specific instructions for technical writing?

We have observed that it is a loss for teamwork that the sparring with AI is entirely lost when only the technical conclusion is recorded. I write to recover that for my team and an AI can use it to its advantage as a side effect.

It would be cool to have good tool support for this process, but I’d bet on support, not delegation in that case.

reveriedevabout 1 hour ago
The models perform badly without guidance but we've found the guidance doesn't need a human in the loop (at least for this task). You can distill what makes a good wiki, what information should go in etc. and the models are good enough to do it reliably. That's what took the most time (researching and studying existing wikis)

When you say support do you mean something where you can collaborate with the model to maintain the wiki?

gupsak31about 1 hour ago
This looks promising. Is there a version I can use to self improve my production workflows and not just the dev work?
divitsheth31 minutes ago
Glad you liked it! Would love to chat more about what kind of production workflows you are looking to improve. You could grab whichever time is convenient for you: https://cal.com/team/almanac/demo
pwillia7about 3 hours ago
Any data on better outputs and/or token saving?
divitshethabout 2 hours ago
We’re working on evals now. We ran a small preliminary LoCoMo test with a 2k-token retrieval budget:

Almanac: 55.7% BM25: 51.8% Supermemory: 47.6% Mem0: 60.6%

LoCoMo is not quite our use case. It tests conversational memory, while Almanac is more for coding agents trying to find their way around a codebase.

These results show output quality at the same token budget, not token savings yet. We’re working on coding agent evals that should be more representative.

pwillia733 minutes ago
Cool thanks I will keep an eye on it!
colinbabout 3 hours ago
Not in any way being negative about what you’ve done, but… Mac only. Is this just because of inbuilt knowledge about file system shape or some more important Apple exclusive tool/environmental quirk?
reveriedevabout 3 hours ago
We’re working on Linux/Windows support right now. Mac was the easiest to setup for us since that’s the machine we code on. What OS do you use?