agentleFS
weininghuiweininghui/skills/conventional-commits/SKILL.md

conventional-commits

Skill1 starsChanged 12 days agoMITView on GitHub

Format commit messages using the Conventional Commits specification. Use when creating commits, writing commit messages, or when the user mentions commits, git commits, or commit messages. Ensures commits follow the standard format for automated tooling, changelog generation, and semantic versioning.

56 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use github, grilling and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • NVIDIASkill

    github

    Interact with GitHub using the gh CLI restricted to REST API only (no GraphQL). Use when the user wants to work with GitHub issues, pull requests, repos, releases, or Actions — especially in sandboxed environments where the GraphQL endpoint may be blocked. Trigger keywords - github, gh, pull request, PR, github issue, github actions, workflow, release, gh api.

    Also in 3 projects that use this

  • GoogleSkill

    grilling

    Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

    Also in 5 projects that use this

  • GoogleSkill

    domain-modeling

    Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

    Also in 4 projects that use this

  • NVIDIASkill

    research

    Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

    Also in 5 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 3 projects that use this

  • +5 more from google

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 51 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Must immediately follow the colon and space after the type/scope

    line 51
  2. Distinctive:

    Use imperative mood ("add feature" not "added feature" or "adds feature")

    line 52
  3. Distinctive:

    Don't capitalize the first letter

    line 53
  4. Distinctive:

    No period at the end

    line 54
  5. Distinctive:

    Keep it concise (typically 50-72 characters)

    line 55
  6. Distinctive:

    Must begin one blank line after the description

    line 60
  7. Distinctive:

    Always use a type: - Every commit must start with a type followed by a colon and space

    line 149
  8. Distinctive:

    Use imperative mood: - Write as if completing the sentence "If applied, this commit will..."

    line 150
  9. Distinctive:

    Document breaking changes: - Always indicate breaking changes clearly

    line 154
  10. Distinctive:

    Use this format for:

    line 164
  11. Distinctive:

    When the user asks about commit messages or git commits

    line 168

“Common” is measured: kept by at least 6 in 10 of the 51 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Conventional Commits

Format all commit messages according to the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and better commit history.

Format Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

Required Types

  • feat: - A new feature (correlates with MINOR in Semantic Versioning)
  • fix: - A bug fix (correlates with PATCH in Semantic Versioning)

Common Additional Types

  • docs: - Documentation only changes
  • style: - Code style changes (formatting, missing semicolons, etc.)
  • refactor: - Code refactoring without bug fixes or new features
  • perf: - Performance improvements
  • test: - Adding or updating tests
  • build: - Build system or external dependencies changes
  • ci: - CI/CD configuration changes
  • chore: - Other changes that don't modify src or test files
  • revert: - Reverts a previous commit

Scope

An optional scope provides additional contextual information about the section of the codebase:

feat(parser): add ability to parse arrays
fix(auth): resolve token expiration issue
docs(readme): update installation instructions

Description

  • Must immediately follow the colon and space after the type/scope
  • Use imperative mood ("add feature" not "added feature" or "adds feature")
  • Don't capitalize the first letter
  • No period at the end
  • Keep it concise (typically 50-72 characters)

Body

  • Optional longer description providing additional context
  • Must begin one blank line after the description
  • Can consist of multiple paragraphs
  • Explain the "what" and "why" of the change, not the "how"

Breaking Changes

Breaking changes can be indicated in two ways:

1. Using ! in the type/scope

feat!: send an email to the customer when a product is shipped
feat(api)!: send an email to the customer when a product is shipped

2. Using BREAKING CHANGE footer

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

3. Both methods

chore!: drop support for Node 6

BREAKING CHANGE: use JavaScript features not available in Node 6.

Examples

Simple feature

feat: add user authentication

Feature with scope

feat(auth): add OAuth2 support

Bug fix with body

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Breaking change

feat!: migrate to new API client

BREAKING CHANGE: The API client interface has changed. All methods now
return Promises instead of using callbacks.

Documentation update

docs: correct spelling of CHANGELOG

Multi-paragraph body with footers

fix: prevent racing of requests

Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.

Remove timeouts which were used to mitigate the racing issue but are
obsolete now.

Reviewed-by: Z
Refs: #123

Guidelines

  1. Always use a type - Every commit must start with a type followed by a colon and space
  2. Use imperative mood - Write as if completing the sentence "If applied, this commit will..."
  3. Be specific - The description should clearly communicate what changed
  4. Keep it focused - One logical change per commit
  5. Use scopes when helpful - Scopes help categorize changes within a codebase
  6. Document breaking changes - Always indicate breaking changes clearly

Semantic Versioning Correlation

  • fix: → PATCH version bump (1.0.0 → 1.0.1)
  • feat: → MINOR version bump (1.0.0 → 1.1.0)
  • BREAKING CHANGE → MAJOR version bump (1.0.0 → 2.0.0)

When to Use

Use this format for:

  • All git commits
  • Commit message generation
  • Pull request merge commits
  • When the user asks about commit messages or git commits

Common Mistakes to Avoid

❌ Added new feature (past tense, capitalized) ✅ feat: add new feature (imperative, lowercase)

❌ fix: bug (too vague) ✅ fix: resolve null pointer exception in user service

❌ feat: add feature (redundant) ✅ feat: add user profile page

❌ feat: Added OAuth support. (past tense, period) ✅ feat: add OAuth support

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.