# Your docs folder is already the knowledge base AI-assisted development produces documentation faster than anyone can file it. Plain Markdown in the repository, rendered by a static site generator, turns that pile into a knowledge base for both people and agents. I usually start working early, with everyone else still asleep and an espresso within reach. On one of those mornings I realized we had created a mess. A colleague had set up a separate repository for our first prototype. My own laptop held nearly thirty local folders and checkouts, with design documents scattered across all of them. Claude and the superpowers plugin had written most of those files while we worked, and I could not have said which copy of anything was current. The first thing we did was promote a single repository to hold all of our documentation, and a single folder in it, `docs/superpowers`, for everything the agent produces: specs, plans and handovers. Between late May and late September, that folder collected 962 Markdown files: 380 specs, 335 plans, 197 handovers, 18 ideas, and a long tail of artifacts, spikes and templates. Consolidating gave us one place, but we never planned what would fill it. The files arrived as a side effect of working with Claude Code, one design conversation at a time, and each of them was useful on the day it was written. Picking one place settled where the files go. What that place should be made of was the bigger question, because the next session, and the next person, still had to be able to find things in it. --- ## The usual answer is a wiki When documentation piles up, most teams reach for a wiki or a shared folder: Confluence, Notion, a OneDrive or Google Drive directory. It is a sensible default for documents people write by hand, and it works well enough until an agent is one of the readers. An agent working in your repository cannot see a wiki. You can bolt on a connector, or export pages and paste them into a session, but either way the documentation now lives in two places that drift apart. A spec in the wiki says one thing, the code says another, and nothing in either place tells you which one changed last. Search over a shared drive means a model has to be pointed at the right file every time. The files an agent produces already sit next to the code they describe. They are versioned, so you can see what a spec said before the plan changed it, and diffable, so a reviewer sees what a handover added. And because the agent wrote them, a model reads them back without any conversion. Moving them somewhere else adds a copy to keep in sync, for a corpus that git already keeps honest. The convention the tooling has settled on points the same way. `CLAUDE.md` and `AGENTS.md` are plain Markdown files at the root of a repository that an agent reads when a session starts. The context lives in the repository, next to the code. ## What was missing was a home for people The agent side of this took care of itself. What was missing was on the human side: 962 files in a folder are hard to browse, and a knowledge base that only one kind of reader can use is half of one. I have maintained Hinode, an open-source Hugo theme, for several years, so the answer was close at hand. A static site generator reads a directory of Markdown and renders it as a site. That is the whole job. With no database behind it, the output is fast, and since the result is only files it deploys to the edge. Serving those generated files does not require running the site generator or querying a database for each request. We already run our developer documentation this way, on Hugo with a custom theme that extends Hinode. The specs, plans and handovers stay plain Markdown, and most of them carry no front matter at all: when we counted, 369 of the 380 specs started with a heading and nothing else. The site publishes content derived from them, such as objectives, UX designs, architecture decision records and generated specifications. The `docs` folder is the single source. The site is a view of it. Because it is internal, it sits behind a login, which [we built with a small Go server](/blog/gating-a-static-site-with-go/). ## The structure carries the weight Volume is only useful when it is organized. The structure is plain: one folder for everything the agent produces, a subfolder per document type (specs, plans, handovers, ideas), and a date in every file name so the history sorts itself. None of this is clever. It is the kind of convention a small team can agree on in ten minutes, and an agent follows it as readily as a person does. ## The same idea, pointed outward If Markdown is a good format for what an agent reads inside the repository, it is a good format for what it reads on your public site too. The `llms.txt` convention proposes exactly that: an index of your pages plus a clean Markdown version of each one, free of navigation and scripts. Hinode's `mod-llm` module generates both for a Hugo site, and it can also publish a machine-readable schema of every shortcode so that a model suggests components that exist. I wrote up the setup as a tutorial, because it is the same bet as the `docs` folder from the other side. Once your content is plain Markdown, making it available to a model is mostly a matter of choosing where to expose it. --- The belief I would leave here is the one in the title: if your assistant writes its thinking down in Markdown next to your code, the knowledge base already exists. What remains is giving it one home and a front door for the people who were never going to browse a folder of 962 files. If you want to try the outward-facing half, the tutorial walks through it: [Generating LLM-ready content](https://gethinode.com/tutorials/generating-llm-content/).