---
name: green-pr
description: Prepare an authorized feature branch or existing pull request for human review by synchronizing its base, fixing root causes, and verifying all required CI checks on the exact pushed commit. Preserve unrelated work and stop before merge.
---

# 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:

```bash
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.