pr-creation

Format GitHub pull request descriptions with reviewer-oriented, outcome-based content.

1|Updated Apr 18, 2026

Search Tags:#code review #documentation #pull request #verification #GitHub #engineering standards

Ready to run

npx skills add https://github.com/nushey/sdd-flow --skill pr-creation-nushey

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: pr-creation
Source: https://github.com/nushey/sdd-flow/tree/main/skills/pr-creation
Command: npx skills add https://github.com/nushey/sdd-flow --skill pr-creation-nushey

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill standardizes pull request writing so the verifier phase produces PRs that are clear, value-oriented, and easy for reviewers to assess quickly.

Core Features & Use Cases

Reviewer-first structure: enforces a consistent PR body that leads with user/system impact before technical minutiae.
Concise, risk-aware technical bullets: includes technical detail only when it affects correctness, risk, or future implications.
SDD-aligned tone and scope: prevents noise like task IDs, commit hashes, spec paths, and test-plan checklists so reviewers focus on outcomes.

Quick Start

Use the pr-creation skill to generate a GitHub Pull Request description for a completed SDD verification phase.

Frequently Asked Questions about pr-creation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I write a pull request description that puts the reviewer first?▼

A reviewer-first pull request description leads with user and system impact before technical details, enforcing a consistent body structure so reviewers can assess outcomes quickly without parsing noise like task IDs or commit hashes.

What should I exclude from a GitHub PR description to improve code review clarity?▼

To improve code review clarity, exclude irrelevant internal artifacts from your PR description such as task IDs, commit hashes, spec paths, and test-plan checklists, focusing reviewer attention strictly on outcome-based changes and risk-aware technical bullets.

Can I use this structured PR format for both feature work and bug fixes?▼

Yes, this structured PR format applies to both feature work and fixes during the verification phase, standardizing the description to ensure clear reviewability whenever a completed task requires a GitHub pull request assessment.

What is the best way to format technical details in a pull request without overwhelming reviewers?▼

The best way to format technical details is using concise, risk-aware bullets that include technical minutiae only when it affects correctness, risk, or future implications, preventing noise so reviewers can focus strictly on the value and outcomes delivered.

When do I need a standardized PR description during the SDD verification phase?▼

You need a standardized PR description during the SDD verification phase when completing feature work or fixes that require clear reviewability, ensuring the generated GitHub pull request content is value-oriented and easy for reviewers to assess.