Before starting work, read and follow CONTRIBUTING.md, including the Prevent agent impersonation section governing identification when communicating through a person's account.
Follow Conventional Commits for every commit. Every commit must have a descriptive title and a substantive body. Title-only commit messages are not acceptable.
Write commit messages in Markdown and assume readers view them with syntax highlighting. Enclose code identifiers, package and module names, file paths, and shell commands in backticks. Use Markdown whenever it helps readers understand or navigate the prose.
- Every title must use the form
type: descriptionortype(scope): description. - Use
feat:for user-visible features andfix:for user-visible fixes. - Use appropriate prefixes for other changes, such as
docs:,test:,ci:,build:,refactor:,perf:,style:, orchore:. - Breaking changes must use
!immediately before the colon, for examplefeat!:,refactor!:, or a scoped form such asfix(repo)!:. - Optionally scope a commit to the affected component, for example
fix(repo):.
Example titles:
feat: add support for a new Git optionfix(repo): handle bare repositories correctlybuild!: drop support for an older Python versionci: add an independent documentation buildrefactor(repo): simplify repository initialization
The body must explain the problem or motivation, what changed, and why the chosen approach addresses it. Include relevant behavior before and after the change, design decisions, limitations, and validation results. Scale the detail to the change; do not add boilerplate or claim checks that were not run.
Commit messages must stand on their own. Put the information needed to understand and review the change in the commit body, even when it also appears in a pull request description. PR and issue links may provide additional context, but must not substitute for that explanation.