pr-review

PR Review

ultrathink

Respond to PR review comments for: $ARGUMENTS

Migrated from the pr-review command under ADR-064, which makes skills the single user-invocable surface. The command file is gone, so its path is named here in plain text rather than as a citation to something a reader could open. The config moved with it, from the command directory into this skill.

Load configuration from pr-review-config.yaml for scripts, completion criteria, error recovery, and failure handling tables. It sits beside this file, so the skill directory is the one place the resolver, the dispatcher default, and the shipped copy all agree on.

The bundled copy IS runnable from an installed plugin (issue #5112, Option 1). When resolve_pr_review_config lands on a config inside a host-declared plugin root (COPILOT_PLUGIN_ROOT or CLAUDE_PLUGIN_ROOT) whose tree is disjoint from the consumer's git work tree, the completion gate treats that origin as install-trusted: the operator installed it and PR content cannot write there, so the gate skips the byte-identity check it would otherwise run against the trusted ref. This reverses an earlier stance that called the bundled copy a reference artifact; under that stance an installed /pr-review could not dispatch at all, because path containment refused the config before any check ran.

Disjoint, not merely "outside." Neither tree may be at or under the other, and the difference is not pedantic. A root of $HOME with the repository at $HOME/repo is "outside" the work tree in the loose sense (it is not a subdirectory of it) while containing every file the checked-out PR wrote. That reading was in an earlier draft of this paragraph, and the matching one-way test in the gate admitted exactly that root, so a PR-authored config became install-trusted and skipped verification. Both directions are checked now. The boundary is the real work tree from git rev-parse --show-toplevel, because a directory marker inside the repository can be created by the PR and therefore cannot anchor trust. If the work tree cannot be established, no root install-trusts anything and the gate exits 3.

Runtime prerequisite. The gate parses YAML, and the plugin declares no dependencies, so a clean consumer environment may lack PyYAML. Not new (the gate has always parsed YAML), but reachable now that an installed /pr-review can dispatch. The failure is clean, never a criterion failure: exit 2, PyYAML is required to parse the completion-gate config, and the path of the interpreter that failed. Install into THAT interpreter. The invocation below uses uv run python, so the environment is the consumer project's and uv run --with pyyaml python ... is the form that works; a bare pip install pyyaml can modify an environment the next run never consults, leaving the failure unchanged.

Three limits, because the widening is narrow. The $repo_root/.claude fallback in the list below gets NO such treatment even if a plugin-root variable points at it: that path is written by the checked-out PR and keeps the full trust check. Only the config ORIGIN widens; the commands the config names are still verified against the trusted ref, so an install-trusted config cannot execute a PR-rewritten verifier script. And --trusted-ref is validated on this path like any other, including the requirement that it resolve to a remote-tracking ref: HEAD and local branches can be moved by the checked-out PR, so they cannot anchor trust and are refused.