What is the Angular commit convention?

A standardized format for commit messages: type(scope): subject, followed by an optional body and footer.

How long should the subject be and how should it be written?

Use imperative, present tense; do not capitalize the first letter and do not end with a period; keep the subject under 72 characters.

git-convention

Scanned

npx machina-cli add skill duckyman-ai/agent-skills/git-convention --openclaw

Files (1)

SKILL.md

4.8 KB

Git Convention Skill

Generate conventional git commit messages following Angular commit convention format.

Commit Message Format

<type>(<scope>): <subject>

<body>

<footer>

Type

Must be one of:

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
`refactor`	A code change that neither fixes a bug nor adds a feature
`perf`	A code change that improves performance
`test`	Adding missing tests or correcting existing tests
`build`	Changes that affect the build system or external dependencies
`ci`	Changes to CI configuration files and scripts
`chore`	Other changes that don't modify src or test files
`revert`	Reverts a previous commit

Scope

The scope should be the name of the npm package affected (as indicated by package.json).

Example scopes:

core
auth
user
api
ui

Subject

The subject contains a succinct description of the change:

Use imperative, present tense: "change" not "changed" nor "changes"
Don't capitalize the first letter
No period (.) at the end

Body

The body should include the motivation for the change and contrast this with previous behavior:

Use imperative, present tense: "change" not "changed" nor "changes"
Include the motivation for the change and contrast this with previous behavior

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines.

Examples

Feature with scope

feat(auth): add login with Google

Implement OAuth2 authentication flow using Google Sign-In
- Add GoogleSignInButton component
- Update auth service to handle OAuth tokens
- Add error handling for failed authentication

Closes #123

Bug fix

fix(api): handle null response from user endpoint

Previously, null responses would crash the app.
Now returns empty user object instead.

Breaking change

feat(core): change user model structure

BREAKING CHANGE: User.id is now String instead of int.

All database queries and API calls need to be updated
to handle string IDs.

Documentation

docs(readme): update installation instructions

Added step for installing required system dependencies.

Refactoring

refactor(user): extract validation logic to separate class

Move all user validation logic from UserService to
new UserValidator class for better testability.

Multiple paragraphs in body

feat(api): add pagination support

Implement cursor-based pagination for list endpoints.

- Add PaginationFilter class
- Update repository methods to accept pagination params
- Add tests for pagination edge cases

This improves performance for large datasets and
reduces memory usage.

Revert

revert: feat(auth): add login with Facebook

This reverts commit 1a2b3c4d

Best Practices

DO:

Use the present tense ("add" not "added")
Use the imperative mood ("move" not "moves")
Limit the first line to 72 characters or less
Reference issues in the footer
Explain what and why, not how
Keep subject line short and descriptive
Use body to explain what and why vs. how

DON'T:

Use past tense
Use period at the end of subject
Capitalize first letter of subject
Mix multiple types in one commit
Write vague subjects like "update stuff"
Include how you fixed it in the message
Exceed 72 characters on first line

Changelog Generation

Conventional commits enable automatic changelog generation:

# Using conventional-changelog
npm install -g conventional-changelog
conventional-changelog -p angular -i CHANGELOG.md -s

Commit Linting

Enforce commit message conventions with commitlint:

// commitlint.config.js
{
  "extends": ["@commitlint/config-angular"],
  "rules": {
    "type-enum": [2, "always", ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"]],
    "type-case": [2, "always", "lower-case"],
    "subject-empty": [2, "never"],
    "subject-case": [0]
  }
}

Quick Reference

feat: add new feature
fix: fix bug
docs: update documentation
style: format code (no logic change)
refactor: refactor code
perf: improve performance
test: add/update tests
build: change build system
ci: change CI config
chore: other changes
revert: revert previous commit

Source

git clone https://github.com/duckyman-ai/agent-skills/blob/main/skills/git-convention/SKILL.mdView on GitHub

Overview

This skill generates conventional git commit messages following the Angular commit convention. It guides you to structure commits as type(scope): subject with optional body and footer, improving changelog clarity and history navigation.

How This Skill Works

You specify a type from the allowed list, a scope (usually an npm package), and a concise subject in imperative tense. The message is assembled as <type>(<scope>): <subject>, with an optional body and footer for motivation and references. Follow the body/footer guidelines to explain the change and any breaking changes or issues.

When to Use It

When creating a new feature and you want a standardized commit message
When fixing a bug and documenting the fix for changelogs
When updating documentation that accompanies code changes
When performing a refactor that should be clearly tracked
When closing issues or preparing a changelog entry

Quick Start

Step 1: Identify the change type from the allowed list and pick a scope (usually a package name).
Step 2: Write the header using the exact format: <type>(<scope>): <subject>, keeping the subject under 72 chars and lowercase with no trailing period.
Step 3: Add a body that explains why the change was made and any relevant details, then include a footer for breaking changes or issue references if needed.

Best Practices

Use present tense and imperative mood (e.g., add, remove)
Keep the subject line under 72 characters and start with a lowercase letter; do not end with a period
Explain what and why in the body, not how
Reference issues in the footer (e.g., Closes #123)
Don’t mix multiple types in a single commit; keep scope and type focused

Example Use Cases

feat(auth): add login with Google Implement OAuth2 authentication flow using Google Sign-In - Add GoogleSignInButton component - Update auth service to handle OAuth tokens - Add error handling for failed authentication Closes #123
fix(api): handle null response from user endpoint Previously, null responses would crash the app. Now returns empty user object instead.
docs(readme): update installation instructions Added step for installing required system dependencies.
refactor(user): extract validation logic to separate class Move all user validation logic from UserService to new UserValidator class for better testability.
revert: feat(auth): add login with Google This reverts commit 1a2b3c4d

Frequently Asked Questions

Add this skill to your agents

git-convention

Git Convention Skill

Commit Message Format

Type

Scope

Subject

Body

Footer

Examples

Feature with scope

Bug fix

Breaking change

Documentation

Refactoring

Multiple paragraphs in body

Revert

Best Practices

Changelog Generation

Commit Linting

Quick Reference

Source

Overview

How This Skill Works

When to Use It

Quick Start

Best Practices

Example Use Cases

Frequently Asked Questions

What is the Angular commit convention?

Which types are allowed?

How long should the subject be and how should it be written?