dbx-commit-messages

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

Auto-Commit Behavior

When this skill is invoked without additional arguments (e.g., the user runs /dbx-commit-messages with no other instructions), immediately proceed to commit changes using the conventions below. Do not ask for confirmation — analyze the changes, draft an appropriate commit message, stage the relevant files, and create the commit.

• If you have context about what you were just working on, only commit the files related to that work. Stage them by name rather than using git add -A.
• If you have no prior context about recent work, commit all staged and unstaged changes.

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

1. 72 character limit - The entire first line must fit within 72 characters. A pre-commit hook enforces this.
2. Keep it brief - Subjects should be short and to the point. Most commits in this project are 3-6 words.
3. Subject is lowercase - Start the subject with a lowercase letter.
4. No period - Don't end the subject with a period.
5. Past tense or imperative - Both styles are used; past tense is more common (e.g., "added", "fixed", "updated").
6. 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