Git Semantic Commits Skill

Name: Git Semantic Commits Skill
Author: darellchua2

ASecurity

Conventional Commits — type, scope, breaking changes, semver guidance, atomic-commit granularity by layer. Triggers: commit and push, make a commit, write a commit message, commit message format, semantic commit. Not for brevity (git-compact-commits-skill).

6 stars

0 votes

0 copies

0 views

Added 9/20/2026

devopsgobashgitapidatabase

Works with

api

Security Analysis

A100/100

Scanned 9/20/2026

Install to Claude Code

$npx -y skills add darellchua2/opencode-config-template --skill git-semantic-commits-skill --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Git Semantic Commits Skill?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Git Semantic Commits Skill

[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/darellchua2-git-semantic-commits-skill/badge)](https://www.skillsdirectory.com/skills/darellchua2-git-semantic-commits-skill)

More formats (shields.io, HTML) on the badges page.

Download Zip

Files

SKILL.md

---
name: git-semantic-commits-skill
description: "Conventional Commits — type, scope, breaking changes, semver guidance, atomic-commit granularity by layer. Triggers: commit and push, make a commit, write a commit message, commit message format, semantic commit. Not for brevity (git-compact-commits-skill)."
license: Apache-2.0
compatibility: opencode
category: Git/Workflow
---

## What I do

Conventional Commits formatting plus this config's atomic-commit granularity doctrine. A framework skill — other skills consume these rules.

**Handoffs:** commit-length enforcement (72-char subject, 150-word body, commitlint config, semantic grouping) → `git-compact-commits-skill` (the authority for those). Full release pipeline conventions (PR titles, merge strategy, release tags, GitHub Actions) → `semantic-release-convention`.

## Format

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

<body>

<footer>
```

- Types: `feat fix docs style refactor test chore perf ci build revert`
- Subject: imperative mood ("add", not "added"), lowercase type/scope, ≤72 chars, no trailing period
- Body: what and why, not how; wrap at 72; word-count limits live in `git-compact-commits-skill`
- Footers: `BREAKING CHANGE: <desc + migration>`, `Closes #N`, `Reviewed-by:`, `Authored-by:`
- Breaking change: `!` after type/scope (`feat(api)!: …`) **or** `BREAKING CHANGE:` footer → MAJOR

## Semver mapping

`feat`→MINOR · `fix`→PATCH · `perf`→PATCH/MINOR · `build`→PATCH if functional · `docs`/`style`/`refactor`/`test`/`chore`/`ci`→none · breaking→MAJOR.

## Commit Granularity (house doctrine)

**One logical change per commit** — each commit compiles and passes tests on its own. Never mix style-only changes with logic.

| Layer | Commit type | Why isolate |
|---|---|---|
| Database migration | `feat(db):` / `chore(db):` | DDL is irreversible; isolated rollback |
| ORM / model | `feat(model):` | downstream code depends on schema |
| API contract (pydantic/schema) | `feat(schema):` | consumers must adapt |
| Business logic | `feat:` / `fix:` / `refactor:` | one concern per commit |
| Tests | same commit as the code (or `test:` if large) | tests validate what they accompany |
| Docs / plan updates | `docs:` | no runtime effect |
| Style / formatting | `style:` | always its own commit |

Split vs combine: single concern → one commit · different layers → one per layer · same layer, tightly coupled (can't compile/test apart) → combine · same layer, independent → separate commits.

## Project override

These are **defaults**. The project's `AGENTS.md` and `.commitlintrc*` / `commitlint.config.*` override them (layer naming, body line length 72 vs 120, squash-merge policy). Always check the project's AGENTS.md first.

> Removed 2026-09: per-type example/keyword catalogs, filled templates, changelog samples, validation/detection bash scripts, commitizen/commitlint/semantic-release setup guides, and common-issue walkthroughs — the spec lives at conventionalcommits.org; this file keeps the house doctrine and handoffs.

Attribution

darellchua2

View source More from darellchua2 →

SSkills DirectorySkills Directory

Your tool, in front of Claude Code builders.

3 founder slots · $299/mo · GSC-verified traffic · sponsors can never buy grades.

See placements

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

--- name: git-semantic-commits-skill description: "Conventional Commits — type, scope, breaking changes, semver guidance, atomic-commit granularity by layer. Triggers: commit and push, make a commit, write a commit message, commit message format, semantic commit. Not for brevity (git-compact-commits-skill)." license: Apache-2.0 compatibility: opencode category: Git/Workflow --- ## What I do Conventional Commits formatting plus this config's atomic-commit granularity doctrine. A framework skill — other skills consume these rules. **Handoffs:** commit-length enforcement (72-char subject, 150-word body, commitlint config, semantic grouping) → `git-compact-commits-skill` (the authority for those). Full release pipeline conventions (PR titles, merge strategy, release tags, GitHub Actions) → `semantic-release-convention`. ## Format ``` <type>(<scope>): <subject> <body> <footer> ``` - Types: `feat fix docs style refactor test chore perf ci build revert` - Subject: imperative mood ("add", not "added"), lowercase type/scope, ≤72 chars, no trailing period - Body: what and why, not how; wrap at 72; word-count limits live in `git-compact-commits-skill` - Footers: `BREAKING CHANGE: <desc + migration>`, `Closes #N`, `Reviewed-by:`, `Authored-by:` - Breaking change: `!` after type/scope (`feat(api)!: …`) **or** `BREAKING CHANGE:` footer → MAJOR ## Semver mapping `feat`→MINOR · `fix`→PATCH · `perf`→PATCH/MINOR · `build`→PATCH if functional · `docs`/`style`/`refactor`/`test`/`chore`/`ci`→none · breaking→MAJOR. ## Commit Granularity (house doctrine) **One logical change per commit** — each commit compiles and passes tests on its own. Never mix style-only changes with logic. | Layer | Commit type | Why isolate | |---|---|---| | Database migration | `feat(db):` / `chore(db):` | DDL is irreversible; isolated rollback | | ORM / model | `feat(model):` | downstream code depends on schema | | API contract (pydantic/schema) | `feat(schema):` | consumers must adapt | | Business logic | `feat:` / `fix:` / `refactor:` | one concern per commit | | Tests | same commit as the code (or `test:` if large) | tests validate what they accompany | | Docs / plan updates | `docs:` | no runtime effect | | Style / formatting | `style:` | always its own commit | Split vs combine: single concern → one commit · different layers → one per layer · same layer, tightly coupled (can't compile/test apart) → combine · same layer, independent → separate commits. ## Project override These are **defaults**. The project's `AGENTS.md` and `.commitlintrc*` / `commitlint.config.*` override them (layer naming, body line length 72 vs 120, squash-merge policy). Always check the project's AGENTS.md first. > Removed 2026-09: per-type example/keyword catalogs, filled templates, changelog samples, validation/detection bash scripts, commitizen/commitlint/semantic-release setup guides, and common-issue walkthroughs — the spec lives at conventionalcommits.org; this file keeps the house doctrine and handoffs.