How it works

One loop. Two ways in. Your CI at the end.

Patchlit never decides whether a fix worked. It makes a small change, pushes it, and your own checks give the answer.

Input one

Dependency updates

Starts by itself when a bot’s PR goes red, unless you chose to approve each one first.

  1. 01

    Red CI

    A Renovate or Dependabot PR fails its checks.

  2. 02

    Gather

    Failing job logs, the version diff, and the files the logs name.

  3. 03

    Write the fix

    Up to three model calls, aimed at the smallest change.

  4. 04

    Vet

    Checked against your limits and protected paths before any push.

  5. 05

    Push

    One commit on the same PR branch, marked with a trailer.

  6. 06

    Your CI

    Green on that commit is the verdict. Red means try again, up to your cap.

Input two, off until you switch it on

Bug reports, reproduce first

The extra safeguard: no fix is written until a person has read the test that proves the bug.

  1. 01

    Label an issue

    A trigger label you chose, added by someone who can label issues.

  2. 02

    One failing test

    Patchlit writes a single reproduction test and opens a PR holding only that.

  3. 03

    Your CI confirms

    Red means the bug is reproduced. Green with no fix means it was not, and the PR closes.

  4. 04

    You approve

    A person reads that one test and adds the patchlit-go label. Nothing happens without it.

    a person decides
  5. 05

    The fix

    The same loop as a dependency PR, with the same vetting and the same caps.

  6. 06

    Your CI decides

    Green on Patchlit's commit counts. You still review and merge.

Reproduction tests are JavaScript and TypeScript only today.

What it reads

Only what the failure points at. Not your whole repository.

  • The failing job logs
  • The version change in the PR
  • Files the logs name, and what they import (3 levels, 12 files)
  • Your contributing guide and style config, only if you switch analysis on

When it stops, and says so

A clear hand-back to a person beats a confident wrong fix.

  • The failure is not caused by the bump
  • It needs a command run, such as regenerating a lockfile
  • The fix would touch a protected path
  • The fix grows past your file or line limit
  • CI uses secrets and you have not allowed that
  • It has used all its attempts

See what you can tell it to do, and not do.