open-supply-hub: Skill for Claude Code

Writing Good PR Descriptions

Based on Google's CL description guidelines.

A PR description is a public record of change. It must communicate:

1. What change is being made — summarize so readers understand without reading the entire diff.
2. Why these changes are being made — what context did the author have? What decisions aren't reflected in the code?

The description becomes a permanent part of version control history. Future developers will search for the PR based on its description. If all the important information is in the code and not the description, it will be much harder to locate. And even after finding it, they need to understand why the change was made — code reveals what the software does, but not why it exists.

IMPORTANT: THE DESCRIPTION SHOULD BE EASY TO READ AND CONCISE!!!

Required Structure

IMPORTANT: The PR body MUST follow the repository template at pull_request_template.md (repo root). Read that file first — it is the single source of truth. If it has changed, follow the file, not the outline below.

Reproduce every section, in order, with the guidance HTML comments stripped out:

## Jira Ticket

[OSDEV-123](https://opensupplyhub.atlassian.net/browse/OSDEV-123)

---

## Summary of Changes

<the what/why writing described in the rest of this skill>

---

## Type of Change

- [x] <only the boxes that apply>

---

## Testing

<how the change was verified>

---

## Known TODO Items

<deferred work, follow-up tickets, known limitations — or "None">

---

## Checklist

### Implementation
### Testing & Validation
### Documentation & Communication
### Final Review

Rules:

• Do not invent, drop, rename, or reorder sections, and keep the --- separators.
• Replace each N/A placeholder with real content. Leave N/A only when the section genuinely does not apply, and explain why in Summary of Changes.
• Jira Ticket: derive the ticket id from the branch name (see Gathering Context) and link it in the [OSDEV-123](...) format. Use N/A only for PRs with no ticket.
• Type of Change: check all applicable boxes. This drives what reviewers look at, so be accurate — a UI change needs the UI box, a schema change needs the backend box.
• Testing: list the scenarios actually covered (happy path, edge cases, regressions). Attach screenshots or a recording for UI changes; note the requests/queries run for backend changes.
• Known TODO Items: write None rather than deleting the section.
• Checklist: keep all four subsections and every item. Only check a box when the work was genuinely done and verified. Never check boxes on the author's behalf by assumption — leave them unchecked and tell the user which ones need their attention. Uncheck (or annotate) items that don't apply.