How do I install the Commit skill?

Run npx skillmds@latest add thkt/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.

What does the Commit skill do?

Analyze Git diff, generate a Conventional Commits format message, and run the commit. It is listed under Coding & Dev Tools on SkillMD.

Is Commit safe to use?

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

Which AI agents work with 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 Commit free to use?

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

Who published Commit?

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

Commit by thkt — Agent Skill

Name: Commit
Rating: 4.5 (4 reviews)
Author: thkt

File contents

/commit - Git Commit Execution

The manual counterpart of the commit build's Code stage takes per unit. The subject rules are the same.

Input

$ARGUMENTS may contain context or an issue reference. Trim whitespace; if empty, analyze staged changes only. If non-empty, treat it as a hint for the message scope or footer.

Execution

Run git status and git diff --staged in parallel to read the staged changes
Generate one message from the changes and $ARGUMENTS (§ Type Detection, § Rules)
Run the commit directly via the sandbox-compatible commit

Type Detection

Infer type from diff context. When it cannot be told, use chore. feat declares a semver minor bump, so do not pick it without grounds.

Type	When to use
feat	New functionality or capability
fix	Bug fix or error correction
refactor	Code restructuring without behavior change
docs	Documentation only changes
test	Adding or updating tests
chore	Config, dependencies, maintenance
perf	Performance optimization
style	Formatting, whitespace, linting
ci	CI/CD configuration changes

Rules

Assemble the message as <type>(<scope>): <subject>. A breaking change takes a ! after the type, as in feat(api)!:. The table below decides the rule for each part.

Part	Rule
Subject	72 chars or fewer, imperative, lowercase, no trailing period
Body	The why the diff cannot show, such as motivation or rationale. Omit when obvious
Footer	`BREAKING CHANGE:`, `Closes #123`, `Co-authored-by:`

Sandbox-Compatible Commit

Confirm the target repository with the leading git rev-parse --show-toplevel.

git rev-parse --show-toplevel
cat > "$TMPDIR/commit-msg.txt" << 'EOF'
<message>
EOF
git commit -F "$TMPDIR/commit-msg.txt"

Error Handling

Error	Treatment
No staged files	Do not commit; report that the stage is empty
Empty diff	Commit with a minimal message
No git repository	Do not commit; report that this is not a git repo
Repository is not the one intended	Do not commit; report the `git rev-parse --show-toplevel` output
Pre-commit failed	Report the hook output as it stands. The user decides whether to retry

---name: commitdescription: Analyze Git diff, generate a Conventional Commits format message, and run the commit.---# /commit - Git Commit ExecutionThe manual counterpart of the commit build's Code stage takes per unit. The subject rules are the same.## Input`$ARGUMENTS` may contain context or an issue reference. Trim whitespace; if empty, analyze staged changes only. If non-empty, treat it as a hint for the message scope or footer.## Execution1. Run `git status` and `git diff --staged` in parallel to read the staged changes2. Generate one message from the changes and `$ARGUMENTS` (§ Type Detection, § Rules)3. Run the commit directly via the sandbox-compatible commit## Type DetectionInfer type from diff context. When it cannot be told, use chore. feat declares a semver minor bump, so do not pick it without grounds.| Type | When to use || -------- | ------------------------------------------ || feat | New functionality or capability || fix | Bug fix or error correction || refactor | Code restructuring without behavior change || docs | Documentation only changes || test | Adding or updating tests || chore | Config, dependencies, maintenance || perf | Performance optimization || style | Formatting, whitespace, linting || ci | CI/CD configuration changes |## RulesAssemble the message as `<type>(<scope>): <subject>`. A breaking change takes a `!` after the type, as in `feat(api)!:`. The table below decides the rule for each part.| Part | Rule || ------- | -------------------------------------------------------------------------------- || Subject | 72 chars or fewer, imperative, lowercase, no trailing period || Body | The why the diff cannot show, such as motivation or rationale. Omit when obvious || Footer | `BREAKING CHANGE:`, `Closes #123`, `Co-authored-by:` |## Sandbox-Compatible CommitConfirm the target repository with the leading `git rev-parse --show-toplevel`.```bashgit rev-parse --show-toplevelcat > "$TMPDIR/commit-msg.txt" << 'EOF'<message>EOFgit commit -F "$TMPDIR/commit-msg.txt"```## Error Handling| Error | Treatment || ---------------------------------- | ---------------------------------------------------------------------- || No staged files | Do not commit; report that the stage is empty || Empty diff | Commit with a minimal message || No git repository | Do not commit; report that this is not a git repo || Repository is not the one intended | Do not commit; report the `git rev-parse --show-toplevel` output || Pre-commit failed | Report the hook output as it stands. The user decides whether to retry |

Frequently asked questions

Commit