How do I install the Write Conventional Commit skill?

Run npx skillmds@latest add ragnarok22/write-conventional-commit in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Write Conventional Commit safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Write Conventional Commit?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Write Conventional Commit free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Write Conventional Commit?

ragnarok22 (@ragnarok22) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Write Conventional Commit by ragnarok22

Name: Write Conventional Commit
Rating: 4.5 (4 reviews)
Author: ragnarok22

Write Conventional Commit

Create Git commit messages that conform to Conventional Commits 1.0.0, including type/scope/description format, optional body, trailer-style footers, and explicit BREAKING CHANGE signaling. Use when users ask to draft commit messages, commit current changes, rewrite a commit message into conventional format, or enforce conventional commit standards in a repo.

ragnarok22 Updated Sep 10, 2026

File contents

Write Conventional Commit

Generate and apply Conventional Commits that follow the 1.0.0 specification.

Workflow

Step 1: Inspect commit scope

Run from repository root:

git status --short
git diff --staged --name-only
git diff --name-only

Use staged changes when available. If nothing is staged and the user asked to commit now, stage intentionally relevant files first and state what was staged.

Step 2: Classify intent into commit type

Pick the best type from change intent, not from file extension.

Common types:

feat: add a user-facing feature
fix: fix a bug
refactor: code change without new feature or bug fix
perf: improve performance
docs: documentation only
test: add/update tests
build: build/dependency tooling
ci: CI/CD configuration
chore: maintenance that does not fit above
revert: revert a previous commit

If uncertain between feat and fix, prefer:

fix when correcting broken behavior
feat when adding new behavior

Step 3: Choose optional scope

Scope is optional and should be short and stable.

Prefer one of:

top-level package/app (api, billing, auth)
subsystem (migrations, deps, release)
user-visible surface (checkout, search)

Avoid broad scopes like misc.

Step 4: Detect breaking changes

Mark breaking changes when diff indicates incompatible API/contract behavior.

Signals include:

removed/renamed public endpoints, fields, events, CLI flags
required inputs changed incompatibly
output schema changed incompatibly

When breaking:

Add ! after type or type+scope (feat!: or feat(api)!:)
Add footer: BREAKING CHANGE: <what changed and how to migrate>

Use both when possible for clarity.

Step 5: Compose message in spec format

Use this structure exactly:

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

Formatting rules:

Header type must be lowercase noun.
Put a colon and single space after header prefix.
Keep description concise and specific.
Put one blank line between header and body.
Put one blank line between body and footers.
Footer tokens follow git trailer style (Token: value), except references may use Token #value.
Use BREAKING CHANGE: as the canonical breaking footer token.

Step 6: Create commit (when requested)

If user wants the commit executed, run non-interactively:

git commit -m "<header>" -m "<body>" -m "<footer1>" -m "<footer2>"

Only include -m blocks that are needed.

For multiline body/footer with precise formatting, use:

git commit -F /tmp/commit-msg.txt

Then report:

final commit header
commit hash
whether breaking change was marked

Quality checks

Before finalizing, verify:

Header matches <type>[scope][!]: description
Type reflects intent correctly
Scope is helpful or omitted
Breaking changes are explicitly marked when applicable
Body explains why when context is not obvious
Footers are valid trailers and references are accurate

Output behavior

When user asks only for message suggestions, provide 1 recommended message and up to 2 alternatives.

When user asks to commit directly, proceed with staging/commit commands and then return commit result.

Reference

Read references/conventional-commits-1.0.0.md for the normative checklist and examples.

---name: write-conventional-commitdescription: Create Git commit messages that conform to Conventional Commits 1.0.0, including type/scope/description format, optional body, trailer-style footers, and explicit BREAKING CHANGE signaling. Use when users ask to draft commit messages, commit current changes, rewrite a commit message into conventional format, or enforce conventional commit standards in a repo.---# Write Conventional CommitGenerate and apply Conventional Commits that follow the 1.0.0 specification.## Workflow### Step 1: Inspect commit scopeRun from repository root:```bashgit status --shortgit diff --staged --name-onlygit diff --name-only```Use staged changes when available. If nothing is staged and the user asked to commit now, stage intentionally relevant files first and state what was staged.### Step 2: Classify intent into commit typePick the best type from change intent, not from file extension.Common types:- `feat`: add a user-facing feature- `fix`: fix a bug- `refactor`: code change without new feature or bug fix- `perf`: improve performance- `docs`: documentation only- `test`: add/update tests- `build`: build/dependency tooling- `ci`: CI/CD configuration- `chore`: maintenance that does not fit above- `revert`: revert a previous commitIf uncertain between `feat` and `fix`, prefer:- `fix` when correcting broken behavior- `feat` when adding new behavior### Step 3: Choose optional scopeScope is optional and should be short and stable.Prefer one of:- top-level package/app (`api`, `billing`, `auth`)- subsystem (`migrations`, `deps`, `release`)- user-visible surface (`checkout`, `search`)Avoid broad scopes like `misc`.### Step 4: Detect breaking changesMark breaking changes when diff indicates incompatible API/contract behavior.Signals include:- removed/renamed public endpoints, fields, events, CLI flags- required inputs changed incompatibly- output schema changed incompatiblyWhen breaking:1. Add `!` after type or type+scope (`feat!:` or `feat(api)!:`)2. Add footer: `BREAKING CHANGE: <what changed and how to migrate>`Use both when possible for clarity.### Step 5: Compose message in spec formatUse this structure exactly:```text<type>[optional scope][!]: <description>[optional body][optional footer(s)]```Formatting rules:- Header type must be lowercase noun.- Put a colon and single space after header prefix.- Keep description concise and specific.- Put one blank line between header and body.- Put one blank line between body and footers.- Footer tokens follow git trailer style (`Token: value`), except references may use `Token #value`.- Use `BREAKING CHANGE:` as the canonical breaking footer token.### Step 6: Create commit (when requested)If user wants the commit executed, run non-interactively:```bashgit commit -m "<header>" -m "<body>" -m "<footer1>" -m "<footer2>"```Only include `-m` blocks that are needed.For multiline body/footer with precise formatting, use:```bashgit commit -F /tmp/commit-msg.txt```Then report:- final commit header- commit hash- whether breaking change was marked## Quality checksBefore finalizing, verify:- Header matches `<type>[scope][!]: description`- Type reflects intent correctly- Scope is helpful or omitted- Breaking changes are explicitly marked when applicable- Body explains why when context is not obvious- Footers are valid trailers and references are accurate## Output behaviorWhen user asks only for message suggestions, provide 1 recommended message and up to 2 alternatives.When user asks to commit directly, proceed with staging/commit commands and then return commit result.## ReferenceRead [references/conventional-commits-1.0.0.md](references/conventional-commits-1.0.0.md) for the normative checklist and examples.

Frequently asked questions

Write Conventional Commit

File contents

Write Conventional Commit

Workflow

Step 1: Inspect commit scope

Step 2: Classify intent into commit type

Step 3: Choose optional scope

Step 4: Detect breaking changes

Step 5: Compose message in spec format

Step 6: Create commit (when requested)

Quality checks

Output behavior

Reference

Related skills

Frequently asked questions

How do I install the Write Conventional Commit skill?

What does the Write Conventional Commit skill do?

Is Write Conventional Commit safe to use?

Which AI agents work with Write Conventional Commit?

Is Write Conventional Commit free to use?

Who published Write Conventional Commit?