pr-report

原文涵盖的主题

• 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

这里只展示节选，请以完整原文和当前要求为准。