pr-report

Name: pr-report
Author: IncomeStreamSurfer

69stars33forks

How to install pr-report?

incomestreamsurfer/paperclip-surfers/pr-report

$npx -y skills add IncomeStreamSurfer/paperclip-surfers --skill pr-report

Installs into the current project.

Summary

Review a pull request or contribution deeply, explain it tutorial-style for a maintainer, and produce a polished report artifact such as HTML or Markdown. Use when asked to analyze a PR, explain a contributor's design decisions, compare it with similar systems, or prepare a merge

Files · 1

View on GitHub

SKILL.md

1	# PR Report Skill
2
3	Produce a maintainer-grade review of a PR, branch, or large contribution.
4
5	Default posture:
6
7	- understand the change before judging it
8	- explain the system as built, not just the diff
9	- separate architectural problems from product-scope objections
10	- make a concrete recommendation, not a vague impression
11
12	## When to Use
13
14	Use this skill when the user asks for things like:
15
16	- "review this PR deeply"
17	- "explain this contribution to me"
18	- "make me a report or webpage for this PR"
19	- "compare this design to similar systems"
20	- "should I merge this?"
21
22	## Outputs
23
24	Common outputs:
25
26	- standalone HTML report in `tmp/reports/...`
27	- Markdown report in `report/` or another requested folder
28	- short maintainer summary in chat
29
30	If the user asks for a webpage, build a polished standalone HTML artifact with
31	clear sections and readable visual hierarchy.
32
33	Resources bundled with this skill:
34
35	- `references/style-guide.md` for visual direction and report presentation rules
36	- `assets/html-report-starter.html` for a reusable standalone HTML/CSS starter
37
38	## Workflow
39
40	### 1. Acquire and frame the target
41
42	Work from local code when possible, not just the GitHub PR page.
43
44	Gather:
45
46	- target branch or worktree
47	- diff size and changed subsystems
48	- relevant repo docs, specs, and invariants
49	- contributor intent if it is documented in PR text or design docs
50
51	Start by answering: what is this change trying to become?
52
53	### 2. Build a mental model of the system
54
55	Do not stop at file-by-file notes. Reconstruct the design:
56
57	- what new runtime or contract exists
58	- which layers changed: db, shared types, server, UI, CLI, docs
59	- lifecycle: install, startup, execution, UI, failure, disablement
60	- trust boundary: what code runs where, under what authority
61
62	For large contributions, include a tutorial-style section that teaches the
63	system from first principles.
64
65	### 3. Review like a maintainer
66
67	Findings come first. Order by severity.
68
69	Prioritize:
70
71	- behavioral regressions
72	- trust or security gaps
73	- misleading abstractions
74	- lifecycle and operational risks
75	- coupling that will be hard to unwind
76	- missing tests or unverifiable claims
77
78	Always cite concrete file references when possible.
79
80	### 4. Distinguish the objection type
81
82	Be explicit about whether a concern is:
83
84	- product direction
85	- architecture
86	- implementation quality
87	- rollout strategy
88	- documentation honesty
89
90	Do not hide an architectural objection inside a scope objection.
91
92	### 5. Compare to external precedents when needed
93
94	If the contribution introduces a framework or platform concept, compare it to
95	similar open-source systems.
96
97	When comparing:
98
99	- prefer official docs or source
100	- focus on extension boundaries, context passing, trust model, and UI ownership
101	- extract lessons, not just similarities
102
103	Good comparison questions:
104
105	- Who owns lifecycle?
106	- Who owns UI composition?
107	- Is context explicit or ambient?
108	- Are plugins trusted code or sandboxed code?
109	- Are extension points named and typed?
110
111	### 6. Make the recommendation actionable
112
113	Do not stop at "merge" or "do not merge."
114
115	Choose one:
116
117	- merge as-is
118	- merge after specific redesign
119	- salvage specific pieces
120	- keep as design research
121
122	If rejecting or narrowing, say what should be kept.
123
124	Useful recommendation buckets:
125
126	- keep the protocol/type model
127	- redesign the UI boundary
128	- narrow the initial surface area
129	- defer third-party execution
130	- ship a host-owned extension-point model first
131
132	### 7. Build the artifact
133
134	Suggested report structure:
135
136	1. Executive summary
137	2. What the PR actually adds
138	3. Tutorial: how the system works
139	4. Strengths
140	5. Main findings
141	6. Comparisons
142	7. Recommendation
143
144	For HTML reports:
145
146	- use intentional typography and color
147	- make navigation easy for long reports
148	- favor strong section headings and small reference labels
149	- avoid generic dashboard styling
150
151	Before building from scratch, read `references/style-guide.md`.
152	If a fast polished starter is helpful, begin from `assets/html-report-starter.html`
153	and replace the placeholder content with the actual report.
154
155	### 8. Verify before handoff
156
157	Check:
158
159	- artifact path exists
160	- findings still match the actual code
161	- any requested forbidden strings are absent from generated output
162	- if tests were not run, say so explicitly
163
164	## Review Heuristics
165
166	### Plugin and platform work
167
168	Watch closely for:
169
170	- docs claiming sandboxing while runtime executes trusted host processes
171	- module-global state used to smuggle React context
172	- hidden dependence on render order
173	- plugins reaching into host internals instead of using explicit APIs
174	- "capabilities" that are really policy labels on top of fully trusted code
175
176	### Good signs
177
178	- typed contracts s

