Use a fixed commit prefix, a small label set that marks ecosystem and update level, and an owner for routing. Update tools let you customize titles, labels, branch names and assignees. Consistent naming lets you filter bot pull requests, feed release tooling and report on update lag without reading each one.
What you can customize
The options reference of one major bot lists several controls:
- A commit message prefix, up to 50 characters, used for commit messages and therefore pull request titles. It inserts a colon after the prefix when the value ends in a letter, number or closing bracket, and a trailing space stops that. A separate prefix can be set for development dependencies in several ecosystems, and an include option adds the dependency type scope after the prefix.
- Labels. By default every pull request gets a dependencies label and an ecosystem label, and if semantic version labels already exist in the repository, major, minor or patch labels are applied automatically. You can set your own labels.
- Branch names. The default form is the bot's name, then the package manager, then the dependency. The separator, prefix, maximum length and casing can be changed, and a template can be provided.
- Assignees. By default none. Assignees must have write access, and for organization repositories, members with read access are also valid.
The second bot documents a sensible default for reviewers: when automerge is on, it does not add assignees or reviewers at creation, to cut notifications, and adds them only if checks fail so automerge is not possible.
A sane starting set
| Item | Suggestion | Why |
|---|---|---|
| Commit prefix | Short and fixed, such as a conventional type | Release tools can parse it |
| Dev dependency prefix | A different scope | Lets you separate runtime from tooling |
| Labels | Ecosystem, update level, security | Filtering and dashboards |
| Assignee | A team or on-call owner | A bot pull request needs a human |
| Branch name | Keep default unless a rule needs it | Fewer surprises |
Why this matters beyond tidiness
Release tooling often reads commit prefixes to decide a version bump and a changelog. If your update bot writes a prefix that your release tool reads as a feature, you may publish a new minor release just because a dependency changed. Pick a prefix your release process treats as a chore or a fix, as appropriate.
Labels also drive reporting. If you can filter open bot pull requests by label and age, you can measure update lag, one of the most useful exposure measures. Our post on dependency update lag as an exposure metric explains how to use it.
Finally, ownership. Our post on who owns a bot pull request when it breaks something argues that every bot pull request needs a named owner. An assignee or a code owner rule is how you encode that.
Steps
- Write down how your release tool reads commit messages. Choose prefixes that match your intent.
- Create the labels once, so the bot reuses yours instead of creating new ones.
- Add a label for security updates, so you can sort them first.
- Route by ecosystem. Container image updates may go to a platform team, library updates to the service team.
- Review monthly: how many bot pull requests have no owner?
Quick check
Can a bot pull request title break my release process?
Yes, if your release tool turns commit prefixes into version bumps. Set a prefix that matches how you want dependency changes released.
Should every bot pull request have an assignee?
Every one needs an owner. Some tools skip assignees on automerge pull requests and add them only when checks fail, which is reasonable.
Safeguard works alongside your pull request process. It builds an SBOM from manifests and lockfiles, applies policies and gates to changes, and uses reachability analysis to show which flagged dependencies your code calls. Fix pull requests are off by default, with every category on Manual. Try a free scan.
Sources
- Code host documentation: update bot options reference, commit messages, labels, branch names and assignees
- Update bot documentation: automerge, assignees and reviewers
Last reviewed: 19 October 2026.
