Eidos or Spec Kit: the next change, or the whole product?
GitHub Spec Kit turns intent into a spec, a plan, and tasks your coding agent carries out, one feature at a time. Eidos keeps one blueprint per part of the product, written by a person and checked against a framework you choose. It stays true after each feature ships. One drives the work. The other defines what the work is for.
The short answer
Pick Spec Kit if you want your coding agent to go from a feature request to code along one set path, in whichever agent your team runs. Pick Eidos if you want a definition of the product that outlives each change: written by a person, checked the same way every time, and readable by people who never open a terminal. Many teams will want both.
At a glance
Eidos and GitHub Spec Kit, side by side
| Question | Eidos | GitHub Spec Kit |
|---|---|---|
| What a spec describes | One part of the product, as it stands | One change: a feature folder per piece of work |
| Who writes it | A person; your agent asks and pushes on scope | The agent drafts; a person reviews |
| Checking a spec’s shape | A deterministic check, on your machine and in CI | Agent commands: clarify, checklists, analyze |
| From spec to code | Not built in: your agent reads the blueprint | Plan, tasks, implement, and converge |
| Coding agents | Claude Code, Codex, or any ACP agent in the app | Dozens, wired by one specify init |
| Beyond the feature | Frames for the audience, market, architecture, and criteria | A project constitution |
| People who never open a terminal | A desktop app, with comments, a canvas, and a backlog | Not served: a CLI and your agent |
| Price and license | Free app; open Apache-2.0 standard | Free, MIT licensed |
Where Spec Kit is the better choice
- It’s GitHub’s, free, and MIT licensed. It’s the first answer most developers find for spec-driven development, with a large community and many extensions.
- One
specify initwires the same commands into dozens of coding agents, so a team can share a process without sharing an assistant. - A whole path from intent to code: constitution, spec, plan, tasks, implement, converge. Eidos stops at the definition and leaves the plan and the code to you and your agent.
- Converge compares the code with the spec and turns the gap into tasks. Eidos doesn’t yet check that an agent followed a blueprint.
- Gaps are made visible:
[NEEDS CLARIFICATION]markers, mandatory sections, and numbered requirements and success criteria.
Where Eidos wins
- The product as it stands, not the next change: one blueprint per part of the product, with a permanent id, kept true after the feature ships.
- A person decides every sentence. Your agent reads, asks where you were vague, and pushes on scope. It doesn’t write the spec for you to review.
- A deterministic check of every spec against your framework, as a job on every pull request. The check stays lenient until you turn strictness on.
- As long as you make it. A new blueprint starts from its template’s headings, not from pages of generated markdown to review.
- Room for more than features: the audience, the market, and the architecture, and frameworks for books and research as well as software.
- A free desktop app for the people beside the developers, with comments, a canvas, and a backlog that point at the blueprints.
Use both
Keep Spec Kit for the change, Eidos for the product
Spec Kit and Eidos each keep their files in folders of their own, so both fit in one repository. Install the software framework beside Spec Kit and write a blueprint for each part of the product. When a feature’s spec settles, carry what it decided into the blueprint it changed. Then turn on strictness, so the job on every pull request fails when a blueprint falls out of shape.
- Both in one repository, in folders of their own
- Any agent reads the blueprints as plain files
- A check that runs the same way on every pull request
$ eidos install @BuildableWorks/software Blueprints --group payments --yes
✓ installed @BuildableWorks/software → Blueprints
collections: frames, specs; groups under specs: payments
$ eidos setup --strict on
$ eidos ci --write github
✓ created .github/workflows/eidos-check.yml: eidos check on every pull requestWhat this page says of GitHub Spec Kit was checked against its own pages and docs in October 2026. Products change; if something here is out of date, tell us with Send Feedback, under Help in the app.
Compare
Other comparisons
- Workspace and wikivs NotionPick Notion when everyone needs to write in one shared workspace. Pick Eidos when the spec should be checked and live beside the code.
- Team wikivs ConfluencePick Confluence when the whole company reads the spec beside Jira. Pick Eidos when the spec should be checked and reviewed with the code.
Give your agent a product to build toward.
Download Eidos MD, open your repository beside Spec Kit, and write the first blueprint yourself.
Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.