People who liked this also viewed

6 picks

Type

pr-report

69stars33forks

View on GitHub

How to install pr-report?

incomestreamsurfer/paperclip-surfers/pr-report

$npx -y skills add IncomeStreamSurfer/paperclip-surfers --skill pr-report

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# PR Report Skill
2
3	Produce a maintainer-grade review of a PR, branch, or large contribution.
4
5	Default posture:
6
7	- understand the change before judging it
8	- explain the system as built, not just the diff
9	- separate architectural problems from product-scope objections
10	- make a concrete recommendation, not a vague impression
11
12	## When to Use
13
14	Use this skill when the user asks for things like:
15
16	- "review this PR deeply"
17	- "explain this contribution to me"
18	- "make me a report or webpage for this PR"
19	- "compare this design to similar systems"
20	- "should I merge this?"
21
22	## Outputs
23
24	Common outputs:
25
26	- standalone HTML report in `tmp/reports/...`
27	- Markdown report in `report/` or another requested folder
28	- short maintainer summary in chat
29
30	If the user asks for a webpage, build a polished standalone HTML artifact with
31	clear sections and readable visual hierarchy.
32
33	Resources bundled with this skill:
34
35	- `references/style-guide.md` for visual direction and report presentation rules
36	- `assets/html-report-starter.html` for a reusable standalone HTML/CSS starter
37
38	## Workflow
39
40	### 1. Acquire and frame the target
41
42	Work from local code when possible, not just the GitHub PR page.
43
44	Gather:
45
46	- target branch or worktree
47	- diff size and changed subsystems
48	- relevant repo docs, specs, and invariants
49	- contributor intent if it is documented in PR text or design docs
50
51	Start by answering: what is this change trying to become?
52
53	### 2. Build a mental model of the system
54
55	Do not stop at file-by-file notes. Reconstruct the design:
56
57	- what new runtime or contract exists
58	- which layers changed: db, shared types, server, UI, CLI, docs
59	- lifecycle: install, startup, execution, UI, failure, disablement
60	- trust boundary: what code runs where, under what authority
61
62	For large contributions, include a tutorial-style section that teaches the
63	system from first principles.
64
65	### 3. Review like a maintainer
66
67	Findings come first. Order by severity.
68
69	Prioritize:
70
71	- behavioral regressions
72	- trust or security gaps
73	- misleading abstractions
74	- lifecycle and operational risks
75	- coupling that will be hard to unwind
76	- missing tests or unverifiable claims
77
78	Always cite concrete file references when possible.
79
80	### 4. Distinguish the objection type
81
82	Be explicit about whether a concern is:
83
84	- product direction
85	- architecture
86	- implementation quality
87	- rollout strategy
88	- documentation honesty
89
90	Do not hide an architectural objection inside a scope objection.
91
92	### 5. Compare to external precedents when needed
93
94	If the contribution introduces a framework or platform concept, compare it to
95	similar open-source systems.
96
97	When comparing:
98
99	- prefer official docs or source
100	- focus on extension boundaries, context passing, trust model, and UI ownership
101	- extract lessons, not just similarities
102
103	Good comparison questions:
104
105	- Who owns lifecycle?
106	- Who owns UI composition?
107	- Is context explicit or ambient?
108	- Are plugins trusted code or sandboxed code?
109	- Are extension points named and typed?
110
111	### 6. Make the recommendation actionable
112
113	Do not stop at "merge" or "do not merge."
114
115	Choose one:
116
117	- merge as-is
118	- merge after specific redesign
119	- salvage specific pieces
120	- keep as design research
121
122	If rejecting or narrowing, say what should be kept.
123
124	Useful recommendation buckets:
125
126	- keep the protocol/type model
127	- redesign the UI boundary
128	- narrow the initial surface area
129	- defer third-party execution
130	- ship a host-owned extension-point model first
131
132	### 7. Build the artifact
133
134	Suggested report structure:
135
136	1. Executive summary
137	2. What the PR actually adds
138	3. Tutorial: how the system works
139	4. Strengths
140	5. Main findings
141	6. Comparisons
142	7. Recommendation
143
144	For HTML reports:
145
146	- use intentional typography and color
147	- make navigation easy for long reports
148	- favor strong section headings and small reference labels
149	- avoid generic dashboard styling
150
151	Before building from scratch, read `references/style-guide.md`.
152	If a fast polished starter is helpful, begin from `assets/html-report-starter.html`
153	and replace the placeholder content with the actual report.
154
155	### 8. Verify before handoff
156
157	Check:
158
159	- artifact path exists
160	- findings still match the actual code
161	- any requested forbidden strings are absent from generated output
162	- if tests were not run, say so explicitly
163
164	## Review Heuristics
165
166	### Plugin and platform work
167
168	Watch closely for:
169
170	- docs claiming sandboxing while runtime executes trusted host processes
171	- module-global state used to smuggle React context
172	- hidden dependence on render order
173	- plugins reaching into host internals instead of using explicit APIs
174	- "capabilities" that are really policy labels on top of fully trusted code
175
176	### Good signs
177
178	- typed contracts s

People who liked this also viewed

6 picks

Type