Enforces conventional commits for consistency in changelogs and versioning.
Install
mkdir -p .claude/skills/git-matteing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17249" && unzip -o skill.zip -d .claude/skills/git-matteing && rm skill.zipInstalls to .claude/skills/git-matteing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Enforces conventional commit messages and good git hygiene. Use this skill automatically whenever creating commits, preparing PRs, or performing any git operations in this repository.Key capabilities
- →Standardize commit message types
- →Identify affected areas with scopes
- →Indicate breaking changes in commit messages
- →Ensure one logical change per commit
How it works
The skill ensures that every commit message adheres to the Conventional Commits specification, including required types, recommended scopes, and indicators for breaking changes. It checks for proper formatting and content before a commit is finalized.
Inputs & outputs
When to use git
- →Formatting commit messages
- →Preparing PR commits
- →Standardizing history logs
About this skill
Git Conventional Commit Skill
You enforce Conventional Commits on every commit in this repository. This is critical for consistent changelogs and semantic version bumps.
Commit message format
Every commit message MUST follow this format:
<type>(<scope>): <description>
[optional body]
[optional footer(s)]
Types (required)
| Type | When to use | Version bump |
|---|---|---|
feat | A new feature or capability | minor |
fix | A bug fix | patch |
docs | Documentation only | none |
style | Formatting, semicolons, whitespace — no logic | none |
refactor | Code change that neither fixes a bug nor adds a feature | none |
perf | Performance improvement | patch |
test | Adding or correcting tests | none |
build | Build system or external dependency changes | none |
ci | CI configuration changes | none |
chore | Maintenance tasks (deps, tooling, releases) | none |
Scopes (recommended)
Use a scope to identify the affected area:
| Scope | Meaning |
|---|---|
core | Elixir core (lib/opal/ directory) |
cli | TypeScript CLI (cli/ directory) |
rpc | JSON-RPC protocol layer |
agent | Agent loop / GenServer |
tools | Built-in tool implementations |
ci | GitHub Actions workflows |
release | Release and versioning infrastructure |
docs | Documentation |
sdk | TypeScript SDK client |
Omit the scope only when the change truly spans the entire project.
Breaking changes
Append ! after the type/scope for breaking changes:
feat(rpc)!: change message envelope format
Or add a BREAKING CHANGE: footer in the body.
Rules
- Always use conventional commit format. Never commit with a bare message like "fix stuff" or "updates".
- Description must be lowercase, imperative mood, no period at the end.
- Scope should match the table above when the change is localized.
- Body is optional but encouraged for non-trivial changes — explain why, not what.
- One logical change per commit. Don't bundle unrelated changes.
- Before committing, verify the message parses as a valid conventional commit.
Examples
feat(cli): add --json flag for machine-readable output
fix(core): prevent crash when tool returns empty response
docs(tools): document edit tool hashline format
refactor(agent): extract token counting into dedicated module
ci: add Elixir dialyzer step to CI pipeline
chore(release): 0.1.10
feat(rpc)!: switch from JSON-RPC 2.0 to msgpack framing
BREAKING CHANGE: RPC wire format changed from JSON to msgpack.
Clients must update to sdk >= 0.2.0.
When not to use it
- →When committing with bare messages like 'fix stuff'
- →When bundling unrelated changes into a single commit
- →When not adhering to the Conventional Commits format
Limitations
- →Commit messages must be in lowercase and imperative mood.
- →The skill requires adherence to predefined commit types and scopes.
- →The description must not end with a period.
How it compares
This skill automatically enforces a structured commit message format, which helps maintain a consistent and meaningful git history, unlike manual commit practices that can lead to varied or unclear messages.
Compared to similar skills
git side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| git (this skill) | 0 | 4mo | Review | Beginner |
| github-workflow-automation | 11 | 2mo | Review | Advanced |
| testing-workflow | 16 | 9mo | Review | Intermediate |
| github-actions-templates | 7 | 3mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
github-workflow-automation
ruvnet
Advanced GitHub Actions workflow automation with AI swarm coordination, intelligent CI/CD pipelines, and comprehensive repository management
testing-workflow
amo-tech-ai
Comprehensive testing workflow for E2E, integration, and unit tests. Use when testing applications layer-by-layer, validating user journeys, or running test suites.
github-actions-templates
wshobson
Create production-ready GitHub Actions workflows for automated testing, building, and deploying applications. Use when setting up CI/CD with GitHub Actions, automating development workflows, or creating reusable workflow templates.
glab
NikiforovAll
Expert guidance for using the GitLab CLI (glab) to manage GitLab issues, merge requests, CI/CD pipelines, repositories, and other GitLab operations from the command line. Use this skill when the user needs to interact with GitLab resources or perform GitLab workflows.
create-pr
n8n-io
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.
gh-fix-ci
openai
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.