pr-description

PR Descriptions

Write HoloViz PR descriptions in the HoloViz voice from the Before drafting section of the deslop skill: first person, as work you did.

Follow the repo's PR template rather than inventing sections. Every HoloViz repo inherits it from the org-wide holoviz/.github repo, so fetch the current, authoritative sections from the raw template and fill each one in:

https://raw.githubusercontent.com/holoviz/.github/refs/heads/main/.github/pull_request_template.md

The template carries HTML comments with instructions for each section. Read them, then delete them.

Contents

• Writing each part well
• Voice and style

Writing each part well

The template's sections are authoritative; fetch them rather than working from the bullets below, which cover how to fill a section well, not which sections exist. The title is a separate PR field, not a template section.

• Title: conventional-commit style (fix:, feat:, docs:, chore:) summarizing the change in one line.
• Description: summarize the change and its motivation in your own words, say which issue it fixes, describe the tests you ran to verify it, and include a copy-pastable minimal reproducible example. Write the example per the minimal-example skill so a reviewer can paste and run it unchanged. Add visuals for any observable or visual change (behavior, UI, plotting, rendered docs) as screenshots, GIFs, or video, labelled old versus new; skip them when there is nothing to compare, such as docs or refactors. Flag any breaking change, API change, new dependency, or migration step prominently so a reviewer cannot miss it.
• Fixes #{issue}: replace the placeholder with the issue number, or delete the line when the PR fixes no filed issue. Leaving #{issue} in place renders literally.
• AI Disclosure: delete the section only if AI was not used. Otherwise name the tool and model on Tool & Model: (for example Claude Code + Opus 4.6), say briefly on Usage: what it did, and leave both checkboxes for the author to tick, since they are statements about the author's own testing and responsibility. Non-disclosure can result in a ban.
• Checklist: keep the items that apply and remove the rest. "Tests added and are passing" stays unticked until the tests exist and pass, and per the testing skill a new test must fail on main first. "Added documentation" stays when the PR adds or changes user-facing behavior, since the documentation skill requires docs for it, and goes otherwise.