Require verification before an agent hands over a pull request

Have the agent complete the relevant build, test, and review checks before presenting its change for approval.

Prompt

Evaluate and apply this CI technique to my repository: Require verification before an agent hands over a pull request.

Have the agent complete the relevant build, test, and review checks before presenting its change for approval.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/verify-before-agent-pr.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Let an agent open a pull request only after build, tests, coverage and lint pass

DoorDash's feature-flag cleanup system turns a stale-flag ticket into a merge-ready pull request. Removal agents run in parallel, up to four per repository, each in its own git worktree, and Gradle runs with --no-daemon so parallel worktrees share no state. Before an agent may open a pull request it must confirm the build passes, the tests pass, patch coverage is at least 95% on changed lines and the Detekt linter is clean, retrying until each gate passes. On the 50 most recent stale flags, the system produced usable pull requests for 45, at an average of $4.79 and 13.8 minutes per flag.

the system produced usable PRs for 45 of them at an average cost of $4.79 and 13.8 minutes per flag Source

Use it when: Agent pull requests go red in CI after they open, or parallel agents share one checkout.
Before applying it: Local gates must match the required checks exactly; a gate that runs only in the agent's sandbox can drift from CI.

Make the verification stack a skill the agent must pass

In the Agents SDK repositories, a code-change-verification skill runs the formatting, lint, type-check and test stack whenever runtime code, tests, examples or build and test behavior changes, and AGENTS.md says the work is not complete until it passes. Docs-only changes skip it. Separately, the JavaScript repository's changeset-validation skill keeps its validation rules in a shared prompt, so local runs and GitHub Actions use the same logic.

The skill encodes the repository’s definition of “verified,” and AGENTS.md makes that definition enforceable. Source

Use it when: Agents report a change done before running the commands your CI runs.
Before applying it: Keep the skill's command list identical to the workflow's, and update both in one change.

Have the coding agent hand over a visually validated pull request

Translated to GitHub Actions

What Ramp built: Ramp's Inspect takes a task from Slack, GitHub, Linear or the web and turns it into a visually validated and reviewed pull request.
Your GitHub Actions version: A coding agent that gathers context, fixes the issue, attaches visual proof and prepares the pull request for review.

Ramp's Inspect takes a task from Slack, GitHub, Linear or the web and converts it into a visually validated and fully reviewed pull request, using the team's development environment in the cloud. For a mobile bug, a screenshot and a one-line message are enough: Inspect gathers context, pinpoints the issue, fixes it, provides visual proof and prepares the pull request for review. Ramp reports 99% of its engineering, design and product teams used Inspect in the past month, and that Inspect accounts for 74% of merged PRs.

2026: Inspect accounts for 74% of Ramp's merged PRs, and 99% of its engineering, design, and product teams used it in the past month. Source

Use it when: Changes can be described in a message, the development environment runs in the cloud, and reviewers want to see the result before they read the diff.
Before applying it: Every agent pull request still goes through the same review and required checks as any other, so the review queue is where the volume lands.
GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation.

Run verifiers and a judge before an agent opens a pull request

Translated to GitHub Actions

What Spotify built: Spotify's background coding agent runs independent verifiers and an LLM judge before it opens a pull request.
Your GitHub Actions version: Verifiers that activate from the repository's contents, with a red verifier stopping the pull request from opening, then a judge that reads the diff against the original prompt.

Spotify's background coding agent runs one or more independent verifiers before it opens a pull request. A verifier activates from the repository's contents, such as a Maven verifier when a pom.xml sits at the root, and returns a short error summary so the agent keeps its context window for the change. In Claude Code the checks run from the stop hook, and a red verifier stops the pull request from opening. An LLM judge then reads the diff and the original prompt and flags changes that go beyond the instructions, such as refactoring code or disabling flaky tests.

Spotify reports that out of thousands of agent sessions, the judge vetoes about a quarter of them, and the agent is able to course correct half the time. Source

Use it when: Agents or bots open pull requests across many repositories, and reviewers spend time on changes that stray from the task.
Before applying it: The judge adds a model call to every session. Give it the diff and the original prompt, and run it after the deterministic verifiers pass.
GitHub Actions adaptation: Compare the source system with your own workflow before applying this translation.

How companies used this technique

Let an agent open a pull request only after build, tests, coverage and lint pass

Make the verification stack a skill the agent must pass

Have the coding agent hand over a visually validated pull request

Run verifiers and a judge before an agent opens a pull request

Company Playbooks