Git commit formatter

Skill marco-souza/skills/.agents/skills/git-commit-formatter

CLI for managing AI agent skills — install, create, and share reusable SKILL.md definitions with automatic script dependency resolution

Install

npx -y skills add marco-souza/skills --skill git-commit-formatter

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Format and write git commit messages using a structured type-based format (fea, fix, ref, ai, oth). Use when the user asks to commit, stage, create a commit message, or summarize code changes. Do NOT use for merge commits, revert operations, work-in-progress commits, or when user specifies a custom format.

SKILL.md

3.0 KB, as published. Nobody here has run it

Git Commit Message Formatter

Format all commit messages using this specification.

Note: This skill uses simplified types (fea, fix, ref, ai, oth) rather than full Conventional Commits (feat, fix, refactor, chore, docs, etc.) for brevity in AI-generated messages.

Format

<type>(optional scope): <description>

All lowercase except proper nouns. No period at the end.

Types

Type	Use when
`fea`	Adding a new feature
`fix`	Fixing a bug
`ref`	Refactoring or restructuring code
`ai`	AI-related changes (prompts, models, agents)
`test`	Adding or correcting tests
`oth`	Documentation, config, or anything else

Rules

Description must be in imperative mood ("add feature", not "added feature")
No period at the end
Keep the first line under 72 characters
Add scope only when it clarifies which component changed
For breaking changes, append a footer: BREAKING CHANGE: <description>

Examples

Standard Commits

fea: add user authentication flow
fix(api): handle null response from downstream service
ref: extract validation logic into shared helper
ai: update system prompt for code review skill
oth: update README with setup instructions

Breaking Change Example

fea(api)!: remove legacy authentication endpoint

BREAKING CHANGE: /api/v1/auth endpoint removed. Use /api/v2/auth instead.

Full Workflow Example

User: "Commit my changes"

Agent:

Runs git diff --cached — sees staged changes
Identifies dominant change: new feature in auth module
Generates: fea(auth): add JWT token refresh flow
Asks: "Commit with message: fea(auth): add JWT token refresh flow?"
Runs: git commit -m "fea(auth): add JWT token refresh flow"

Process

Ensure we're in a git repository (git status)
Run git diff --cached to see staged changes
Determine the dominant type from the table above
Identify the scope if multiple components exist
Write a concise description
Ask the user to confirm or run git commit -m "<message>"

Edge Cases

No Staged Changes

If git diff --cached is empty, check git diff for unstaged changes. Ask the user if they want to:

Stage all changes: git add -A
Stage specific files: git add <files>
View changes first: git diff

Empty Repository

If git status shows "not a git repo", initialize with git init or alert the user.

Commit Failure

If git commit fails (e.g., pre-commit hook rejection), surface the error and ask if the user wants to:

Fix the issue and retry
Bypass the hook: git commit --no-verify