# Commit And Pr Conventions

> Follow the adopted commit and pull-request conventions. Use whenever creating a commit or opening, editing, reviewing, or preparing to squash-merge a PR, including requests to commit, push, or open a PR.

- Skill: `devolutions/commit-and-pr-conventions` (Agent Skill)
- Install (CLI): `npx skillmds@latest add devolutions/commit-and-pr-conventions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/devolutions/commit-and-pr-conventions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: devolutions (https://skillmd.com/u/devolutions)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/devolutions/commit-and-pr-conventions

---


# Commit and PR conventions

Treat the PR title and initial body as the exact commit message that squash-and-merge will land.

## Commit message

- Read repository instructions first. Derive scopes with the repository-local `commit-scope` skill. If unavailable, use explicit repository rules or omit the scope rather than inventing one.
- Follow Conventional Commits: `<type>[optional scope][!]: <description>`.
- Target 50 characters and describe the resulting behavior. Do not drop repository-required scopes to meet that target; when they make it impossible, keep the remaining description as concise as practical.
- Separate subject, body, and footers with blank lines.
- For standalone commits, wrap body lines at 72 characters. Explain why the change was needed, how it solves it, and material side effects.
- Put an existing ticket key or link in a footer, not the subject: `Issue: PROJECT-123`. Follow repository-specific footer format when an issue exists. When none exists, omit the footer rather than fabricating `Issue: N/A`.
- Add applicable Conventional Commit footers and `Co-authored-by: Name <email>` trailers for collaborators.
- Choose the type by the affected surface, not by whether the change fixes a defect.
- Use `ci` for CI, workflow, and automation changes, including fixes to that automation.
- Use `fix` for product or runtime bugs and non-feature changes to externally consumed public API boundaries.
- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for internal restructuring, `test` for tests, and `perf` for performance.
- Mark breaking changes with `!` or a `BREAKING CHANGE` footer without changing an otherwise accurate type.
- Keep every non-squashed development commit coherent and conventional.

```text
fix(storage): preserve collated indexes

Normalize server-expanded collations before comparing index definitions.

Issue: PROJECT-123
```

## Pull request

- Set the title to the intended squash commit subject exactly.
- Set the initial body to the intended squash commit body and footers exactly. Exclude PR-only preambles, checklists, and implementation journals.
- Do not manually wrap the PR body; GitHub handles display wrapping.
- Keep permanent history concise: record motivation, material behavior, and side effects.
- Put experiments, alternatives, extensive validation, and implementation chronology in follow-up comments.
- Update the title and initial body as the implementation evolves.
- Before opening, updating, or merging, read `title + blank line + body` as one commit message and correct any mismatch.