Entalpa

For Spec Kit projects

One spec for the whole system

Spec Kit writes one spec per feature and never merges them. Paste your repository and see every feature folded into one current backlog, with statuses from your tasks.md — read-only, no account, and nothing written back to your repo.

Public repositories only, read through the GitHub API. We never write to yours.

What happens when you paste a repository

1

We read specs/, oldest feature first

Every user story and every FR- and SC- requirement, word for word with the file it came from. Your clarifications come in as answered questions, open [NEEDS CLARIFICATION] markers as open ones, and each requirement's status comes from the ticks in your tasks.md.

2

Then we fold the features into one backlog

A later feature revises the story it changes instead of adding a second copy, requirements are linked to the stories they serve, and refactor-only or test-only features are left out. Where a later requirement may replace an earlier one, you get a question to confirm, never a silent edit.

3

You read the whole thing, before signing up

Not three teaser rows. Your repository is public, so the folded view withholds nothing you had not already published.

Why one spec, not a folder of them

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 marked the earlier spec as out of date. 71% of the specs still say Status: Draft, more than half of those with every task ticked. A folder of feature specs records how the system was built; it does not say what it does now.

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.

Keep Spec Kit for the next feature

Spec Kit’s per-feature loop stays as it is. What moves is the source of truth: the current spec of the whole system lives in Entalpa, and your agent reads it over MCP while /speckit-specify writes the next feature. And it goes back whenever you want: export the current spec as a specs/ feature, or let your agent write it into the repository.