Best for
- Founders and product owners with ideas but no spec
- Turning a chat message or a meeting note into something buildable
- Checking a new request against decisions you already made
What you give it
- The request in your own words (verbatim is best)
- Your existing requirements or decisions file, if you have one
- Constraints you already know: budget, deadline, rules
What you get back
- Requirements written as short numbered statements
- Acceptance criteria for each: how you will know it is done
- A list of open questions and conflicts with earlier decisions
How it works
- Reads your request and any requirements file you point it at.
- Separates what was asked from what it assumes, and marks every assumption.
- Writes each requirement as one testable statement with its acceptance criteria.
- Checks them against the decisions you have recorded and reports conflicts without resolving them.
- Hands you the requirements and the questions; you answer, it updates.
Example
You: Customers should get an email when their order ships, and be able to turn it off.
Result: R1 A shipped order sends one email to the buyer. R2 The buyer can opt out of shipping emails from their account. Acceptance: an opted-out buyer receives none. Open: does opt-out also cover receipts? Which address is used if the buyer changed it?
Limits — please read
- It cannot know your business rules: it asks instead of guessing.
- It does not size, schedule or design the solution.
- Quality depends on the verbatim request: paste your words, not a summary.