Loading

pr-report skill | PlugMCP

Skip to content

Directory Skills Categories Blog

Sign in Sign up

Home/Skills/pr-report

pr-report

P

by paperclipai103k

Autonomous AgentsProject Management

>

Install

The skill file stays in the publisher's repository.

Paste the copied command in a terminal. It installs this SKILL.md into that agent.

npx skills add paperclipai/paperclip --skill pr-report -a cursor -y

Download skill .agents/skills/pr-report/SKILL.md on GitHub

Related skills

P
paperclipThe open-source app everyone uses to manage agents at work
P
paperclip-task-bridgeCreate, comment on, update, and list Paperclip tasks from Hermes using scoped Paperclip API credentials.
A
add-product-e2e-evalAdd or extend a Paperclip full-stack runner E2E workflow, fixture, matcher, or report evidence path for local or Daytona execution.

Questions

How do I install pr-report?: Download .agents/skills/pr-report/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does pr-report live?: The publisher keeps it at https://github.com/paperclipai/paperclip.
Which agents can use pr-report?: Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.

>

name: pr-report 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.

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"

Plug any tool into any agent. MCP servers for people who do not write servers. Gateway for volume, n8n for apps.

github.com/TODO
x.com/TODO
linkedin.com/company/TODO

PlugMCP, 2026

Product

Browse
Install
Host your own
Pricing
Voice mode
Browser

Directory

All MCP servers
MCP Apps
Tools
Agent skills
Categories
New
Voice
Submit a server

Developers

Docs
Blog
Club
Work with us
What is MCP
What is WebMCP
Status

Company

About
Contact
Terms
Privacy
DPA

"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:

behavioral regressions
trust or security gaps
misleading abstractions
lifecycle and operational risks
coupling that will be hard to unwind
missing tests or unverifiable claims

Always cite concrete file references when possible.

4. Distinguish the objection type

Be explicit about whether a concern is:

product direction
architecture
implementation quality
rollout strategy
documentation honesty

Do not hide an architectural objection inside a scope objection.

5. Compare to external precedents when needed

If the contribution introduces a framework or platform concept, compare it to similar open-source systems.

When comparing:

prefer official docs or source
focus on extension boundaries, context passing, trust model, and UI ownership
extract lessons, not just similarities

Good comparison questions:

Who owns lifecycle?
Who owns UI composition?
Is context explicit or ambient?
Are plugins trusted code or sandboxed code?
Are extension points named and typed?

6. Make the recommendation actionable

Do not stop at "merge" or "do not merge."

Choose one:

merge as-is
merge after specific redesign
salvage specific pieces
keep as design research

If rejecting or narrowing, say what should be kept.

Useful recommendation buckets:

keep the protocol/type model
redesign the UI boundary
narrow the initial surface area
defer third-party execution
ship a host-owned extension-point model first

7. Build the artifact

Suggested report structure:

Executive summary
What the PR actually adds
Tutorial: how the system works
Strengths
Main findings
Comparisons
Recommendation

For HTML reports:

use intentional typography and color
make navigation easy for long reports
favor strong section headings and small reference labels
avoid generic dashboard styling

Before building from scratch, read references/style-guide.md. If a fast polished starter is helpful, begin from assets/html-report-starter.html and replace the placeholder content with the actual report.

8. Verify before handoff

Check:

artifact path exists
findings still match the actual code
any requested forbidden strings are absent from generated output
if tests were not run, say so explicitly

Review Heuristics

Plugin and platform work

Watch closely for:

docs claiming sandboxing while runtime executes trusted host processes
module-global state used to smuggle React context
hidden dependence on render order
plugins reaching into host internals instead of using explicit APIs
"capabilities" that are really policy labels on top of fully trusted code

Good signs

typed contracts shared across layers
explicit extension points
host-owned lifecycle
honest trust model
narrow first rollout with room to grow

Final Response

In chat, summarize:

where the report is
your overall call
the top one or two reasons
whether verification or tests were skipped

Keep the chat summary shorter than the report itself.

How do I install pr-report?: Download .agents/skills/pr-report/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does pr-report live?: The publisher keeps it at https://github.com/paperclipai/paperclip.
Which agents can use pr-report?: Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.