pr-review

PR review

Publish one GitHub review built from two independent reviews of one PR by Codex and Claude: a Comment review carrying the verified findings, or an Approve review when the review is complete and nothing blocking remains. Generic auditing belongs to review-code-changes. Following up on replies and new commits, resolving threads and later approval belong to pr-review-followup; repairing your own PR belongs to pr-followup; when the intended GitHub actor is the PR's author, use that instead. This workflow never requests changes, resolves threads or modifies the reviewed code.

Resolve dependencies by registered name through the host catalog, independently of the reviewed repository. Read review-code-changes before preparing inputs or judging findings. It owns audit criteria, evidence, severity and report grammar. Read compare-solutions for the same-task independent attempt and evidence-based synthesis contract. This caller retains the fixed two-engine roster and its own coordinator: no third judge, nested coordinator or facet allocation. Read origin.toml for these composition choices. Before wording comments, resolve required comment-style. It owns wording; this skill owns selection, placement and API writes. communicate-clearly is optional general support, not another mandatory prose pass. A missing dependency blocks its dependent phase; preserve independently useful work.

Prepare one reproducible review

1. Identify the PR and its rules. Read profiles.md. Capture its full URL, number, title, body, author, closingIssuesReferences, baseRefName, baseRefOid, headRefName and headRefOid in pr.json. The URL identifies the target repository even for a fork. Resolve relevant repository instructions, requirements and standards with their source, revision and applicability. When the conversation is dedicated to reviewing this PR and the host can rename it (T3: t3_thread_update with rename), title it [REVIEW] #<number> <ticket> <author>. The ticket is the subject ticket of the Brief, in its tracker's canonical form, such as ABC-123, #141, or owner/repo#141 for another repository's issue, else NO_TICKET; the author is the PR author's login, or the name the profile's Author names give it.
2. Establish the checkout. Follow the host's checkout ownership rules. Fetch the required target-base and PR-head objects using the authorized Git transport. The checkout must be clean and at the captured PR head. Use the actual target base, including stacked PR bases; do not substitute the tracking branch or main. A supplied SHA that is unavailable is a prerequisite to resolve.
3. Write review-context.md. Use the Brief below. Keep existing feedback and prior conclusions out of it.
4. Freeze the shared packet. Read reviewers.md, then run scripts/snapshot.py prepare with the catalog-resolved auditor, context, PR input and any filtered profile. Supply every applicable domain guide through --rules so both engines receive it. When the diff adds or changes rendered UI and the accessibility skill resolves by registered name, stage its web or platform reference under a path-derived name and pass it with the review-practice authority class; when it is unavailable, record that and continue. The helper records immutable base/head/merge-base, the unique changed-path JSON (including deleted paths), a rename-origin map, the exact diff, source hashes and actual Git state. Its private manifest remains with the parent. Only review-relevant profile sections enter the shared packet. An empty diff is a valid scope.