create-pr

Create a PR

Before opening the PR, run the merge-risk skill and mitigate the risks it finds, where possible without changing the PR's core functionality.

Run the changelog skill before or right after opening the PR.

Use .github/pull_request_template.md for the PR body. Skip preambles and keep prose brief.

Fill each section's Verdict: line with the verdict merge-risk gave its category after mitigation, emoji included: Verification → Verification, Impact → Impact, Rollback → Rollback cost (e.g. **Verdict:** low ✅).

For the Summary, pick the smallest view that makes the key point clear, and place it next to the short text it supports:

• pseudocode for logic or an algorithm
• a call tree for runtime control flow
• a component tree for UI structure, with the state and module boundaries that matter
• a shallow file tree for file responsibility or a broad refactor
• Mermaid for component interaction, control flow, or data flow
• a diff of any of the above when the point is what changes and the surrounding shape already exists
• the whole block when most of it is new, when omitted context would hide ownership or order, or when the reviewer needs a copyable target shape

Keep only the calls, files, props, states, and boundaries a reviewer needs. You may use one of these or several, but rarely all of them. Don't overwhelm the reviewer.

After opening the PR, tell the user if a stacked PR strategy could reduce blast radius or improve reviews.