Reading PR Checklists & Templates
5 exercises — read a realistic GitHub PR template checklist with conditional sections, security items, and a breaking change definition. Understand what each item requires and how to interpret unchecked boxes.
Reading PR checklists: what to look for
- [x] checked → author confirms this is done or applies
- [ ] unchecked → either not applicable (read context) or outstanding (look for explanation)
- Conditional items → "(required for API changes)" — only mandatory if the condition is true
- Breaking change → causes currently working integrations to fail or behave differently
- Reviewer Notes → where authors explain deviations from the standard checklist
0 / 5 completed
1 / 5
GitHub PR Template — acme-platform
## Pull Request Template — acme-platform
Please complete this checklist before requesting review.
Delete sections that do not apply to your change.
---
### Type of Change
- [ ] Bug fix (non-breaking change that resolves an issue)
- [x] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation update
### Breaking Change Checklist (complete only if "Breaking change" is checked above)
- [ ] I have updated MIGRATION.md with upgrade instructions
- [ ] I have bumped the major version in package.json
- [ ] I have notified the #platform-consumers Slack channel
### Code Quality
- [x] My code follows the project style guide (ESLint passes: `npm run lint`)
- [x] I have added or updated unit tests for my changes
- [ ] I have added or updated integration tests (required for API changes)
- [x] All existing tests pass locally (`npm test`)
### Documentation
- [x] I have updated the relevant JSDoc comments
- [ ] I have updated the public API documentation in /docs (required if public API changed)
- [ ] I have updated the README if the setup steps changed
### Security
- [ ] My change introduces new dependencies (if checked: run `npm audit` and attach output)
- [x] I have not hardcoded secrets, tokens, or passwords in the code
- [ ] This change touches authentication or authorization logic (if checked: security review required)
### Reviewer Notes
This PR adds the CSV export feature requested in issue #887.
The integration test item is unchecked because this is a pure frontend change
with no API modifications. I have confirmed this with the team lead.Looking at the "Type of Change" section, which box is checked and what does this tell a reviewer about the PR?
"New feature" is the only checked box — non-breaking, additive change:
The
A reviewer approaching a "Bug fix" PR looks for: what was the root cause, does the fix actually address it, are there regression tests? A reviewer approaching a "New feature" PR looks for: is it the right design, is it tested, is it documented? The type of change sets the review lens.
The
[x] mark next to "New feature (non-breaking change that adds functionality)" tells the reviewer immediately:- There are no breaking changes to existing behaviour — upgrade is safe without migrations
- The Breaking Change Checklist section below is not applicable (hence those boxes are unchecked)
- The change adds something new — so the reviewer should look for tests that cover the new functionality
[x]→ checked / confirmed / done[ ]→ unchecked — either not applicable or intentionally left incomplete (look for an explanation)
A reviewer approaching a "Bug fix" PR looks for: what was the root cause, does the fix actually address it, are there regression tests? A reviewer approaching a "New feature" PR looks for: is it the right design, is it tested, is it documented? The type of change sets the review lens.