pr-description-writer
The pr-description-writer skill generates structured pull request descriptions from git diffs, commit logs, or change summaries. Use it when creating PR documentation to ensure reviewers receive clear context about what changed, why it matters, how to test it, and what requires special attention during review.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/pr-description-writer && cp -r /tmp/pr-description-writer/plugins/pm-engineering/skills/pr-description-writer ~/.claude/skills/pr-description-writerSKILL.md
# PR Description Writer Skill Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately. ## Required Inputs Ask for these if not provided: - **What changed** (paste a git diff, `git log --oneline`, or describe the changes in plain English) - **Why it was changed** (the problem being solved or feature being added) - **How to test it** (any specific steps a reviewer needs to verify it works) - **Risk level** (low / medium / high — affects how much reviewer guidance to include) - **PR type** (feature / bug fix / refactor / dependency upgrade / config change / hotfix) - **Target branch** (e.g. main / develop / release/2.4 — affects risk framing and reviewer guidance) - **Linked issue or ticket** (e.g. JIRA-1234, GitHub #567 — or "none") ## Output Format ### Title A clear, imperative-mood title under 72 characters: `[type]: [concise description of what changed]` Examples: - `feat: add rate limiting to the public API` - `fix: resolve race condition in session expiry` - `refactor: extract payment logic into PaymentService` ### Summary 2–3 sentences covering: - What this PR does (the change) - Why it was needed (the problem or goal) - The approach taken (at a high level) ### Changes Made Bullet list of specific changes — one bullet per logical change, not per file: - Added [X] to handle [Y] - Refactored [A] to reduce [B] - Removed [C] as it was replaced by [D] - Updated [E] to fix [F] ### Screenshots / Demo [If UI change: include before/after screenshots or a screen recording] [If API change: include example request/response] [If no visual change and no API contract change: omit this section entirely — do not leave it as a placeholder] ### How to Test Step-by-step instructions a reviewer can follow: 1. [Setup step if needed] 2. [Action to take] 3. [What to verify] 4. [Edge case to check] Include any specific commands, test data, or environment flags needed. ### Testing Checklist - [ ] Unit tests added/updated - [ ] Integration tests added/updated - [ ] Edge cases covered - [ ] Manual testing completed - [ ] No regressions in existing tests ### Reviewer Notes Flag anything that warrants extra attention: - Areas of uncertainty where a second opinion is welcome - Deliberate trade-offs made (and why) - Out-of-scope items noticed but not addressed - Dependencies on other PRs (link them) ### Related - Closes #[issue number] (if applicable) - Related to #[PR/issue number] ## Quality Checks - [ ] Title is imperative mood and under 72 characters - [ ] Summary explains what AND why (not just what) - [ ] Changes list describes logical changes (not file-by-file changes) - [ ] Title starts with a valid type prefix (feat / fix / refactor / chore / deps / config / hotfix) and is under 72 characters - [ ] Testing steps are reproducible by someone unfamiliar with the code - [ ] For high-risk PRs, Reviewer Notes flags at least one specific area of concern or deliberate trade-off; for low-risk PRs, Reviewer Notes is either omitted or kept to one line ## Anti-Patterns - [ ] Do not write a description that only restates what changed — explain why the change was made - [ ] Do not skip the testing steps — reviewers need to know how to verify the change works - [ ] Do not omit the reviewer notes for high-risk PRs — flag deliberate trade-offs and areas needing careful review - [ ] Do not describe implementation details that are obvious from the diff — add context that the diff cannot convey - [ ] Do not produce a single paragraph — structure with headers so reviewers can navigate to what they need ## Usage Examples - "Write a PR description for these changes" + [paste diff or description] - "Draft a pull request for [feature]" - "I need a PR description — here's what I changed" - "Summarise these commits into a PR description" - "Write the PR body for this branch"
Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.