CarlRannaberg

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

Author here. I wrote this piece because I couldn't find a comprehensive technical overview that connected the foundations of AI agents (memory systems, planning capabilities, tool integration) with their current real-world applications and limitations. Most existing articles either focused purely on theoretical aspects or just listed use cases without diving into the technical architecture behind them. I synthesized findings from dozens of research papers and articles to create this overview.

Fair feedback. It was written by a human together with AI.

Agree. v0 and Bolt are currently only good for prototyping. It lacks the granular control of a proper coding editor like Cursor. But they work well together as the feedback loop and barrier to start iterating on a rough idea is extremely low in v0 and Bolt compared to VSCode + GH Copilot or Cursor.

Hey HN, I've been playing around with Cursor AI, v0, and the new kid on the block, Bolt.new, while building Vyce.app. There's a lot of buzz about Bolt.new being a 'Cursor & v0 killer', but from my hands-on experience, that's not really the case. Don't get me wrong, Bolt.new is cool, but it's not the be-all and end-all some are making it out to be. I break down what each tool is good at (and not so good at) based on actually using them in my work. Turns out, each one has its own strengths in the software development workflow.

Look into the statistics behind code written, time spent on computer and meetings, sleep, steps taken and lessons learned along the way.