omamail: Skill for Codex

Review PRs

Accept optional PR numbers, URLs, or a repository/queue filter. Examples: $review-prs 42 57, $review-prs https://github.com/owner/repo/pull/42, or $review-prs review all open non-draft PRs in this repository.

Primary purpose: product necessity and design

The maintainer primarily reviews PRs to decide whether their new or adjusted capabilities are necessary to introduce and whether the design is appropriate. Lead every PR report with what it changes and the problem it aims to solve, including passing PRs and PRs skipped as already reviewed, superseded or closed. Do not reduce the report to a technical verdict.

For each change, assess fit with established project goals, who benefits, overlap with existing behavior, simpler alternatives, and interface and maintenance cost. Recommend introducing it, deferring it, or leaving it out, with a concrete reason. Evaluate adjusted workflows as well as entirely new features; restoring an established behavior may be a necessary fix, but its design still needs review. The maintainer owns the product decision.

Assess product and interaction design separately from implementation quality: workflow and scope, discoverability, defaults, information hierarchy, consistency, keyboard and focus behavior, and loading, empty, error and cancellation states. For non-UI changes, assess the affected command, configuration or integration workflow. Explain material tradeoffs and distinguish observed design evidence from inference; missing screenshots or hands-on evidence limit the design verdict.

Technical completeness, tests, performance and security support the product and design decision and remain required approval gates. Passing checks does not by itself justify introducing a capability. Keep product recommendations, design findings and technical blockers distinct.

Scope and authority

• Resolve the repository from explicit arguments or the current checkout. If that is ambiguous, ask only for the repository. With explicit PR numbers or URLs, review only those PRs, deduplicated and in supplied order; never add other candidates. Without PR targets, inspect open PRs and their review/discussion history, order by creation time oldest to newest, and select at most the oldest three open non-draft PRs needing review or re-review. A PR needing re-review has a new head or an explicit re-review request since the prior completed review; skip unchanged PRs already reviewed by this reviewer and explain the skip. Paginate listings/history before selection so an API page does not silently omit older PRs.
• Keep each review batch to at most three PRs, and still process them one at a time. If explicit targets exceed three, split only those targets into successive batches of at most three and finish one batch before starting the next. Without explicit targets, stop after the selected batch of at most three and report remaining candidates; do not drain the queue automatically. Read each selected PR's previous findings, author responses and revisions to distinguish first review from re-review.
• Explicitly invoking this workflow authorizes dedicated worktrees, investigation and validation, PR title/body edits, and publishing passing reviews on the selected PRs. For PRs with actionable findings, first complete the review and ask the user to choose helping fix them or submitting Request Changes, as defined below. Fixes, fix commits/pushes and Request Changes publication require that decision; explicit session authorization for a specific choice satisfies it. A request for a read-only review or draft overrides these defaults. Automatic skill selection alone grants no authority to publish, push, or edit GitHub; use existing session authorization or prepare the complete result before asking for missing approval.
• Do not merge, enable auto-merge, force-push, change branch protection, or dismiss other reviewers' decisions without separate explicit authorization. Do not ask again for actions already authorized.