What is write-conventional-commit?

A guide for writing Git commit messages in Conventional Commits format, a shared naming style such as `fix:` or `feat:` that explains the kind of change being recorded.

Use it to draft or apply commit messages for bug fixes, features, refactors, tests, documentation, build changes, maintenance, reverts, and breaking changes.

It helps commit history stay consistent and makes changes easier to scan, categorize, and use with release tooling.

write-conventional-commit — Skill for Codex by ragnarok22/agent-skills

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent

npx skills add ragnarok22/agent-skills --skill write-conventional-commit

Clone the repo

git clone --depth 1 https://github.com/ragnarok22/agent-skills

Made for: Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/skills/ragnarok22/agent-skills/write-conventional-commit/github.svg)](https://agentmods.dev/skills/ragnarok22/agent-skills/write-conventional-commit)

Your own site

<a href="https://agentmods.dev/skills/ragnarok22/agent-skills/write-conventional-commit"><img src="https://agentmods.dev/badge/skills/ragnarok22/agent-skills/write-conventional-commit/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/skills/ragnarok22/agent-skills/write-conventional-commit"><img src="https://agentmods.dev/badge/skills/ragnarok22/agent-skills/write-conventional-commit.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 76 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.

When invoked 881 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00076	$0.00881
Opus 5.5	$0.00030	$0.00352
Sonnet 5.5	$0.00015	$0.00176
Haiku 4.5	$0.00008	$0.00088

Measured 2mo ago against content hash c49c6b45f451, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

write-conventional-commit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/write-conventional-commit/SKILL.md · 139 lines

How it starts

The opening of the file, as written. The whole thing — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.

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.

Read the full file on GitHub · 139 lines

Files

What ships with it

3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

2mo ago First seen · 139 lines · 76 tokens per session scan A c49c6b45f451

Subscribe to this mod's changes

write-conventional-commit is a skill published in the GitHub repository ragnarok22/agent-skills (5 stars, last pushed 4mo ago), licensed MIT. It adds 76 tokens to every session and 881 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Commits Git and workflow

create-pr

Creates a GitHub PR with a Linear-ticket-prefixed title and a decision-led, narrative description for Prisma 8. Use when the user wants to create a pull request, open a PR, or submit changes for review.

prisma/orm · 48 tokens

git-commit

Generate well-formatted git commit messages following conventional commit standards.

ThinkInAIXYZ/deepchat · 15 tokens

repo-sync

Manage automatic Git syncing on macOS with repo-sync. Use only when the user explicitly invokes /repo-sync.

davidondrej/skills · 25 tokens

mcore-split-pr

Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.

NVIDIA/skills · 25 tokens

engineer-bot-ops

A workflow for carrying an engineering task from scope through implementation and reviewable delivery. It works with a repository's branch, existing changes, rules, checks, and permissions while separating completed, unverified, and next-step work.

makecindy/cindy · 57 tokens

contributing

How to contribute to evlog, covering commit and PR conventions, changesets, the Definition of Done, testing rules, and the authored skills that walk through building a new adapter, enricher, framework integration, or map rule. Load this for any question about contributing, opening a PR, or adding something to the…

HugoRCD/evlog · 68 tokens