Specroot Waitlist open

For teams building with AI coding agents

Specs that don’t drift — and a reviewer who isn’t a developer.

One versioned specification instead of a folder of markdown. Every document is a read of it, so nothing goes stale. Work items are pinned to the spec version they were built from, and the people who have to agree can read it without git.

Five specs touch it. Four are superseded. None of them says which.

— dev.to, September 2026

Always-current documents

No spec file to go stale.

Every document is a read of one set of records, drawn when you open it. There is no copy in a folder to fall behind the code or the last decision. A section nobody has captured yet says so; a read that fails says so too.

Functional specification · live 73 records
§ 1Repositories and analysis
7 records
§ 2The session and the interview
14 records
§ 3Review, approval and merge
18 records
§ 4Transcript import
not captured yet
§ 5Cost and metering
out of date · last good read 14:02

Our own specification, in the product

Small, linked requirements

A record says one thing.

Instead of long markdown files, each requirement is a record that says one thing, linked to what it answers to and what checks it. You read a slice — one record and everything under it — not the pile.

FR-040 · Approve a baseline accepted

Answers to

BR-004Private, reviewable specification
business
UC-005Approve a baseline
use case

Checked by

AC-118The approval records who and when
accepted
AC-119An approved baseline cannot be re-frozen
accepted
Document scoped to this record and everything below it
9 records

Our own specification, in the product

Change impact

A change marks what it breaks.

A confirmed decision marks every record it affects, upstream and downstream, before it lands. A work item is pinned to the exact versions it was built from; when they move, the item says so.

Decision applied · what it touches 11 records marked
FR-022Closing a session freezes its baseline
revisit
FR-032The author opens a review on the latest baseline
revisit
FR-033Nothing freezes while anything is unsettled
unaffected
AC-207A frozen baseline names one version of every record
revisit

Work item built from these

TASK-027Close and freeze
basis moved
pinned to FR-022 v2 · FR-032 v1 · FR-033 v1

Our own specification, in the product

Review without git

The people who have to agree can read it.

The client, the product owner or the compliance reviewer gets one address and the document at their level, with what changed marked. They comment, sign off or decline, and nothing merges until they do.

Review · Payments, business level frozen 18 Aug
§ 2  A refund is issued against the original payment only.
+ § 2.1 A partial refund is allowed once, and never after 90 days.
§ 3  A failed payment is retried twice, then abandoned.
Maria (client): Ninety days is wrong for corporate accounts — those settle on 120.
Author emailed · correcting session started from this comment
automatic
Approve Decline Merge — blocked until approved
Baseline 12 AugApproved by Maria · 12 Aug
stale · basis moved

Our own specification, in the product

Questions

“Does it work on an existing codebase?”

Yes. Connect a repository and it is read at the depth you choose — referenced by commit, never stored. What it finds still needs a person to confirm it before it enters the specification.

“How is this different from Spec Kit or OpenSpec?”

They write specs for your coding agent, as files in your repository, reviewed by developers. Specroot holds one versioned specification for everyone who has to agree with it, with sign-off and the impact of each change marked.

“Is our code stored?”

No. Your code is read, referenced by commit, and discarded. Your specification is stored, private, visible only inside your own tenant, and never on a public page.

Read more

What Specroot is