cached

PR review-and-update cycle — the orchestrator that takes a PR from review to resolved. It runs a local review (by delegating to the `pr-review` skill), fetches open GitHub review comments, evaluates all findings, applies valid fixes, runs CI, commits, pushes, resolves threads, and re-requests Copilot review. Supports three modes — `full` (default, everything), `local` (only the local-review-and-fix loop; no GitHub PR-conversation reads or mutations), and `remote` (only the GitHub PR feedback loop; no local review). The review sub-agents default to Sonnet but can be overridden per run (e.g. to opus). Use when asked to "run the pr cycle", "address pr comments", "resolve comments and re-request review", "review and fix the branch", "run the remote pr cycle", or after pushing a new round of changes. For a read-only review with no fixes/push, use `pr-review` instead.

Targeted, read-only review of a PR or checked-out branch. Acquires the diff (a PR number, or the current branch vs origin/master), shards the changed material into appropriately sized, randomized chunks, and spawns multiple read-only code-review and library-consumer sub-agents in parallel (one per shard), then aggregates and de-duplicates their findings into a single report with severity and a valid / already-fixed / invalid verdict for each. Read-only — it does not edit files, commit, push, or touch the GitHub PR conversation. The review sub-agents default to Sonnet but can be overridden per run (e.g. to opus). Use when asked to "review this PR", "review the branch", "what's wrong with this diff", "do a code review", or "review with opus". For the full review → fix → push → resolve loop, use `pr-cycle` (which delegates its review step here).

Review a library/package from the perspective of an external downstream consumer — build a throwaway crate/project that depends on it the way a real user would, exercise the public API, and surface gaps, inconsistencies, and inconveniences with compiler-verified evidence. Use when asked to "review the consumer/user experience", "find API gaps/inconsistencies", "evaluate the public API", "is this ready to publish/release", or before a 1.0 / major version bump. Especially valuable for breaking-change releases (the only non-breaking window to fix the public surface).

Prepare a release (bump versions across all Cargo.toml files, update CHANGELOG.md, refresh the migration guide, regenerate README, commit), or run a pre-release review. The `review` option kicks off a consistency review and an API-examination review to surface lingering inconsistencies and a categorized list of breaking and non-breaking improvements before you cut the release — advisory only, it changes nothing. Use when asked to "cut a release", "bump the version", "prepare a release", "release X.Y.Z", or "do a release review" / "review for release". Takes a version string (e.g. `/release 1.2.0`) or `review` as the argument.