pr-explainer
PR Explainer
Brief the developer on what changed, how the affected workflow behaves, and which assumptions to update. Explain published code, not the author's account of it. For a stack, explain the combined functional outcome first and attribute each PR's contribution second.
Scope and boundaries
| Request | Scope / route |
|---|---|
| Explain a PR URL or repository-qualified number | That published PR; inherited changes are context, not new work |
| Explain what you just pushed / this branch | Discover the unique hosted PR from verified branch/tracking context; never substitute local HEAD |
| Explain a whole stack | Explicit selection or verified membership; one combined briefing with per-PR attribution |
| Explain one stack member | Only its incremental contribution, with enough prerequisite context |
| Find defects / review my PR | pr-review, not this briefing |
| Approve, merge or restack | The applicable landing/shipping workflow, not this skill |
| Write a PR description / teach the entire repository | The applicable authoring skill / repo-tutor |
Support GitHub through available read-only provider tools or gh, and immutable source/history reads. Missing authentication, source or topology is a visible partial/blocked result, never invented evidence. Offline packet import and unpushed/local-only diff explanation are outside this skill.
Authority: read target/provider state only. Never run target code, tests, builds, installs or notebooks; push, merge, rebase, retarget, restack, post comments, edit settings, update memory/glossaries or register a worktree. Do not invoke a mutation workflow to inspect a stack. A requested runtime verification is a separate task.