The hard part of PR testing often comes before the test

One thing I keep running into when reviewing a PR is this: before writing a test, I first have to work out what the change is actually supposed to prove.

My first instinct was to generate E2E test drafts from diffs. It looked useful on paper. In practice, a lot of the output was obvious: click something, then check the success screen.

So I am trying to start one step earlier.

I have been building QAMap, a small local CLI that reads commits and diffs, tries to describe the behavior a change touches, and points out QA questions that may be missing around failures, boundaries, and state changes.

It runs locally. It does not upload source code or make LLM calls.