Which PR title follows Conventional Commits format correctly?
Conventional Commits format: `type(scope): description` in lowercase imperative mood. Types: fix, feat, chore, docs, refactor, test, ci. The scope (auth) identifies the module. The description explains what the commit does (imperative: "prevent", not "prevented"). This format enables automated changelog generation and communicates intent to reviewers at a glance.
2 / 5
"Closes #142" in a PR description does what on GitHub?
GitHub magic words (Closes, Fixes, Resolves) followed by an issue number automatically close the referenced issue when the PR merges into the default branch. This is the standard way to link work to reported issues. Keywords are case-insensitive. The issue is not closed when the PR is opened — only on merge.
3 / 5
Your PR adds a new feature that is not backward-compatible. Which PR description element is most important to add?
Breaking changes must be explicitly flagged in PR descriptions and commit messages. Conventional Commits specifies: add `!` after the type (`feat!:`) or include a `BREAKING CHANGE:` footer. This enables semantic versioning tools to automatically bump the major version. Maintainers and downstream users need explicit migration instructions — not just a note that something changed.
4 / 5
The "What / Why / How / How to test" PR description structure — what belongs in the "Why" section?
"Why" = the motivation behind the change. It must include: the issue reference (so the reviewer can read the full context), and the root cause or business motivation (so the reviewer understands why this specific fix was chosen). "Why" answers "should this change exist?" before the reviewer even reads the code.
5 / 5
A maintainer asks you to "squash your commits before merging". What does this mean?
Squashing combines multiple commits into one, producing a clean, atomic commit in the project history. This is common in projects that prefer a linear history. Before squashing, write a final commit message that summarises the complete change using Conventional Commits format. Many projects squash automatically on merge via GitHub's "Squash and merge" button — but maintainers may ask you to do it manually if they want you to write the final message.