Support shared PR-review automations across repositories

Start by reading the cited entry points: packages/junior-github/src/webhooks/events.ts, packages/junior/src/chat/event-automations/types.ts, store.ts, ingest.ts, and agent/skills.ts. Trace current event matching, dispatch deduplication, and skill loading, then resolve the listed scope, lifecycle, concurrency, and permission decisions before implementation; done requires an approved plan that preserves per-PR progress and avoids duplicate or unauthorized reviews.

Make it easy to review PRs across many repositories without maintaining one Automation per repository or copying a long review prompt into each task. The motivating case is reviewing Sentry-generated PRs, checking their premises against failure evidence, and following useful changes through human merge readiness.

Goal and proposed direction

• One Automation covers an explicit set of repositories with the same owner and policy. Separate Automations remain appropriate when permissions, review rules, or destinations differ.
• Reuse a shared review procedure, potentially through an explicit skill selection. Improve that procedure once rather than update every task's instructions.
• Keep scope, author filters, credentials, allowed actions, and notification rules on the Automation. A skill describes how to review; it does not grant permission.
• Keep each PR's work separate: reviewed head, handled feedback, and result Conversation. Avoid duplicate reviews and ready notifications when events or scheduled runs overlap.
• Post GitHub reviews as Junior using installation identity. Never merge. Treat branch corrections as a separate permission from review.
• Preserve the motivating workflow's evidence standard: PR descriptions and generated diagnoses are claims, not proof. Verify decisive premises against failure evidence and producer/consumer contracts.
• Report newly ready PRs and permitted follow-ups without narrating every successful check. Recheck current head and required checks before reporting readiness.

This captures product direction, not an approved implementation plan. The earlier idea of adding a temporary Watch after each review does not by itself solve reusable multi-repository configuration.

Current Junior behavior

Source reviewed at b8025c2:

• GitHub already publishes PR events to both the PR and its repository: pullRequestTargets.
• An Event automation has one resource identifier and text instructions. Matching uses that exact identifier: schema, matching.
• Each event gets a dispatch keyed by Automation and event identity. Retry deduplication is not the same as remembering PR review progress across different events: ingestion.
• Skill loading already exists. A selected skill need not introduce a second execution system: loadRunSkill.

Competitive research

First-party documentation reviewed on 2026-09-28. These are documented capabilities, not hands-on comparisons or review-quality benchmarks.

Cursor Automations — closest general-purpose comparison

Docs describe one Automation with multiple triggers, instructions, optional tools, and zero, one, or multiple repositories. Source-control triggers include PR opening, pushes, merge, comments, reviews, and CI completion. Creator and service-account execution are separate choices. Help distinguishes a multi-repo execution environment from a single repository.

Relevant pattern: reusable task + repository scope + event selection + explicit capabilities. Multi-repo code access is not the same requirement as independently reviewing PRs across many repositories; Junior should make that distinction clear. The docs do not establish that Cursor maintains one continuing Conversation per PR.

GitHub Copilot code review — organization-wide scope

Configuration docs support organization rulesets with repository inclusion/exclusion patterns, plus separate draft and new-push review options. When user, repository, and organization rules overlap, Copilot still posts one review. Review docs support repository instructions and agent skills, but warn that re-reviews can repeat comments. Replies to review comments do not make Copilot respond.

Relevant pattern: broad policy scope with explicit lifecycle controls. Trigger deduplication and finding deduplication are distinct problems. Reusable skills are compatible with automated reviews, not a competing execution model.

CodeRabbit — shared policy with repository exceptions

Organization settings apply common configuration across repositories. Central configuration keeps shared settings in one dedicated repository. Configuration precedence separates defaults, repository configuration, optional inheritance, and enforced global overrides; configuration sources do not simply merge by default.

Relevant pattern: maintain review rules once, with clear precedence. A shared procedure and a mandatory safety restriction should not be treated as interchangeable settings.

Claude Code Review — managed review lifecycle

Docs describe organization setup with selected repositories and per-repository modes: once after PR creation, every push, or manual. @claude review always subscribes one PR to later pushes. CLAUDE.md and REVIEW.md customize reviews; push-triggered reviews can resolve fixed findings. Inline replies do not start a conversation with the reviewer. The service is documented as a research preview for Team and Enterprise.

Relevant pattern: make initial review and continuing review separate, visible choices. Keep per-PR progress and cost visibility distinct from organization setup.

Implications and open decisions

The common pattern is shared policy across repository scope, not hundreds of copied task definitions. The proposed Junior distinction is to combine a reusable review skill with task-scoped authority, live failure evidence, and useful PR follow-up context.

Still to decide: explicit repository lists versus patterns; skill update behavior; per-PR Conversation reuse; backfill for already-open PRs; missing head-change events; cancellation of queued work; and concurrency/cost limits. Broader event coverage must not increase permissions or create self-triggered review loops. Do not assume a successful check-suite event proves merge readiness.

Related: #1970 covers managing Automations at scale, including editor and lifecycle work. #435 proposes a separate GitHub-channel reactive behavior architecture; this issue records the user goal using the current Automation model and does not adopt that architecture.

via David Cramer.

--

View Junior Session [Sentry]