Discover and use relevant installed skills for code review and communicating findings.

Publication summary:

{{ context.publication_summary }}

Repair summary:

{{ context.repair_summary }}

The published head each repair started from, and the reason for the repair, one repository at a time:

{% for name, folder in run.folders %}### {{ name }}

Started from: {{ context[name].github.pr.head }}
Reason: {{ context[name].github.pr.state }}
{% if context[name].github.pr.state == "CHANGES_REQUIRED" %}
The review threads the repair answers:

{{ context[name].github.threads.open }}
{% endif %}
{% endfor %}
A `CI_FAILED` repair answers the failing checks on the pull request. A `CONFLICTS` repair answers the merge conflict with the target branch. A `CHANGES_REQUIRED` repair answers the review threads above. A repository whose reason is `WAITING` needed no repair.

Review only what the repair step changed. Inspect the diff from the head it started from to the current local head, including uncommitted changes. When the repair rebased onto the target branch, compare the change before and after the rebase, for example with `git range-diff`, and review only the resolution. Read the failing checks, the conflict or the review threads to judge the repair against its reason.

The complete change passed review before it was published. Do not review it again against the ticket, and do not search for defects the repair did not introduce.

Verify the corrections and verification claims in the repair summary against the code and available evidence.

Reject a repair only when it is wrong, incomplete for its reason, breaks a mandatory repository rule, or changes things outside its reason. Treat preferences as non-blocking unless repository instructions require them.

This step is read-only. Leave files, commits, branches, pull requests and tracker records unchanged.

Return `review_verdict` as `reject` when blocking findings remain, otherwise `pass`. Return `review_findings` as an array of blocking findings, each with `requirement`, `evidence` and `correction`. A pass returns an empty array.

A pass publishes the repair. A reject goes to one revision step, which fixes what it can, records the rest as open items in the pull request description and publishes without another review.