Entalpa vs GitHub Spec Kit
Spec Kit gives you a folder of feature specs. Entalpa turns it into one source of truth for the whole system: viewable, auditable, traceable and locked where it matters. Import it, and keep the workflow you like.
Read your own specs here first
Paste a public repository that uses Spec Kit, or upload a zip or a folder of a private one. We read every specs/<feature>/spec.md and its tasks.md, then fold the features into one backlog, oldest first, so a later feature revises the story it changed. No account, nothing to install, and your repository is never written to.
What GitHub Spec Kit is
GitHub's open-source toolkit for spec-driven development. A constitution once per project, then specify → plan → tasks → implement → converge per feature, run as skills inside your coding agent; each feature gets its own specs/NNN-feature/ folder with spec.md, plan.md and tasks.md. Optional extensions add a bug-fixing process and an idea assessment. It supports thirty-plus coding agents, is free, and keeps everything in your repository.
What GitHub Spec Kit does well
- Free and open source, from GitHub, with no account and nothing between you and your files.
- The per-feature loop is the right shape for building one feature: prioritised user stories, Given/When/Then scenarios, numbered requirements, then a plan and tasks the agent works through.
convergeeven checks the implementation against them. - Clarify is good elicitation: up to five targeted questions, each answer written back into the spec. Public repositories hold over two thousand answered clarifications.
- Plain markdown in the repo, reviewed in pull requests, and readable by any agent with or without Spec Kit installed.
Where the two differ
A folder of feature specs is not one spec
Spec Kit has no current state of the system, only the stack of feature specs that built it. We read 1,007 feature specs from 77 public Spec Kit repositories: in a hand-checked sample, about one later feature in three changed or fixed something an earlier one specified, and nothing marks the earlier spec as out of date. In Entalpa a change edits the story it changes, so there is one answer to "what does the system do".
The status line goes stale
71% of the public specs we read still say Status: Draft, and more than half of those have every task ticked. Entalpa keeps a status per requirement and rolls it up to the story, so progress is a view, not an archaeology project.
The next spec cannot see the earlier ones
/speckit-specify writes a new feature from your prompt and the constitution. Spec Kit's MCP server is experimental and serves no artifacts. Entalpa serves the current requirements over MCP, so the agent writing the next spec can check it against everything the system already does.
What Entalpa gives you: one source of truth
Viewable
Every stakeholder, story and requirement of the whole system on one screen, with a graph of how they connect, instead of specs/001 to specs/047 read in order. Share a read-only link to one version with people who never open the repository, or export the lot as a PRD in Markdown or PDF.
Auditable
Each requirement has a status from draft to verified, and on import it comes from your tasks.md ticks. 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, which no single feature spec can see.
Traceable
Stakeholder → story → requirement → subsystem → interface, stored as links, not prose. "What does this rule affect" has an answer: a click in the graph, or one MCP call from your agent.
Manageable
Lock a requirement and the model is never handed it to rewrite. Open questions mark where the spec is still silent. Your agent reads and writes the spec over MCP, which never spends credits. And it goes back out whenever you want: as a Spec Kit specs/ feature, or as ReqIF, Markdown, CSV and JSON.
Moving your specs over
- 1.Point Entalpa at your repository. It reads
specs/oldest feature first: stories become one backlog, with a later feature revising the story it changes instead of adding a second copy; everyFR-andSC-requirement comes in word for word, linked to its story. - 2.Review what it found. Statuses come from your
tasks.md, answered clarifications come in as answered questions, open[NEEDS CLARIFICATION]markers as open ones, and where a later requirement may replace an earlier one you get a suggestion to confirm, not a silent edit. Refactor-only features add nothing, because they describe the code, not the product. - 3.Lock what is settled and connect your agent over MCP. Keep running
/speckit-specifyfor the next feature: it now writes against the current spec instead of a folder of old ones, and once it lands, one click imports it into the same project and folds it in. When you want the files back, export the current spec as aspecs/feature, 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 GitHub Spec Kit if
You are building one feature, or the repository has a handful and one person knows how they fit together. Spec Kit is free and its per-feature loop is good.
Pick Entalpa if
Your specs/ folder has grown past what anyone reads end to end, later features have quietly changed earlier ones, or someone outside engineering needs to see, review or sign off what the system does. Import the specs you have and keep one source of truth from here on.
Questions this raises
Do I have to stop using Spec Kit?
No. Keep it for the next feature. What moves is the source of truth: the merged, current requirements live in Entalpa, and your agent reads them over MCP while it writes the next spec.
What does the import read?
Each specs/NNN-feature/spec.md for user stories, acceptance scenarios, FR- requirements, SC- success criteria and clarifications, and tasks.md for status. plan.md, research.md, data models and contracts describe how one feature was built and are not imported.
Can I put the spec back into my repository?
Yes. Export it as one Spec Kit feature, specs/<NNN>-current-system/spec.md, numbered after your newest one and in the template's shape: stories with priorities and acceptance scenarios, FR- requirements, SC- success criteria and your clarifications. Download it from the project, or let your agent write it over MCP. If you would rather we opened the pull request, write to contact@entalpa.com.
What happens to a feature that was only a refactor?
A feature with nothing a stakeholder would see (a rename, a lint cleanup, a test suite, a dependency swap that keeps behaviour) adds nothing to the backlog. Its requirements describe the code, not the product.
Is Entalpa just a paid Spec Kit?
No. Spec Kit is a free workflow that writes one spec per feature. Entalpa is the merged, current spec of the whole system, with statuses, versions, traceability and locking, served to any agent. You can use both, and most teams with more than a few features should.
See your specs/ folder as one spec
Paste your repository, or upload it as a zip or a folder, and Entalpa folds every feature spec into one backlog, with statuses from your tasks.md and the open questions your specs left. Keep running Spec Kit for the next feature.
Compared with something else