The pull request check, in two steps

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

1 · Add the workflow

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.

2 · Open a pull request

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.

When you are ready, make it a gate

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.

Things worth knowing

It fails open. If a scan errors, the check passes and says so in the log, so a scan error does not block your pipeline. The check still depends on its runtime, its dependencies and GitHub's infrastructure being available.

Your code stays where it is. The scan runs inside your own runner. Nothing is sent to us — no repository name, no file, no finding. The check uses network access to obtain its runtime and dependencies and to interact with your GitHub workflow and repository. In a standard setup that means checking out your repository from GitHub, setting up Node, installing the scanner from npm and posting the comparison back to your pull request.

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.

If something is wrong

Raise a request in our support portal or email support@eriksenlabs.com. 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.