Source profileQuality 96/100

aAAaqwq/AGI-Super-Team/skills/conventional-commits/SKILL.md

conventional-commits

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.

Source repository stars
89
Declared platforms
0
Static risk flags
0
Last source update
2026-08-26
Source checked
2026-08-28

Decision brief

What it does: where it fits

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

Best for

  • All git commits
  • Commit message generation
  • Pull request merge commits

Not for

  • ❌ Added new feature (past tense, capitalized) ✅ feat: add new feature (imperative, lowercase)
  • ❌ fix: bug (too vague) ✅ fix: resolve null pointer exception in user service

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/aAAaqwq/AGI-Super-Team --skill "skills/conventional-commits"
Safe inspection promptEditorial

Inspect the Agent Skill "conventional-commits" from https://github.com/aAAaqwq/AGI-Super-Team/blob/bfcfb64081f94e5869ff420aaaed63b6da716bc6/skills/conventional-commits/SKILL.md at commit bfcfb64081f94e5869ff420aaaed63b6da716bc6. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Format Structure

    Review the “Format Structure” section in the pinned source before continuing.

    Review and apply the “Format Structure” source section.
  2. 02

    Commit Types

    feat: - A new feature (correlates with MINOR in Semantic Versioning)

    feat: - A new feature (correlates with MINOR in Semantic Versioning)fix: - A bug fix (correlates with PATCH in Semantic Versioning)docs: - Documentation only changes
  3. 03

    Required Types

    feat: - A new feature (correlates with MINOR in Semantic Versioning)

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

    Common Additional Types

    docs: - Documentation only changes

    docs: - Documentation only changesstyle: - Code style changes (formatting, missing semicolons, etc.)refactor: - Code refactoring without bug fixes or new features
  5. 05

    Scope

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

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

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score96/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars89SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
aAAaqwq/AGI-Super-Team
Skill path
skills/conventional-commits/SKILL.md
Commit
bfcfb64081f94e5869ff420aaaed63b6da716bc6
License
MIT
Collected
2026-08-28
Default branch
main
View the original 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

Frequently asked questions

What to verify before installation and use

What does the conventional-commits source document cover?

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

How do I install conventional-commits?

The source record exposes this install command: npx skills add https://github.com/aAAaqwq/AGI-Super-Team --skill "skills/conventional-commits". Inspect the command and pinned source before running it.

Alternatives

Compare before choosing

Computed 9564

Jamie-BitFlight/claude_skills

conventional-commits

When writing a git commit message. When task completes and changes need committing. When project uses semantic-release, commitizen, git-cliff. When choosing between feat/fix/chore/docs types. When indicating breaking changes. When generating changelogs from commit history.

Computed 100147

oaustegard/claude-skills

featuring

Generate hierarchical _FEATURES.md files that describe what a codebase DOES from a user/consumer perspective, anchored to source symbols via tree-sitting. Supports large complex codebases through feature-driven decomposition into sub-feature files. Uses a multi-pass synthesis: orientation → detail → overview rewrite. Use when someone says "what does this do", "document features", "feature inventory", "_FEATURES.md", or needs to understand a codebase's purpose before modifying it. Complements tre

Computed 10017

dancingteeth/unified-code-review

unified-code-review

Risk-first code review for PRs and branch audits: blast-radius triage, agent-authored discipline (tests first, intent evidence), call-graph pincer for integration defects between modules, then structural code-judo bar. Use when reviewing PRs, auditing agent-written diffs, catching rubber-stamp green CI, or wiring bugs single-file review misses. Prefer over structure-only thermo-nuclear review alone. Do not use for unrelated coding tasks or as an always-on rule.

Computed 1009

Postpartum-genushyacinthus29/dotnet-skills

dotnet-worker-services

Build long-running .NET background services with `BackgroundService`, Generic Host, graceful shutdown, configuration, logging, and deployment patterns suited to workers and daemons.