The pull request check, in two steps

About two minutes. It is free on every repository and there is no key to configure.

Create .github/workflows/what-it-does.yml with this:

name: what it does
on: pull_request

jobs:
  behaviour:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: rolfe099-sketch/what-it-does/action@v1

Those two permissions are all it asks for: read the code, write the comment. If your application does not sit at the repository root, add path: apps/web or wherever it lives.

That is the whole setup. On the next pull request that touches server-side code, the check scans the base branch, scans yours, and comments with what changed about the application's behaviour.

It says nothing when nothing changed. A silent check is the normal case, and it is what earns the right to be noticed on the pull request that did change something.

Add fail-on-new: true and the check fails when a finding appears that was not there before — a delete endpoint that stopped checking who is asking, for instance.

Leave it off for the first week. Read a few real comments, decide whether you trust what it reports, and turn it on once you do. A check that breaks the build on the day it is installed is a check that gets removed on the day it is installed.

It fails open. If a scan errors, the check passes and says so in the log. It will not block your pipeline because something on our side went wrong.

Your code stays where it is. The scan runs inside your own runner and nothing leaves it — no repository name, no file, no finding, no request at all.

The scanner is the same thing, locally. Run npx what-it-does on your machine any time for the full report. Both are MIT licensed and always will be.

Email [email protected]. If the check said something about your code that turned out to be wrong, that is the most useful message you can send us — it is how the accuracy work continues.