commit

Creates grouped git commits following Conventional Commits format with safety checks.

Updated Nov 20, 2025
One-click install
npx skills add https://github.com/apuya/react-basics-ui --skill commit-apuya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: commit
Source: https://github.com/apuya/react-basics-ui/tree/main/.claude/skills/commit
Command: npx skills add https://github.com/apuya/react-basics-ui --skill commit-apuya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing consistent, well-scoped git commit messages and grouping related changes into clean commits is tedious and error-prone, especially when sessions produce many mixed changes. ## Core Features & Use Cases - Conventional Commits formatting: Generates type(scope): subject messages with proper verbs, bodies, and footers, matching the repo's recent commit style. - Commit grouping by concern: Splits changes into separate feat, refactor, test, and docs commits, staging files by name instead of git add .. - Safety guardrails: Detects pre-commit hooks (husky, lint-staged, commitlint), warns about sensitive files like .env or private keys, and never amends or force-pushes without explicit approval. - Use Case: After refactoring a Select component and adding tests, ask the assistant to commit; it inspects git status and git diff, then produces separate commits like refactor(select): extract shared styles and test(select): cover keyboard navigation. ## Quick Start Ask the assistant to review what changed and commit the current work following the project's commit conventions.

Frequently Asked Questions about commit

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Conventional Commits message?

Use the format `type(scope): subject` with a lowercase imperative verb, such as `feat(select): add multi-select mode`. Keep the subject under 72 characters, add a body for non-trivial motivation, and use a footer only for breaking changes or issue references.

How do I split many changes into multiple git commits?

Group changes by concern — feature, refactor, tests, docs — and stage files by name for each group rather than using `git add .`. A typical order is feat, then refactor, then test, then docs, so each commit covers one concern.

What should I do when a pre-commit hook fails?

Read the hook's error output, report the failure details, fix the underlying issues, re-stage the files, and create a new commit. Never amend the failed commit or bypass the hook with `--no-verify` unless explicitly requested.

Which files should never be committed to git?

Never commit `.env` files, `credentials.json`, service account JSON, private keys (`*.pem`, `*.key`, `*.p12`), files named with `secret`, auth tokens, or `.npmrc` files containing `_authToken`. Also warn if a gitignored file has been staged.

When should I not amend a git commit?

Never amend without an explicit user request, and never amend commits that have already been published or pushed. Amending rewrites history, which breaks collaborators' clones and can lose work silently.