We have a similar setup, but for our whole business at display.dev
We have dedicated document lifecycle skills, folder setup and frontmatter fields in markdown to maintain the order.
We have a temp/ folder, which is for temporary files and does not get committed at all.
We also have folders like foundations/ and scratch/ which the name says, former you can trust and latter not really. Inside top level folders we also have separate _wip/ folders for WIP stuff, which have not yet been promoted.
Markdown files have frontmatter whether it’s a draft, plan or it’s already implemented. Also last updated date is included for the agent to evaluate freshness.
In addition we also have scripts which validate the frontmatter fields and surface broken links before pushing the changes.
On top of all of that we use display.dev to share the artifacts with others in the team and get feedback.
Have you looked at LLM Wiki concept from Karpathy? It might have some additional ideas on how to better manage the knowledge base.
At Display.dev we’re also working on a solution to replace the need for Github repo. So you could manage the artifacts without knowing that it’s git underneath. So stay tuned.
Had the same question when I read the release post. Naturally I took the ACP docs, Gemini CLI example and hacked together my own wrapper for Claude Code SDK to bridge it with Zed. It actually works and uses your Claude subscription.
https://www.npmjs.com/package/claude-code-acp
We have dedicated document lifecycle skills, folder setup and frontmatter fields in markdown to maintain the order.
We have a temp/ folder, which is for temporary files and does not get committed at all. We also have folders like foundations/ and scratch/ which the name says, former you can trust and latter not really. Inside top level folders we also have separate _wip/ folders for WIP stuff, which have not yet been promoted.
Markdown files have frontmatter whether it’s a draft, plan or it’s already implemented. Also last updated date is included for the agent to evaluate freshness.
In addition we also have scripts which validate the frontmatter fields and surface broken links before pushing the changes.
On top of all of that we use display.dev to share the artifacts with others in the team and get feedback.
Have you looked at LLM Wiki concept from Karpathy? It might have some additional ideas on how to better manage the knowledge base.
At Display.dev we’re also working on a solution to replace the need for Github repo. So you could manage the artifacts without knowing that it’s git underneath. So stay tuned.