Guide to GitHub Status Checks for AI Code

A row of green checkmarks on a pull request feels like a verdict: the code works, so it's safe to merge. With AI-written code, that feeling is especially tempting, because the agent usually reports that everything passed. Yet many pull requests show a dozen checks, few people know what each one does, and a check can only confirm what someone thought to test.

Status checks are automated tasks, usually run by GitHub Actions, that test or inspect a change and report a pass, a failure, or a skip. Reading them well means knowing which checks ran, what each one actually tests, and why some never ran at all. Some report success after being skipped, some wait for a person to allow them to run, and agents have been caught editing tests until they pass. A failed check, on the other hand, comes with a log that explains what went wrong, and opening it often reveals the problem in plain words, even without reading code.

A check proves only what it tests. Passing checks are a good start, and looking at the result yourself finishes the job. Clicking through a preview of the change, or asking someone to test it, catches problems no automated check was written for.

Status checks on GitHub

Status checks show whether commits meet the conditions set for a repository ^[1]. Most come from GitHub Actions or other apps, and each reports a result: success, failure, pending, or skipped.

A check only knows what it was built to test. A check that builds the site confirms that it builds, not that it looks right. A check that runs tests confirms the tested behavior, and nothing the tests don't cover.

The Checks tab of a pull request explains which validations ran and why each passed or failed, so the meaning of a green mark is always one click away.

Reading the checks on a pull request

A pull request's merge box summarizes its checks: how many passed, failed, or are still running, with each one listed by name. The Checks tab shows the same list with full details and logs.

Names usually hint at what a check does, like build, test, lint for code style, or deploy-preview. Required checks are marked as such, and the pull request can't merge until they pass.

Reading the list instead of the summary matters. All checks have passed can hide the fact that only a style check exists, or that the check that matters most never ran. Opening the details of the one that matters most, usually the tests or the preview, is a good habit.

Reading a failed GitHub Actions run

Opening a failed check leads to its run in the Actions tab. A run is made of jobs, each with steps, and failed steps are expanded automatically to show their output ^[2].

The last lines before the failure usually explain it in words, like Expected 12 but received 10 or File not found: menu.html. Reading them doesn't require writing code, and pasting them into a comment saves a developer the first 10 minutes of investigating.

Runs can be repeated with Re-run failed jobs, which helps when a failure was a temporary glitch ^[3]. A check that fails twice in the same way is reporting a real problem.

Skipped checks that look like passes

A check that didn't run can look like one that passed. GitHub's documentation states that a job that is skipped reports its status as success, and that it won't prevent a pull request from merging, even if it's a required check ^[4].

Jobs get skipped for ordinary reasons, like a condition that wasn't met, and the result is a green mark that tested nothing. Other cases behave differently: a whole workflow skipped by its filters leaves required checks pending, which blocks merging until they report.

When a pass seems too quick, opening the check shows whether its steps actually ran. A green mark with no steps executed is a skip, not a pass.

Workflows waiting for approval

On pull requests from Copilot cloud agent, GitHub Actions workflows don't run automatically. Someone has to select Approve and run workflows in the merge box first ^[5].

The pause is a safety measure. Workflows can be privileged and reach sensitive secrets, so a person checks the agent's changes, especially to workflow files, before letting them run. Repository admins can switch this requirement off, but human approval is the default ^[6].

This changes what a missing result means. On an agent's pull request, no check results may simply mean nobody has approved the run yet, so there's nothing to read until someone does.

Green checks vs. correct code

Passing checks show that a change meets the conditions someone wrote down. They don't show that the change does what was asked, works for real users, or is a good idea.

With AI-written code, the gap can be wider, because the code is optimized to satisfy whatever is measured. Even GitHub's AI reviewer comes with a caveat: Copilot is not guaranteed to spot all problems in a pull request ^[7].

A green mark is a minimum, not a verdict. The questions a check can't answer, like is this what the customer needed?, are exactly the ones a person brings to a review.

Testing a preview before merging

The most direct check is to try the change. Many hosting services add a preview deployment to each pull request, a temporary version of the site with the change applied, linked from its checks or its conversation.

Clicking through a preview catches what no automated check was written for: a button that goes nowhere, text that overflows on a phone, a price that's wrong. For designers and product managers, it's often the most valuable review they can give.

When there's no preview, screenshots or a short recording from the author are the next best thing. Developer Simon Willison makes the same point about AI coding: eyeballing every line of code has never been the most effective way to validate a change ^[8].