Put a requirement next to the product that already exists.
See what is already there, what would change and what still needs clarification before work is handed to engineering.
Paste a brief, a page of a specification, or a change request, and GitMir lays it over the product that is already built. You get three lists back: what the product recognised, what it could not tell apart and needs a person to settle, and what it has never heard of. Under them is the reach — how many things a change like that would touch, and how risky it looks.
Open the project's Documents screen and paste the text — an email, a specification page, a change request.
Read the three lists: recognised, ambiguous, never heard of.
Settle an ambiguous phrase by picking which part of the product the customer meant; the answer is recorded with your name so nobody is asked again.
Take what the product has never heard of back to the requester as your open questions.
Write the agreed work down on the project's Work screen, with at least one line of what must be true when it is done.
Nothing you paste is stored — only the wording you settle and the work you choose to write down. It is not a contradiction detector: it tells you what the document lands on, not whether the requirement is right or complete. Anything still unsettled is deliberately left out of the reach rather than guessed at, so the reach is a floor, not a full scope.
See it on a real product.
Three models are published in full and open without an account. Ask one of them the question this page is about.