Run any Skill in Manus with one click

conventional-commits

Stars1

Forks1

UpdatedJune 10, 2026 at 10:25

Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

jnMetaCode

jnMetaCode/skillet

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	conventional-commits
description	Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.
version	1.0.0
license	MIT
keywords	["git","commits","conventional-commits","changelog","workflow"]

conventional-commits

Write the message from the diff, not from the conversation. The reader is a stranger running git log in two years.

Procedure

Read what is actually staged: git diff --cached --stat then the diff itself.
Classify the change — pick ONE primary type:
- feat new user-visible capability · fix corrects wrong behavior
- refactor no behavior change · perf faster, same behavior
- docs · test · build · ci · chore (only when nothing else fits)
Scope = the subsystem a reader would filter by: feat(parser): …. Omit if the repo doesn't use scopes (check git log --oneline -20 and match style).
Subject line: imperative, lowercase, no period, ≤ 72 chars, and it must state the effect, not the activity — "fix: reject expired tokens" not "fix: update token check".
Body (when the why isn't obvious): 1–3 sentences on why the change was needed and any non-obvious consequence. Wrap at 72. Never narrate the diff.
Breaking change → footer BREAKING CHANGE: <what breaks and the migration>, and add ! after the type: feat(api)!: ….

Anti-patterns to reject

One commit doing two unrelated things — split it (git add -p).
"update", "misc fixes", "address comments" — say what changed.
Restating the conversation ("as discussed…") — the log has no conversation.
Explaining that the change is correct — that belongs in the PR, not the log.

Example

fix(ingest): treat mtime regressions as edits, not new files

Restored backups can move mtime backwards; we indexed those as fresh
documents, duplicating every chunk. Key on inode+path instead.

More from this repository

same repository

self-evolve

jnMetaCode/skillet

Make the agent improve with every task — review the run, distill lessons into durable memory, and reinforce what worked. Use at the end of any non-trivial task, or when the user asks the agent to "learn from this".

2026-06-101

incident-postmortem

jnMetaCode/skillet

Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.

2026-06-101

pr-description

jnMetaCode/skillet

Write a reviewer-first pull-request description from the actual branch diff. Use when opening a PR or asked to write/improve a PR description.

2026-06-101

systematic-debugging

jnMetaCode/skillet

Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.

2026-06-101

test-writing

jnMetaCode/skillet

Write tests that catch real regressions — behavior-focused, minimal mocking, edge cases chosen from the code's actual branches. Use when adding tests for new code or backfilling tests for a fix.

2026-06-101

changelog

jnMetaCode/skillet

Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…".

2026-06-101

name	conventional-commits
description	Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.
version	1.0.0
license	MIT
keywords	["git","commits","conventional-commits","changelog","workflow"]

conventional-commits

Write the message from the diff, not from the conversation. The reader is a stranger running git log in two years.

Procedure

Read what is actually staged: git diff --cached --stat then the diff itself.
Classify the change — pick ONE primary type:
- feat new user-visible capability · fix corrects wrong behavior
- refactor no behavior change · perf faster, same behavior
- docs · test · build · ci · chore (only when nothing else fits)
Scope = the subsystem a reader would filter by: feat(parser): …. Omit if the repo doesn't use scopes (check git log --oneline -20 and match style).
Subject line: imperative, lowercase, no period, ≤ 72 chars, and it must state the effect, not the activity — "fix: reject expired tokens" not "fix: update token check".
Body (when the why isn't obvious): 1–3 sentences on why the change was needed and any non-obvious consequence. Wrap at 72. Never narrate the diff.
Breaking change → footer BREAKING CHANGE: <what breaks and the migration>, and add ! after the type: feat(api)!: ….

Anti-patterns to reject

One commit doing two unrelated things — split it (git add -p).
"update", "misc fixes", "address comments" — say what changed.
Restating the conversation ("as discussed…") — the log has no conversation.
Explaining that the change is correct — that belongs in the PR, not the log.

Example

fix(ingest): treat mtime regressions as edits, not new files

Restored backups can move mtime backwards; we indexed those as fresh
documents, duplicating every chunk. Key on inode+path instead.