Why I bet on Eidos
Every product I have worked on eventually lost track of what it was supposed to be. Eidos is my answer to that, and the biggest thing I have put money into so far.
I manage engineers at Buildable during the day. That means I have sat in a lot of meetings where somebody asks “wait, what is this feature actually supposed to do?” and the honest answer is that nobody knows anymore. The ticket closed. The wiki page is from two versions ago. The person who knew left in March.
That is not a people problem. Everyone on those projects was doing their job. It is a where does the truth live problem, and I have never seen a tool fix it. Jira describes work. Confluence describes whatever someone felt like writing that day. Neither one describes the thing.
So, Eidos.
The idea is small on purpose
One markdown file is the complete source of truth for one unit of the product. Not the work to build it. The thing itself: what it is for, how it behaves, what is deliberately out of scope. That file is true before the thing exists, while it is being built, and after it ships. A task dies when the work is done. A blueprint does not.
The files live in the repo, next to the code they describe. They get reviewed in pull requests like everything else. There is no SaaS, no login, and nothing to export when you leave.
That is basically the whole pitch. The rest is machinery.
Why plain markdown
Because I want this to still work in ten years. Markdown in git is the most boring, most portable thing I could pick, and boring is exactly what you want for the document that is supposed to outlive the tooling around it. It also happens to be what coding agents read best, which was not the original reason but has turned into a pretty big one.
Why a standard and not just a template
Templates drift. Everybody copies one, tweaks it, and six months later no two specs have the same shape. Eidos separates the framework (the collections, templates, and properties that say how you write) from the blueprints (the things you wrote). The framework is the portable piece. One team can hand it to another, and a validator can tell you when a file stopped matching it.
The standard itself came out of Buildable, and it is theirs, Apache-2.0. What I built on top of it is eidosmd: the CLI that scaffolds and validates a root, the local browser for mapping a product out visually, the registry of frameworks, and the docs. That part is The Virtual Panda’s.
Why “human-first” is in the docs
I use agents constantly. I also think handing an agent a blank page and saying “write the spec” is how you get a very confident document that nobody actually agreed to. So the CLI owns the structure, the agent facilitates, and the words in a blueprint get written with the owner. The intent stays with a person.
Why it is my biggest bet
Because I use it every day and I do not want to work without it anymore. Care Connect is defined in it, top to bottom, and the number of “wait, what was this supposed to do?” conversations I have had on that project since is roughly zero.
If that is a problem you recognize, it is npm install -g eidosmd and about ten minutes. Free for personal use, and if you want it at work, talk to me.