lema · docs

Verify

A GitHub Action on every pull request that answers one question: did the diff do what the description says? It compares the PR’s stated changes to the actual changes and reports both directions of drift — as a neutral check run with inline annotations, never a blocking gate you didn’t ask for.

What it checks

Agents — and humans — routinely ship diffs whose descriptions have drifted: a promised change quietly dropped, an extra change quietly included. Verify reads the pull request’s description (and the issue it references) against the diff itself and sorts every stated or shipped change into three buckets:

Stated and found
A change the description claims, located in the diff — with the file it landed in.
Stated but not found
A change the description claims that the diff does not contain — the drift reviewers miss most.
In the diff, not described
A change that shipped without being mentioned — annotated inline on the lines it touches.

The result lands as a neutral check run on the pull request — a summary comment plus inline annotations on the undescribed lines. What verify does not do is just as load-bearing: it does not review code quality, correctness, or style, and it does not decide whether the change is a good idea. It checks the claim against the artifact, and stops there.

Add it to a repo

One workflow file. Save the yaml as .github/workflows/description-check.yml, commit it, and every pull request from then on gets a description check. No lema account, no signup — the action authenticates via GitHub OIDC.

The fetch-depth: 0 checkout matters: verify diffs the pull request against its base, so it needs the history, not a shallow snapshot.

The action is published as lemahq/lema-verify@v1. It takes two inputs — api-url and github-token — and nothing else.

.github/workflows/description-check.yml

name: description check

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write
  id-token: write
  checks: write

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: lemahq/lema-verify@v1
        with:
          api-url: https://api.lema.sh
          github-token: ${{ github.token }}

Authentication

Two ways in, both plain:

GitHub OIDC (the default)— the workflow above. The run proves which repo it is to lema via GitHub’s own OIDC token; there is no lema key to mint, store, or rotate.
A lema API key — for callers outside GitHub Actions, POST /verify on api.lema.sh accepts a lema_live_ key (see Connect your repo).

Limits and failure modes

Fail-open, by design.If lema is down, slow, or over budget, the check reports that plainly and never blocks your merge — a verification tool that can’t be verified should get out of the way, not hold your release hostage.

Checks meter per repo, per month— 50 free, 500 on Pro — because pull-request volume, not org size, is what drives them. Past the allowance, or past the service’s own daily budget, the check says exactly that and when it resets; it never fails silently and never turns red because of us. Allowances are on Plans & usage.

Connect your repo Plans & usage