I also work on many projects at a time. To keep up, my notes grew into a whole network of documentation. It works as a network because a coding agent can follow the links. All the notes entries are markdown and all is in git. Here's my long-run notes network:

0) Work journals. One repo for all projects at once. Each project or feature has its folder with dated entries, one entry per significant move, and a small index: a row per entry with date, link and a few lines of what happened. The project folder points to its journal and the journal points back, so when two projects touch, both sides reference each other.

1) Docs. Always maintained starting from day one of the project, not scattered in the code but usually in repo/<proj|subproj>/docs in the code repos.

2) Knowledge base with the index on top which consolidates the knowledge across projects. The index is sqlite + faiss, built from what is in git and rebuilt as it changes, and there is MCP over it. So I can ask "where did I talk about X" and get a quick recap with the links to primary notes (can be docs, journals, other knowledge base articles, sometimes source code files).

3) Issues tracker (e.g. github issues). Journal entries reference the issues (no retelling, but the linkage is preserved). Optional and for smaller projects can be solved with journals.

4) Procedures. Notes that teach how to maintain all of this while working. This is the "onboarding procedure" for a maintainer, and it is a "must read". All these piles of knowledge and sources stay sane and survive months only because the maintainers always keep the network updated as they work. My coding agents follow these same procedures and journal.

Getting back to a project after a long break or onboarding a new agent starts from reading its journal index. I describe the feature, the agent finds relevant journals and onboards itself. This just works

Writing is probably the most important and easiest skill right now.