commit

Operate on the Git repository in the current working directory.

Refuse to run when the directory is not a Git working tree.

Refuse to run when the branch has no commits yet and the user did not ask for an initial commit.

Refuse to run when the current branch is main, master, develop, trunk, or matches the remote's default branch from git symbolic-ref --short refs/remotes/origin/HEAD — commits belong on feature branches, not protected defaults.

Override the default-branch refusal only when the user said in plain words to commit directly to that branch.

Trust the user — the changes in the working tree exist on purpose, and this skill only records them.

Do not edit source files.

Do not reformat code, run the linter, run the test suite, or start a build to "verify" the change before committing.

Verify the commit identity with git config user.email and git config user.name before composing the message.

Refuse to run when either is empty — otherwise Git attributes the commit to root@hostname or a stale default.

Inspect commit.gpgsign and gpg.format with git config --get before running git commit.

Warn the user once when signing is required but no signing key is configured locally, so the commit does not fail mid-run on a hook.

Run git status and git diff (and git diff --staged when something is already staged) before composing the message.

Describe what is on disk, not what the conversation discussed earlier.

Show the user a one-line summary of the files about to be committed and the proposed subject.

Stop and wait for the user's reply before invoking git commit, so the user can redirect the scope or the wording before the commit lands.

Stage files with one git add <path> [<path> ...] call listing every path the user named.

Never run git add -A, git add ., or git commit -a unless the user said in plain words to stage everything — those forms sweep in unrelated edits and leak secrets.

Refuse to stage files whose names match a known secret pattern: .env, .env.*, *.pem, *.key, id_rsa, id_ed25519, credentials.json, *.tfstate, *.kdbx, or any path inside .ssh/.

Refuse to stage a file whose diff introduces a credential-looking line — an AKIA/ASIA AWS key, a gh[pousr]_ GitHub token, an sk- API key, a -----BEGIN ... PRIVATE KEY----- block, or a 40+ character base64 string assigned to a secret, token, password, or key variable — and ask the user to confirm before continuing.

Format the subject as <type>(<scope>): <description> per Conventional Commits 1.0.0.

The scope is optional; the colon-space separator is mandatory.

Pick the type from the standard set: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert.

Do not invent new types.

Include a scope when every staged path sits under one package, module, or top-level directory (fix(parser): ..., feat(api): ...).

Omit the scope when the change spans unrelated areas.

Never invent a scope that does not match a directory or module name.

Append ! after the type or scope (feat!: or feat(api)!:) when the commit breaks compatibility, and add a BREAKING CHANGE: footer so tooling can detect the break from the subject alone.

Write the description in the imperative mood, lowercase, with no trailing period.

Aim for 50 characters and never exceed 72 (fix(parser): handle empty input, not Fixed the parser.).

Leave one blank line between the subject and the body, and another between the body and any footer — the parser splits the message on those blank lines.

Keep the body to a few short sentences naming the motivation and the visible effect.

Wrap body lines at 72 columns.

Omit the body when the subject already says everything — one-line commits ship.

Derive the message from the diff and the user's words, not from the branch name or a guess at intent.