Feature GitHub Publication and Authorization

Feature: GitHub Publication & Review Authorization

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

Controls what github-pr-review publishes to a PR and under what authority. Review analysis is always separate from GitHub mutation authority: the review always runs and produces a mechanically derived verdict; whether that verdict is submitted to GitHub is governed by one canonical publication mode — PASSIVE / SEMI / ACTIVE.

Publication mode	What gets published
PASSIVE (default)	Nothing — a report is returned to you
SEMI	Nothing to GitHub — a preview of the exact ACTIVE outcome
ACTIVE, self-review	Informational COMMENT + a disclosure line; no formal event
ACTIVE, external, clean	APPROVE (needs reviewer independence + GitHub permission)
ACTIVE, external, blocking	REQUEST_CHANGES (needs reviewer independence + GitHub permission)

Why it exists

Publishing to someone else's PR is the highest-stakes action either Skill can take. Splitting "did the review find anything" from "should anything be written to GitHub" lets the review run safely by default, and makes publication an explicit, narrowly-scoped, always-auditable decision rather than an implicit side effect of asking for a review.

When it applies

github-pr-review only — local-code-review never publishes to GitHub, even when given a PR reference. Default is PASSIVE. An explicit ACTIVE request is, by itself, sufficient authorization to publish that review's own outcome — there is no second activation phrase — but it still requires reviewer independence, GitHub event permission, and a current (revalidated) reviewed HEAD. Self-review is allowed; formal APPROVE / REQUEST_CHANGES is never submitted on the reviewer's own work in any mode. Ambiguity always fails closed to non-mutating.

How it works

An active review publishes as one batched submission (body + inline comments + event); an optional machine-readable status/check for the reviewed SHA, when requested, publishes before that submission — nothing review-owned is published after it. A blocking status may be published even by a self-review; a success status needs the same ACTIVE + independence guarantees as APPROVE. Immediately before that submission, a read-only check re-verifies the APPROVE/REQUEST_CHANGES event about to go out still matches the mechanically-derived decision — see Severity-and-Decision-Model — and withholds submission on a mismatch rather than publishing it.

Important options / modes

• Natural language sets the mode — "just review and tell me what you find" (PASSIVE), "tell me what would happen, but don't touch GitHub" (SEMI), "approve if clean, request changes if blocking" (ACTIVE).
• The optional machine-readable status/check, and making it a required check, are separate, explicitly requested actions — never implied by choosing ACTIVE.

Example

review #812; approve if it's clean, request changes if there are
blocking issues

Limitations & safety boundaries

Maximum positive action is Approve / a success status — this Skill never merges, enables auto-merge, or deletes branches, and never changes approval-count rules, stale-review settings, or bypass actors on branch protection.

Inline comments anchor at the fix/action location — the line an author must change — not merely where a problem is observable. A finding whose fix/action location is outside the PR diff or not inline-commentable is surfaced at review-summary level with an explicit path and remediation, never attached to an unrelated nearby line; where a finding is published never affects its identity or the decision (see finding-placement.md).

Related features

• Feature-Delta-Re-Review — HEAD-freshness rules that gate publication after a re-review.
• Feature-Human-Style-Review-Output — presentation of the same published verdict; never changes what gets published or to whom.
• Feature-GitHub-Merge-Enforcement — making the published status a required merge check, only on your explicit request.

Canonical references

• Usage guide: docs/features/github-review-publication.md
• Canonical semantics: skills/github-pr-review/policies/review-action-authorization.md, review-output.md, review-status-enforcement.md
• Skill guide: GitHub-PR-Review-Guide