Code and Requirements all in one place
When requirements sit with the code, the statement of what the product must do and the change that does it share one history. A tracker, a wiki, or a chat thread keeps a second copy that falls behind. Reviews then guess which sentence still applies, and an agent has to rebuild the intent before it can do the work.
How it works
-
You say what the product must do, one requirement at a time, in language a person can approve and an agent can carry out. Each requirement keeps its identity as the product changes, so later work refers to that statement instead of a conversation that has moved on.
-
Each requirement stays tied to the work that fulfills it and to the evidence that it was met. Someone building it, or someone checking a release, can see the ask and the proof together.
-
That same set is what you read and what you share. A report shows what was required, what was built, and how it was checked, without asking a reviewer to learn the tool. The hosted app is one way to open the set. The requirements stay with the product.
Features
-
Git compatible
Requirements travel with the product. They are reviewed and merged with the changes they describe, so the history of a decision is the history of the work.
-
LLM agent friendly
An agent can draft a requirement, do the work it names, and check the result against the same statement a person would use. Nobody has to translate a ticket into a prompt first.
-
Portable text
The requirements are ordinary text you can read, copy, and archive. The hosted application is a view of them. Leaving it does not mean leaving the requirements behind.
-
Output reports
A report lays out each requirement with the work that carries it out and the evidence that it was met, in a form you can send to a reviewer or keep with a release.