Find the gaps before your team does.

What it does

Paste a brief, a spec, a set of requirements or a user story — as text or as a .md, .txt or .docx file — and get the document back completed: your own wording preserved, the missing sections written in where they belong, every edit highlighted with its reason and a button to restore your version.

The second tab is the analysis, in five blocks:

• Ambiguities — the quote, why it reads two ways, and a rewrite following EARS and IEEE 830
• Missing cases — errors, empty states, permissions, boundaries, concurrent access, rollback
• Untestable criteria — acceptance wording you could not write a test against
• Grooming questions — what a developer will ask, before they ask it
• A traffic-light verdict — ready to hand over, send back to the author, or needs a stakeholder decision

Why I built it

It is the same problem as the delivery system, one step earlier. A feature slips less often because someone estimated wrong than because the spec quietly left a decision unmade — and nobody noticed until the work was already underway.

The behaviour that made it worth building: hand the same vague spec to a coding agent and it will not stop to ask. It fills the gap with a guess and keeps going. The cost of an unasked question went up.

How it's built

Deliberately small: paste, read, copy or download as Markdown. No Jira or Confluence integration, no accounts, no document storage — all of it explicitly out of scope for the first version, so the one question worth answering stays answerable.

What I'm measuring

Not sign-ups. Whether anyone comes back with a second document within a week — that's the only early signal that the output was worth the paste. Rate limits and a kill switch are environment variables, so the cost of a bad day is bounded and I can stop it from a phone.