Entalpa vs OpenSpec
OpenSpec keeps your spec as folders in the repo. Entalpa imports them into one source of truth you can view, audit, trace and lock. Paste the repository, or upload it as a zip or a folder, and see your own spec that way, before you sign up.
Read your own specs here first
Paste a public repository with an openspec/ folder, or upload a zip or a folder of a private one. We read specs/, build the project, and derive the layers the format has nowhere to keep — stakeholders, stories, and the questions your specs leave open. No account, nothing to install, and your repository is never written to.
What OpenSpec is
A change-centric, file-based framework built on a two-folder model: openspec/specs/ holds the source of truth, openspec/changes/ holds proposals. Rather than documenting the whole system up front, you write delta specs describing only what a change alters, and a three-phase propose → apply → archive cycle keeps them moving. An AGENTS.md file lets agents with no native OpenSpec support follow the workflow anyway.
What OpenSpec does well
- The delta-spec idea is genuinely good: writing only what changes is far more likely to survive contact with a real project than a full up-front specification.
- Minimal ceremony and fast iteration — it is the least heavy option in this category by some distance.
- Free, open source, entirely in your repo, and readable by agents that have never heard of it.
- The propose → apply → archive state machine gives you discipline without a gate that blocks work.
Where the two differ
Archived history versus a current store
OpenSpec accumulates a source of truth by archiving applied changes. Entalpa keeps the current state as the primary object and serves it: one is a history you reconstruct the present from, the other is a present you query.
A heading is not an identity
In OpenSpec a requirement is its heading, so renaming it breaks every reference from outside the repository. In Entalpa it has an id, links to the story it serves, and a status, which is what lets you trace it and report on it.
Nothing stops a rewrite
The specs folder is a folder. An agent asked to update the spec will update the spec. A locked Entalpa requirement is excluded from the set the model is given.
What Entalpa gives you: one source of truth
Viewable
Every requirement of every domain on one screen, with the stakeholders and stories behind them and a graph of how they connect. Share a read-only link to one version with people who have no GitHub account, or export it as a PRD in Markdown or PDF.
Auditable
Each requirement has a status from draft to verified. Name a version, compare any two field by field, undo the last fifty changes. The backlog audit checks the whole set for duplicates, conflicts and scope creep across domains.
Traceable
Each requirement has an identity of its own, not its heading, so a ticket, a test or another requirement can point at it and keep pointing after a rename. Stakeholder → story → requirement → subsystem → interface, stored as links you can query.
Manageable
Lock a requirement and the model is never handed it to rewrite. Open questions mark where the spec is silent. Your agent reads and writes over MCP, which never spends credits. And it goes back out whenever you want: as an openspec/specs/ tree that passes openspec validate, or as ReqIF, Markdown, CSV and JSON.
Moving your specs over
- 1.Paste your public GitHub repository on the OpenSpec import page, or upload a private one there as a zip or a folder. Entalpa reads
openspec/specs/, notchanges/: one subsystem per domain, one requirement per heading, scenarios kept as acceptance criteria. No account needed, and you see all of it, not a teaser. - 2.Review what it added: stakeholders and stories inferred from your own requirements and labelled as inferred, and the open questions where your spec is silent.
- 3.Claim the project, lock what is settled and connect your agent over MCP. Keep proposing changes the way you do now; the agent reads the current requirements while it writes them. When you want the files back, export an
openspec/specs/tree, or have your agent write it into the repository over MCP. Would you rather we opened the pull request for you? Write to us and we set it up.
Which one fits
Pick OpenSpec if
You want spec discipline with the least possible ceremony, your team reviews only in pull requests, and nobody outside engineering needs to read the spec.
Pick Entalpa if
Non-engineers need to see, review or sign off the requirements, you need to say what a change affects, or the spec has to be queryable by an agent rather than reconstructed from an archive. Import it and see.
Questions this raises
Can I move OpenSpec specs into Entalpa?
Yes. Paste a public GitHub repository with an openspec/ folder on the import page, or upload a private one as a zip or a folder, and Entalpa builds the project from openspec/specs/, up to 300 requirements per import, and tells you if it had to leave any out. You can read the whole result before creating an account.
Can I put the spec back into my repository?
Yes. Export it as an openspec/specs/ tree: one spec per subsystem and one for the system-level requirements, with acceptance criteria as scenarios, and it passes openspec validate. A requirement with no acceptance criteria gets a scenario restating it, and the export tells you which ones to replace. Download it, or let your agent write it over MCP. If you would rather we opened the pull request, write to contact@entalpa.com.
Does it read openspec/changes/?
No. Changes are work in flight, not agreed behaviour, so the import reads only openspec/specs/.
Is OpenSpec a lighter Spec Kit?
Roughly, yes — both are file-based and CLI-shaped, and OpenSpec is the closest one-to-one alternative to Spec Kit. OpenSpec's distinctive idea is the delta spec: describing only what a change alters instead of the whole system.
See your openspec/ folder as one source of truth
Paste a public repository, or upload a private one as a zip or a folder, and read your own spec as stakeholders, stories, requirements and open questions, before you create an account. Keep proposing changes the way you do now.
Compared with something else