skills.rest
nushey
nusheyCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

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
One-click install
npx skills add https://github.com/nushey/sdd-flow --skill pr-creation-nushey
Or copy as Structured Prompt for Agent▼
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.

Related Skills

Explore More Content & Communication Skills→
yknothingyknothing
1

delivery-completion

Generate a delivery-decision-record after validating verification evidence.

Community
Advanced
Fandry96Fandry96
27

create-pr

Create GitHub pull requests following Sentry engineering practices.

Community
Advanced
BrennonTWilliamsBrennonTWilliams
7

ll-check-code

Execute linting, formatting, and type checking on project code.

Community
Basic
7a336e6e7a336e6e
1

git-workflow

Enforce standardized Git branching, commit messages, and pull request templates.

Community
Intermediate