Green PR

Deliver a reviewable pull request with green checks and a clear account of what changed. Stop before merge. A green badge is evidence about a commit, not proof that the product does what the person asked for.

Confirm scope and authority

Read repository instructions. Identify the working directory, feature branch, remote, base branch, existing PR, and the requested outcome. Inspect status, recent history, unstaged changes, and staged changes before editing or publishing.

The user's request must authorize pushing a branch and opening or updating a PR. The skill itself grants no access or permission. For a review-only request, report findings without committing or publishing changes. If publication access is missing, prepare the local patch and explain the exact handoff needed.

Preserve unrelated changes. Stage explicit owned paths, never a whole dirty checkout by habit. Ask about ambiguous ownership. Do not discard lockfile churn, generated files, or another person's work merely because they look incidental. Never commit credentials, tokens, private keys, local configuration, or private logs. Inspect the PR body and attachments for sensitive information too.

Synchronize before spending a CI cycle

Fetch the intended base and compare branch history. Follow the repository's merge or rebase policy. Before rewriting a feature branch, preserve its original head with a recovery ref and confirm that rewriting it will not disrupt others.

Resolve conflicts only when the intended behavior is clear. If multiple coherent interpretations remain, stop and ask about the exact conflict. Never select one side wholesale to get through the operation. After a rebase, inspect the full base-to-head diff and run the checks affected by conflict resolutions.

Use a normal push when possible. Use a force push only with a verified lease, on an authorized feature branch whose history was deliberately rewritten. Never force-push a base branch or bypass branch protection.

Establish the acceptance checks

Derive commands from the actual CI configuration, package scripts, changed components, and user-facing acceptance criteria. Do not assume a language, package manager, test runner, or hosting service.

Run relevant formatting, generated-file validation, lint, type checks, and focused behavioral tests. Exercise the interface or deployment path when the change needs it. Inspect the complete diff for stubs, debug code, suppressed errors, weakened assertions, and unintended behavior changes.

Optional helpers may investigate disjoint failures when delegation is available and authorized. Give each helper explicit file ownership and acceptance checks. Keep one controller responsible for Git operations, final review, and claims. No particular model or multi-agent runtime is required.

Publish a clear review artifact

Commit accepted changes, push the feature branch, and reuse an existing PR instead of creating duplicates. Respect repository policy on draft versus ready status. Keep the description human-readable:

• What problem this solves and what now works.
• The important changes and any interface evidence or mockups.
• Tests run, their results, and anything not yet verified.
• Compatibility, migrations, rollout or rollback concerns when applicable.
• Risks and explicit deferrals.

Link detailed evidence rather than pasting a transcript of the agent's work. Never claim a deployment, release, or live acceptance test that did not happen.

Drive checks to a truthful result

Watch the PR's checks, inspect the first failing job's actual logs, and fix the root cause. Use the repository's supported tooling. For a GitHub repository with the GitHub CLI available, the corresponding commands are:

gh pr checks --watch --fail-fast
gh pr checks --watch

The first command provides early failure feedback. The second verifies the complete suite after no failure remains. Neither grants permission to merge.

Do not obtain green checks by skipping tests, deleting assertions, broadening types to hide errors, adding blanket suppressions, loosening thresholds, or swallowing failures. Correct an assertion only when evidence shows that its previous expectation was wrong, and explain why.

Before calling a failure pre-existing, reproduce it on the base revision. Before calling it flaky, investigate its intermittent cause. Do not rerun an unexplained failure until luck produces green. If a required gate depends on credentials, human approval, or unavailable infrastructure, report it as blocked instead of weakening the gate.

Final review and handoff

Re-read the complete diff against the user's intent. Confirm that no work or known failure disappeared from the report. Fetch the base again and apply the repository's freshness policy; a new rebase requires checks on the new commit.

Verify every required check is successful for the exact pushed head SHA, not an older commit. Missing or pending checks are not green. Report unresolved review comments or approvals separately, even when CI passes.

Hand off the PR URL, head SHA, concise outcome, test evidence, remaining risks, and any action required from the reviewer. Leave the PR open. Do not merge, enable auto-merge, enqueue a merge, or use an administrator override.