name	commit-discipline
description	How to structure commits: atomic, conventional messages, never push to main/master directly.

Commit discipline

Run this whenever committing changes, opening a PR, or when asked to "commit this" / "push this."

Commits are atomic: one logical change per commit. If a task touched two unrelated things (e.g. a bug fix and an unrelated formatting pass), split into separate commits rather than bundling them.
Commit messages follow conventional-commit style: type(scope): summary, where type is one of feat, fix, refactor, test, docs, chore, style, perf. Summary is imperative mood ("add", not "added" or "adds"), under ~72 chars on the first line. Add a body only if the "why" isn't obvious from the summary and diff.
Never commit directly to main or master. If already on main/master, create a branch first and say which branch name you're using before committing.
Never force-push to a shared branch unless explicitly told to.
Never commit files matching common secret patterns (.env, *.pem, _key, credentials.) even if they were staged by something else — flag them and stop instead of committing silently.
Never use git add . or git add -A blindly. Review what's staged (git status) and add specific files. If genuinely everything changed is meant to be committed, say so explicitly in the report rather than defaulting to it.
After committing, show the commit hash and message, and confirm the branch. Do not push unless explicitly asked to.

If the working tree has unrelated uncommitted changes from a previous session mixed in with the current task's changes: stop and ask which files belong to this commit rather than guessing.
If a repo has its own CONTRIBUTING.md or commit convention documented, defer to that over this skill's defaults and say so.
If a pre-commit hook fails: report the failure verbatim, do not bypass with --no-verify unless explicitly told to.

name	commit-discipline
description	How to structure commits: atomic, conventional messages, never push to main/master directly.

Run this whenever committing changes, opening a PR, or when asked to "commit this" / "push this."

Commits are atomic: one logical change per commit. If a task touched two unrelated things (e.g. a bug fix and an unrelated formatting pass), split into separate commits rather than bundling them.
Commit messages follow conventional-commit style: type(scope): summary, where type is one of feat, fix, refactor, test, docs, chore, style, perf. Summary is imperative mood ("add", not "added" or "adds"), under ~72 chars on the first line. Add a body only if the "why" isn't obvious from the summary and diff.
Never commit directly to main or master. If already on main/master, create a branch first and say which branch name you're using before committing.
Never force-push to a shared branch unless explicitly told to.
Never commit files matching common secret patterns (.env, *.pem, _key, credentials.) even if they were staged by something else — flag them and stop instead of committing silently.
Never use git add . or git add -A blindly. Review what's staged (git status) and add specific files. If genuinely everything changed is meant to be committed, say so explicitly in the report rather than defaulting to it.
After committing, show the commit hash and message, and confirm the branch. Do not push unless explicitly asked to.

If the working tree has unrelated uncommitted changes from a previous session mixed in with the current task's changes: stop and ask which files belong to this commit rather than guessing.
If a repo has its own CONTRIBUTING.md or commit convention documented, defer to that over this skill's defaults and say so.
If a pre-commit hook fails: report the failure verbatim, do not bypass with --no-verify unless explicitly told to.

commit-discipline