Programming · Writing
commit
/commit
Use when writing a commit message, or before running `git commit`.
For whom
- Author
- j0hanz ↗
- Repository
- j0hanz-marketplace ↗
- Licence
- MIT
- Last repository change
- 27.10.2026
Assessment and security
96/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability21 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
Deprecation
No signals detected. Repository changed on 27.10.2026, without references to retired models or APIs.
Licence
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Use when writing a commit message, or before running `git commit`.
Original author description
Use when writing a commit message, or before running `git commit`.
How it works
- Message
- What to leave out
- Examples
- Boundaries
Original SKILL.md headings · 61 lines, 508 words
SKILL.md preview
---
name: commit
description: Use when writing a commit message, or before running `git commit`.
---
**REQUIRED:** apply writeup:unslop to all prose.
## Message
Read the staged diff (`git diff --cached`) first. A commit message has these parts, in this order:
1. **Subject.** `type(scope): summary`, the Conventional Commits form. The type is one of `feat`, `fix`, `refactor`, `perf`, `docs`, `test`, `chore`, `build`, `ci`, `style` or `revert`. The scope is the area the change touches, such as a package or plugin name, and is optional. The summary is in the imperative mood ("add", not "added" or "adds"), lowercase after the colon unless the repo's log says otherwise, with no trailing period. Aim for 50 characters; 72 is the limit. A `!` after the scope marks a breaking change.
2. **Blank line.**
3. **Body.** One paragraph of at most 3 lines, wrapped at 72 characters, that states the problem the change solves. It does not repeat the subject and names no file, function or constant. The reader has the diff for those. When the subject already states the problem, as for a typo fix, there is no body.
4. **Footer.** After a blank line: issue references such as `Closes #42` or `Refs #17`, a `BREAKING CHANGE:` line that says what a caller must change, then trailers such as `Co-Authored-By:`.
A breaking change, a security fix, a data migration or a revert always has a body. That body says what breaks, what was exposed, what moves, or why the earlier change went back.
## What to leave out
- "This commit", "I", "we", "now", "currently". The diff says what changed; the body says why.
- A list of the test cases.
- Conventions every change in the repo already follows, such as rules from the repo's instructions file.
- Attribution to the model or tool that wrote the change, except as a trailer the repo's own rules ask for.
## Examples
A subject that names the behavior, and a body that names the problem:
```text
feat(api): add GET /users/:id/profile
The mobile client loads the full user payload on every cold launch
to read three profile fields. Launch on LTE took over two seconds.
Closes #128
```
A body that states what was wrong before:
```text
fix(auth): retry the token refresh once on a 401
The auth server rotates its signing key every hour, so a token
issued just before the rotation fails once. Users were logged out.
```
A breaking change:
```text
feat(api)!: rename /v1/orders to /v1/checkout
The orders route also took cart edits, so a client could not tell a
placed order from an open cart.
BREAKING CHANGE: callers of /v1/orders must move to /v1/checkout
before 2026-06-01. The old route returns 410 after that date.
```
## Boundaries
Write the message. Stage, amend or push only when the user asked for it. When the user asked for the message and not the commit, hand it back in a code block ready to paste.
Done when the subject fits in 72 characters and a reader who has not seen the diff knows what was wrong before, from the body or, when there is none, from the subject.
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · j0hanz/j0hanz-marketplace | 96 | MIT |
| rmsaitam/skill-git-conventions | 100 | MIT |
| opsmill/infrahub | 100 | Apache-2.0 |
| kdlbs/kandev | 100 | AGPL-3.0 |
| vinta/hal-9000 | 100 | MIT |
| restarter/lets-workflow | 100 | MIT |
| mickeyyaya/evolve-loop | 100 | Apache-2.0 |
| friendlyinternet/nuxt-crouton | 100 | MIT |
| yonatangross/orchestkit | 100 | MIT |
Database snapshot: 13.11.2026 · package version 160915eba98f (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 100dev-commit
开发者准备提交代码时触发。当用户说"commit"、"提交"、"写 commit message"、 "commit these changes"、"生成提交信息"、"帮我写 commit"时使用本 skill。 基于 git diff 生成符合项目 commit 规范的提交信息。 即使用户没有明确说"commit message",只要涉及提交代码的操作都应该触发。 - 90commit-message
Write a commit message for the staged changes that matches the repo's own style, and commit when asked. Use when asked to "write a commit message", "commit this", "commit my changes" or "what should this commit say". - 84generate-commit-message
Generate well-structured git commit messages. Use when user says "generate commit message", "write a commit", "what should my commit message be", "create commit message for these changes", or needs help crafting conventional commit messages. - 100create-commit-message
Generate a Conventional Commit message from staged git changes when the user asks to write a commit message, create a commit, or format a commit - 91hashiiiii-git
Use this skill to name a Git branch or write a commit message. - 96conventional-commit
Write a Conventional Commits v1.0.0 message for the current changes. Use when writing or checking a commit message or PR title.