Review a dependency update with an agent
Intended result
Every dependency update the bot opens gets one verdict from one rule: it meets the normal checks, or it needs a person, with the reasons written down. The updates that pass can be merged by Maplith after it checks every condition again on the live pull request; the rest become a work item with the reasons. Nothing is merged on the strength of a pull request's own description.
Prerequisites
| You need | Why | Where |
|---|---|---|
| A dependency bot that opens grouped, weekly updates | The bot’s commits are signed by the platform, which is what lets the rule trust that every commit is the bot’s own. | The repository’s bot configuration |
| Tests that gate the main branch | The rule requires every workflow run on the update’s commit to have passed, the required one among them. | The repository’s rules for the main branch |
| A written rule: held packages, allowed step sizes, allowed files | The verdict is the same for every update and explainable from the rule alone. | The rule, kept in the repository and changed only in a reviewed pull request |
| A Maplith workspace with the repository connected, and the merge operation declared | The signal per update and the merge request are Maplith’s; the operation is what the agent asks for. | Maplith › Integrations, and Agents & access › Policies |
Steps, with the expected result
- The bot opens the updateDo this: nothing; the bot opens its weekly groups on Monday morning. You should see: one pull request per group, labelled by the bot.
- Maplith raises one signal with a verdictDo this: nothing; the repository watch reads the pull request. You should see: a signal naming the files by kind, each version and how far it moves, the test state, and the verdict with its reasons.
- The agent acts on the verdict in its passDo this: for a verdict to merge, ask Maplith for the merge; otherwise ask for a work item with the reasons. You should see: the request in Maplith, pending or carried out.
- Maplith checks again, waits, and merges or refusesDo this: nothing. You should see: the merge of the exact commit it checked, after the tests pass and the branch is up to date; or a refusal with its reason, which the agent hands on.
- A person decides the restDo this: read the changelog and test the touched flow; merge, or close with a comment naming the package. You should see: the pull request closed, and the signal cleared.
Two updates of 2 November 2026
#2187: Next.js, a patch step
The web framework, moved one patch version. The framework is on the held list, so the rule hands it on whatever the size of the step. A person merged it at 17:13, with a merge commit on the main branch.
#2188: three packages, minor and patch steps
A grouped update of three packages in the shape the rule allows. Three minutes after #2187 merged, the bot closed #2188 as superseded and opened #2227 with the same updates on the new main. A person merged #2227 at 19:47, along with the actions pins the founder merges by hand.
The rule, as the repository holds it
| Condition | What it means |
|---|---|
| Opened by the bot, every commit the bot’s own | Authored by the bot and committed and signed by the platform. A commit a person pushed makes it a person’s change. |
| Only package manifests and lockfiles, each modified | A workflow file is the founder’s to merge; any other file is code. |
| Each version a patch or minor step of a released version | A major version is a planned upgrade with its own issue; a pre-release step counts as major. |
| No package on the held list | Payments, the framework, the database and sign-in clients, and one pinned driver: never without a person. |
| Every workflow run on the commit finished and passed | The required workflow among them. An update whose tests still run keeps its verdict and waits. |
| The platform says it can be merged | Checked again at merge time, on the exact commit the rule judged. |
Approval and manual boundaries
Maplith may merge
Only an update whose signal says merge, only the commit it checked, at most a few a day, never while a scan runs, and never in a short window each morning. It waits for the tests for a bounded time and brings a branch that is behind main up to date itself.
A person merges
A held package, a workflow change, a major version, a failing test, or anything with a reason on it. The changelog is read and the touched flow tested first.
Nobody merges on a description
The rule reads what the pull request changes and what the tests say. The pull request's own text is not evidence, and a comment by a bot is not an approval.
Failure recovery
A merge that does not go through ends in one of two ways. "Not merged yet" means the wait ran out, the day's merges were used, a scan ran throughout, or the platform refused just then; the agent asks again in a later pass. "Not merged" means a condition failed on the live pull request; the agent hands it on with Maplith's reason, and a person decides. An update the bot supersedes, as #2188 was, closes itself and its signal with it; the replacement gets a signal of its own.
Questions people ask
Why did a person merge the routine group?
The record says only that a person did, at 19:47 UTC on 2 Nov 2026. The merge path in Maplith has its own waits and limits; whether it looked at #2227 first is not in the repository's record and is not claimed here.
Can I get this on my repository?
Not as a hosted feature. The hosted GitHub integration comments and proposes and does not merge. If the merge path is what you want, tell us; it is a decision about who may change your main branch.
Who changes the rule?
The founder, in a reviewed pull request. The held list is shortened or lengthened the same way.
Sources and last-tested date
- GitHub: Dependabot, the bot that opens the updates
- Maplith docs: the GitHub integration, what the hosted integration does and does not do
- The repository's own records: the rule, its playbook, and pull requests #2187, #2188 and #2227 with their merge commits. Last tested 2 Nov 2026, the day of the two examples.
Read the use case
The use case page says what this workflow is for, what Maplith supplies and where a person decides.