{"id":"2774f923-38f7-4f10-a0e4-497f1b31afa4","slug":"pr-writer","kind":"skill","name":"pr-writer","summary":"Create or refresh reviewer-facing PR titles and descriptions. Use when opening a PR, updating its title or body, or preparing branch changes for review.","owner":"getsentry","repoUrl":"https://github.com/getsentry/skills/tree/HEAD/skills/pr-writer","license":"Apache-2.0","licenseTier":"permissive","trust":"official","stars":1050,"match":null,"fewStars":false,"format":"skill","createdAt":null,"addedAt":"2026-10-14T05:59:32.138Z","logoUrl":"https://avatars.githubusercontent.com/u/1396951?v=4","linkOnly":false,"collection":{"name":"skills","repo":"getsentry/skills"},"skillPath":"skills/pr-writer","categories":["writing"],"tags":["tag-production"],"runtime":"binary","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-14T05:59:32.137Z","sample":false,"url":"https://conduits.dev/tools/pr-writer","language":"Python","transports":[],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# PR Writer\n\nWrite the PR body as a cover note for reviewers, not a changelog, template,\nvalidation log, or file-by-file summary.\n\n## Inspect the Change\n\nRequires authenticated `gh`. Inspect the current branch, working tree, PR,\nbase branch, commits, and full diff:\n\n```bash\ngit branch --show-current\ngit status --porcelain\ngh pr view --json number,title,body,url,baseRefName,headRefName\ngh repo view --json defaultBranchRef\n```\n\nIf `gh pr view` reports that no PR exists, continue with first-time PR\ncreation. For an existing PR, use its `baseRefName`; otherwise use the\nrepository default branch. Set `BASE`, then inspect:\n\n```bash\ngit log \"$BASE\"..HEAD --oneline\ngit diff \"$BASE\"...HEAD\n```\n\nIf on `main` or `master`, create a feature branch first. Ensure intended\nchanges are committed and review the whole branch diff, not only the latest\ncommit or existing PR text.\n\n## Core Rules\n\n- Describe concrete changed behavior, affected surfaces, and reviewer impact\n  before implementation detail.\n- Explain motivation, risk, tradeoffs, migration, or review focus only when\n  useful.\n- Use the smallest structure that makes the change easier to review.\n- Replace internal prompt or process terminology with specific behavior.\n- When refreshing a PR, rewrite around the current full diff without narrating\n  review history.\n\n## Titles\n\nUse `<type>(<scope>): <subject>` or `<type>: <subject>`.\n\nAllowed types: `feat`, `fix`, `ref`, `perf`, `docs`, `test`, `build`,\n`ci`, `chore`, `style`, `meta`, `license`, and `revert`.\n\n- Describe the dominant full-branch change with the narrowest accurate type\n  and scope.\n- Use `!` only when the change breaks an external contract, and explain the\n  affected surface in the body.\n- Avoid vague subjects such as `update`, `cleanup`, `misc`, `fix stuff`,\n  or `address feedback`. Do not add a trailing period.\n- Keep an existing title only when it still describes the whole diff.\n\n## Body Shape\n\nChoose the minimum useful shape:\n\n| Change | Include |\n|--------|---------|\n| Small or obvious | One concise paragraph without headings. |\n| Feature, bug fix, or refactor | Changed behavior and effect; add root cause, unchanged behavior, or non-obvious approach when relevant. |\n| Contract or breaking change | Affected API, schema, payload, config, permission, storage, or CLI surface; include compatibility and migration guidance. |\n| Operational, visual, or workflow change | User/operator effect, measured impact, failure modes, or flow when useful. |\n| Broad, generated, or cross-cutting change | Organizing principle, why the breadth is necessary, and where review should start. |\n\nDefault:\n\n```markdown\n<What changed and what effect it has.>\n\n<Why the approach, risk, migration, or review focus matters, if not obvious.>\n```\n\nFor review-feedback updates, describe the resulting PR as a whole rather than\nthe sequence of revisions.\n\n## Reviewer Aids\n\nUse an aid only when it reduces reviewer reconstruction work:\n\n- A compact before/after or interface example for changed contracts.\n- A small Mermaid diagram for async flows or state transitions.\n- A screenshot or recording note when visual evidence exists.\n- A rollout, compatibility, risk, or review-order note when reviewers or\n  adopters need it.\n\nIntroduce an artifact with one sentence explaining what reviewers should\nnotice. Omit it when prose is clearer.\n\n## Boundaries\n\n- Do not add default `Summary`, `Changes`, or `Test Plan` sections.\n- Omit routine validation unless it changes risk assessment or explains\n  meaningful regression coverage. For docs, skills, copy, or config changes,\n  omit it by default.\n- Do not paste commands, CI logs, validation dumps, commit logs, placeholders,\n  or exhaustive file lists.\n- Never include customer or organization names, user emails, support ticket\n  contents, secrets, or PII.\n- Use issue references only when verified from user input, branch names,\n  commits, PR discussion, or tracker output. `Fixes <issue>` closes;\n  `Refs <issue>` only links.\n\n## Create or Update\n\nCreate new PRs as drafts. Write the body to a temporary Markdown file, then run:\n\n```bash\ngh pr create --draft --title '<title>' --body-file /tmp/pr-body.md\n```\n\nUpdate existing PRs with `gh api`:\n\n```bash\ngh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \\\n  -f title='<title>' \\\n  -F body=@/tmp/pr-body.md\n```\n\nRefresh the title and body when follow-up commits materially change scope,\napproach, breaking behavior, risk, migration, or review expectations. Skip\ntypo-only, formatting-only, and rename-only follow-ups.\n\n## Examples\n\nSmall change:\n\n```markdown\nThe AI Customizations section now starts collapsed so it does not consume\nsidebar space before users need it. Expanding it preserves the existing saved\npreference behavior.\n```\n\nBreaking contract:\n\n````markdown\nRun logs now emit chunk-level records instead of one skill-level record.\nConsumers that read top-level `findings` must iterate over\n`chunk.findings` for each record.\n\nBefore:\n\n```json\n{\"skill\": \"security-review\", \"findings\": [...]}\n```\n\nAfter:\n\n```json\n{\"schemaVersion\": 1, \"chunk\": {\"index\": 1, \"findings\": [...]}}\n```\n````"}