Maintenance: AI-assisted auto-merge for low-risk Dependabot PRs

[hjgraca]

Summary

Explore AI-assisted auto-merge for low-risk Dependabot PRs. Today Dependabot
opens dependency-update PRs (label dependencies) that a maintainer reviews and
merges by hand — e.g. routine GitHub-Actions and NuGet patch/minor bumps. This
proposes a one-shot agent, triggered by the dependencies label, that judges
whether a Dependabot PR is low-risk and, if so, approves it and enables GitHub
auto-merge (which still waits for all required checks) — otherwise it leaves
a comment explaining why it was held for a human.

The agent is a reference architecture from
agentic-sdlc (github-pr-label-actions).
The "low-risk" decision is the model's judgement bounded by an explicit policy
that lives in a skill file: patch/minor only (never major/unknown), combined CI
must be green, and the diff must be manifest/lockfile-only. The agent works
entirely through the GitHub API and never checks out or runs PR code.

Why is this needed?

Routine Dependabot bumps (Actions SHAs, NuGet patch/minor) make up a steady
stream of low-risk PRs that cost maintainer time to triage and merge manually.
Safely auto-merging the clearly-low-risk subset reduces that toil while keeping
required checks as the gate, and keeps the policy auditable in-repo.

Which area does this relate to?

• Automation
• Governance

Solution

A label-triggered, one-shot workflow that runs the agent. On a Dependabot PR
labelled dependencies it: reads PR metadata + the version bump + combined CI +
the changed files; if the policy passes, approves and enables auto-merge
(squash); otherwise comments why and applies a hold label.

I'll follow up with a PR. Open questions for the team to decide — this is
experimental:

1. Security posture. This repo deliberately avoids raw pull_request_target
   and uses the hardened workflow_run-off-"Record PR details" pattern with
   SHA-pinned, allowlisted actions. The reference implementation uses
   pull_request_target (gated to dependabot[bot] + the dependencies label,
   API-only, no PR-code execution). The PR should be adapted to this repo's
   pattern and secure_workflows.yml allowlist before it would be acceptable.
2. LLM backend / AWS account. The agent calls Amazon Bedrock via GitHub OIDC,
   which requires a team-owned AWS account with an OIDC role scoped to Bedrock.
   Provisioning that account/role is a prerequisite the team would need to own.
3. Scope of "low-risk." The starting policy is patch/minor + green CI +
   lockfile-only. The team may want it stricter (e.g. patch-only, or
   GitHub-Actions ecosystem only).

Filing this first per the contributing guidance that PRs on non-triaged issues
may not be successful; happy to adjust scope based on feedback before opening the
PR.

Acknowledgment

• This request meets Powertools for AWS Lambda (.NET) Tenets