Create structured pull requests following engineering best practices

PR Writer provides a GitHub CLI workflow for creating pull requests following Sentry engineering practices. It turns a committed branch diff into a description that explains the change, its purpose and the context a reviewer needs. Repository templates and mandatory checklists take precedence over the fallback writing structure.

The workflow covers preparation, branch inspection, drafting, creation and subsequent edits. Its example descriptions illustrate a feature, a null-handling bug fix and a shared-validation refactor; these examples are writing patterns rather than claims about the user's repository.

Use it when a branch is ready for a pull request and you need a repeatable way to describe the committed work. Keep one feature or fix in a reviewable PR, and use a draft for work in progress. Do not bundle unrelated changes just because they are present in the working tree.

Before creation, ensure the intended changes are committed and reviewed. Preserve unrelated dirty or staged files, and prepare only the authorized diff through the repository's normal workflow. A missing commit skill does not prevent ordinary authorized Git work. Clarify missing inputs, permissions, boundaries or success criteria before proceeding.

The inputs are the intended committed changes, the repository's base branch, its local PR requirements and any relevant issues or tickets. Detect the default branch rather than assuming its name. Inspect status, commit history and the full branch diff; confirm the branch is current with its remote and rebase on the base when needed.

One of the inspection commands is:

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

The description should explain what changed and why, relevant alternatives, non-obvious context and areas requiring careful review. Avoid repetitive test sections, duplicated checkboxes and a second summary of the diff unless policy requires them. Report completed validation, material pending checks and failures even when a shorter style is preferred.

Use a conventional title describing the feature, fix or refactor. Issue references distinguish an intended closing relationship from a non-closing link. Verify the upstream base, fork head and full committed SHA, then re-read the created PR to confirm its target and content.

GitHub CLI must be installed and authenticated. Creation uses a draft PR with the prepared title and body. Existing titles and descriptions can be updated through an API patch. Historical Projects-classic errors do not establish that the installed editing command is currently broken; use actual capability and error evidence when choosing the edit path.

This skill suits developers preparing changes for review who can inspect Git history and supply repository-specific context. The written PR complements environment-specific testing and expert review; it cannot replace either.