# PR Report

Writes a maintainer-grade report on a pull request with a merge recommendation.

- Repository: https://github.com/paperclipai/paperclip (109885 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add paperclipai/paperclip --skill pr-report -g -a claude-code -y`
Codex: `npx skills add paperclipai/paperclip --skill pr-report -g -a codex -y`
Cursor: `npx skills add paperclipai/paperclip --skill pr-report -g -a cursor -y`
Gemini CLI: `npx skills add paperclipai/paperclip --skill pr-report -g -a gemini-cli -y`

## Description

Produce a maintainer-grade PR or contribution report as HTML or Markdown. Use when asked to deeply review a PR, explain a design, compare systems, or prepare a merge recommendation.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# PR Report Skill

Produce a maintainer-grade review of a PR, branch, or large contribution.

Default posture:

- understand the change before judging it
- explain the system as built, not just the diff
- separate architectural problems from product-scope objections
- make a concrete recommendation, not a vague impression

## When to Use

Use this skill when the user asks for things like:

- "review this PR deeply"
- "explain this contribution to me"
- "make me a report or webpage for this PR"
- "compare this design to similar systems"
- "should I merge this?"

## Outputs

Common outputs:

- standalone HTML report in `tmp/reports/...`
- Markdown report in `report/` or another requested folder
- short maintainer summary in chat

If the user asks for a webpage, build a polished standalone HTML artifact with
clear sections and readable visual hierarchy.

Resources bundled with this skill:

- `references/style-guide.md` for visual direction and report presentation rules
- `assets/html-report-starter.html` for a reusable standalone HTML/CSS starter

## Workflow

### 1. Acquire and frame the target

Work from local code when possible, not just the GitHub PR page.

Gather:

- target branch or worktree
- diff size and changed subsystems
- relevant repo docs, specs, and invariants
- contributor intent if it is documented in PR text or design docs

Start by answering: what is this change *trying* to become?

### 2. Build a mental model of the system

Do not stop at file-by-file notes. Reconstruct the design:

- what new runtime or contract exists
- which layers changed: db, shared types, server, UI, CLI, docs
- lifecycle: install, startup, execution, UI, failure, disablement
- trust boundary: what code runs where, under what authority

For large contributions, include a tutorial-style section that teaches the
system from first principles.

### 3. Review like a maintainer

Findings come first. Order by severity.

Prioritize:

The rest: https://github.com/paperclipai/paperclip/blob/HEAD/.agents/skills/pr-report/SKILL.md