One spec per feature, in the repository beside the code, so your engineers’ agents build from the same file you wrote. Every call made after the sign-off lands on the spec, with who confirmed it and when. For the product manager and the lead engineer on a team that ships with coding agents.
Free for macOS, Windows, and Linux. No account, no subscription.
Sound familiar?
The PRD was approved. Then the requirements kept moving, in meetings, threads, demos, and tickets.
The decision was made on a call and lives in two people’s memory of a thread. When it comes up again, the meeting is about what was decided, not what to build.
Scope changes in the tracker while the document stays as it was signed. Six months on, half of it is out of date, and the new hire cannot tell which half.
Your engineers’ agents build from what is in the repository. The PRD lives somewhere else, so it reaches them pasted in pieces, if it reaches them at all.
How it fits
Install the software framework and every feature gets one markdown file in the repository: why it exists, what it promises, and what it will not do. The work lives in tasks that point at the spec, so the spec describes the product and never fills up with sprint state.
What you will use most
Log what a meeting settled as a Meeting decision on the spec. It waits in the inbox until the person who decides confirms it, and keeps their name and the date.
A thread starts on the acceptance criterion it questions, follows it through edits, and is closed once it is answered. It is in the file, so a reviewer sees it in the merge request.
Tasks on a board, each naming the spec it serves. Close the ticket and the spec stays true, because it never held the ticket’s state.
Sketch the flow with your designer, then promote a sketch into a real spec. It keeps its place on the canvas and opens its file.
Claude Code or Codex beside the page with the spec attached. /grill has it ask where the spec is vague before anyone builds from it.
A history and a diff for each spec, and a named version for what was approved, without opening a terminal.
Who agreed, and when
Every decision made for a spec is listed in its Constraints & Decisions section, ticked once a person confirms it. A call an agent made on its own arrives as Proposed and stays unconfirmed until someone stands behind it. “I don’t remember approving that” has an answer: the name and the date are in the file.
Nothing changes quietly
Open a spec’s File history to see who changed it and when, and the diff of any commit against the spec as it stands. The decisions and the comment threads are part of the file, so they show in the same diff and in the merge request.
From discovery to a spec
Lay out a flow on a canvas whose cards are your specs, drawn live from their files. When an idea is ready, promote the sketch: it becomes a spec in the collection you pick, and the arrows stay where you drew them.
For the lead engineer
Install the framework in the repository, point every agent that reads AGENTS.md at it, and run eidos check in your CI so a pull request that breaks a spec fails (a one-command CI job, eidos ci, comes in the next release). Product managers use the desktop app; nobody has to learn git to write a spec.
$ npm install -g eidosmd
$ eidos install @BuildableWorks/software
$ eidos agents --write
✓ created AGENTS.md with the Eidos nudge
$ eidos checkStart here
Frames for the product and specs for the features, with Out of Scope in every template. Pick it in the app when you make a new root in the repository, or install it from a terminal. Then turn on the Backlog and Decisions under Core plugins.
An app, a service, or a system
Frames for architecture, audience, criteria, and market, and specs grouped by domain.
$ eidos install @BuildableWorks/softwareIn the app: New Root, then pick it from the list.
Download Eidos MD, install the software framework in your repository, and write the spec for the feature your team starts next.
Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.