You hold the controls.
Every one of these is per repository and enforced in the code that decides what Patchlit does, then checked again on what actually landed. Anything you leave alone keeps the safe default.
Real defaults and ceilings. In your dashboard these are saved per repository and enforced before every push, and again on what landed.
- src/routes/orders.js2 lines
- src/billing/invoice.jsprotected
- db/migrations/004_orders.sql1 lines
- src/lib/format.js40 lines
Dependency PRs
Which red PRs Patchlit takes on, and whether it asks first.
Which bots count
Choose whose PRs are in scope.
Opt-in label
A label that brings any other PR into scope, such as a person's.
Ask me first
Patchlit waits for the patchlit-go label before it starts a fix.
Issues
Bug reports, reproduced first and approved by a person.
Switch issues on
Per repository. Reproduction attempts are free; you are counted only when a fix is pushed.
Trigger labels
Patchlit looks at an issue only when one of these is added.
Skip labels
Never when one of these is present. Feature requests and questions are better left to people.
Limits
How big a fix may get before it is handed back.
Attempts per PR
Pushes tried before Patchlit stops.
Files per fix
The most files one fix may touch.
Changed lines per fix
Bigger changes are refused and handed back.
Safety
Where Patchlit must not go, whatever the model suggests.
Protected paths
Folders and patterns Patchlit must never change, such as src/billing/ or **/*.sql. Always on top of the built-ins.
Secrets in CI
If your workflows use secrets, Patchlit pushes nothing until you allow it for that repository.
Voice and learning
How much Patchlit says, and how much it learns about you.
Comment style
Post every step, or only the verdict. Refusals are always posted.
Read my conventions
Optionally reads your contributing guide and style config first, refreshed weekly.