One spec per feature, in the repository beside the code, so your engineers’ agents build from the file you wrote. Every change after sign-off has a history and a diff, with who made it and when.
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. 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 signed. Six months on, half of it is out of date, and a new hire can’t tell which half.
Your engineers’ agents build from what’s in the repository. The PRD lives somewhere else, so it reaches them in pasted pieces, if at all.
How it fits
Install the software framework and every feature gets one markdown file: why it exists, what it promises, and what it won’t do. The work lives in tasks that point at the spec, so the spec never fills up with sprint state.
What you will use most
A thread starts on the criterion it questions and follows it through edits until it’s answered. It’s in the file, so a reviewer sees it in the merge request.
Each task names the spec it serves. Close the ticket and the spec stays true, because it never held the ticket’s state. If your team plans in Jira, the Jira plugin brings the board in.
Sketch the flow with your designer, then promote a sketch into a real spec.
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, with no terminal.
Nothing changes quietly
Open a spec’s File history to see who changed it, when, and the diff of any commit. “I don’t remember approving that” now has an answer: the name and date. Comment threads are part of the file, so they show in the same diff.
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, point every agent that reads AGENTS.md at it, and add eidos check to CI with one command (eidos ci). A pull request that breaks a spec fails. Product managers use the desktop app, so nobody has to learn git.
$ curl -fsSL https://eidosmd.com/install | sh
$ 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 or install it from a terminal. Then turn on the Backlog under Built-in 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 Project, then pick it from the list.
Download Eidos MD, install the software framework in your repository, and write the spec for your team’s next feature.
Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.