pr-report

Topics in the source

• PR Report Skill
• When to Use
• Outputs
• Workflow
• 1. Acquire and frame the target
• 2. Build a mental model of the system
• 3. Review like a maintainer
• 4. Distinguish the objection type

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 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?" 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 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 desig

This is an excerpt. Refer to the complete source and its current requirements.