dbx-commit-messages

Guide for writing commit messages in the dbx-components workspace.

Convention

This project uses @commitlint/config-angular with a restricted set of commit types defined in

.commitlintrc.json

Format

type(scope): subject
                          <-- blank line required before body
- additional detail line
- another detail line

type - Required. One of the allowed types below.
scope - Optional. Indicates what area of the codebase is affected.
subject - Required. Very brief, lowercase description. No period. The entire first line (
```
type(scope): subject
```
) must be 72 characters or less (enforced by pre-commit hook).
body lines - Optional. Must be separated from the title by a blank line. Each line starts with a dash (
```
-
```
) and gives a short explanation. Use when the title alone is too brief to convey the change. The first body line can continue/clarify the title.

Allowed Types (for Developer Use)

Type	When to Use
`refactor`	Code changes that don't add new features or fix user-facing bugs. This is the most common type. Use for restructuring, renaming, style fixes, updating configurations, adding utilities, etc.
`build`	Build system or tooling changes. Commonly used as `build: lint fix` after running linters.
`fix`	Bug fixes for existing functionality.
`test`	Adding or updating tests.
`docs`	Documentation-only changes.
`perf`	Performance improvements.
`checkpoint`	Work-in-progress commit that isn't a complete refactor. Use when saving progress on an incomplete task.
`ai`	Commits related to AI skills, AI-generated content, or AI-specific configuration (e.g., `.claude/` directory changes).
`demo`	Changes to demo applications or example code.

Reserved Types (Do NOT Use Manually)

Type	Reserved For
`feat`	Feature PRs on GitHub only. Never use in direct commits to develop.
`ci`	CircleCI configuration changes only.
`release`	Auto-generated by CircleCI release tooling.
`merge`	Auto-generated when merging main back into develop after a release.

Important:
feat
and any breaking changes (
feat!
,
refactor!
, etc.) are reserved for pull requests. Do not use them in regular commits on the develop branch.

Scope Patterns

Scopes are optional but helpful. Common patterns from the project history:

No scope - Most common. Used when the change is general or touches multiple areas.
- ```
refactor: style fixes
```
- ```
build: lint fix
```
Specific component/service name - When the change is focused on one thing.
- ```
refactor: fixed DbxMapboxMapDirective
```
- ```
refactor: added DbxLinkifyService
```

Area description - Brief description of what area was changed.

refactor: updated dbx-grid, dbx-accordion

```
refactor: package.json fixes
```

Style Guide

72 character limit - The entire first line must fit within 72 characters. A pre-commit hook enforces this.
Keep it brief - Subjects should be short and to the point. Most commits in this project are 3-6 words.
Subject is lowercase - Start the subject with a lowercase letter.
No period - Don't end the subject with a period.
Past tense or imperative - Both styles are used; past tense is more common (e.g., "added", "fixed", "updated").
Prefer
refactor
- When in doubt between types,
```
refactor
```
is almost always the right choice for regular development work.

Examples

Single-line (most common)

refactor: style fixes
refactor: updated vitest config
refactor: package.json fixes
build: lint fix
checkpoint: accordion view
ai: moved skills to .claude

Multi-line (when more detail is needed)

refactor: updated dbx-grid, dbx-accordion
- added responsive breakpoint support
- fixed column alignment in grid

refactor: fixed early destroy on components
- subscription was completing before cleanup

fix: resolved null reference in form validation
- checked for undefined before accessing nested field

test: added unit tests for object filter
- covers edge cases for empty and nested objects

AI Attribution

Do not add

Co-Authored-By

or similar attribution trailers by default. Only add AI attribution when the user explicitly grants permission for significant contributions (e.g., large feature implementations or PRs).

Common Mistakes to Avoid

Using
```
feat
```
for regular commits (reserved for PRs)
Using
```
ci
```
for non-CircleCI changes
Starting the subject with an uppercase letter
Adding a period at the end of the subject
Using overly long subjects (keep it scannable)
Missing the blank line between the title and body lines

dbx-commit-messages

NPX Install

Tags

SKILL.md Content

dbx-commit-messages

Convention

Format

Allowed Types (for Developer Use)

Reserved Types (Do NOT Use Manually)

Scope Patterns

Style Guide

Examples

Single-line (most common)

Multi-line (when more detail is needed)

AI Attribution

Common Mistakes to Avoid