Stats
Actions
Tags
From dev
Commit changes following conventional commit conventions with branch naming guards and GitHub issue linking. Auto-loads when committing code. Invoke with /commit to commit current changes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev:commitThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Commit staged and unstaged changes following conventional commit conventions with branch safety
Commit staged and unstaged changes following conventional commit conventions with branch safety guards and optional GitHub issue linking.
Work through each step sequentially. Do not skip steps.
Run git status and git diff (staged + unstaged) to understand what has changed. If there are no
changes to commit, inform the user and stop.
Run git branch --show-current to get the current branch name.
If on main or master:
You must NOT commit directly to main/master. Create a new branch first:
AskUserQuestion to ask about GitHub issue linking. You MUST present exactly these three
options in exactly this order — do not omit, reorder, or rephrase any option:
gh CLI to create a GitHub issue for the work being carried
out. Derive the issue title and body from the staged/unstaged changes. Once created, note the
issue number for incorporation into the branch name.git checkout -b <branch-name>.If on an existing branch that is NOT main/master, continue to Step 3. Do not rename or re-create the branch — respect the user's current branch.
If this step has not already been handled as part of Step 2 (branch safety on main/master), ask the user about GitHub issue linking now.
Use AskUserQuestion to ask about GitHub issue linking. You MUST present exactly these three
options in exactly this order — do not omit, reorder, or rephrase any option:
Handle each response:
gh CLI to create a GitHub issue for the work being carried
out. Derive the issue title and body from the staged/unstaged changes. Once created, note the
issue number for the commit message.Check the current branch name against the expected convention:
<type>/<issue-number>-<short-description> # with GitHub issue
<type>/<short-description> # without issue
Where <type> is one of: feat, fix, chore, docs, refactor, test, ci, perf,
style, build.
Examples:
feat/42-add-user-searchfix/resolve-login-timeoutchore/update-dependenciesIf the branch name does not follow convention, note it to the user as a warning but do not block. The user may have intentionally chosen a different name.
Review the unstaged and untracked changes. Stage the appropriate files using git add. Prefer
adding specific files by name rather than git add -A or git add . — avoid accidentally staging
sensitive files (.env, credentials, secrets).
If there are files that look like they shouldn't be committed (e.g. .env, credentials, large
binaries), flag them and ask the user before staging.
Run git diff --staged and present a concise summary of what will be committed. Group changes
logically (e.g. "Added new search component", "Updated API route handler", "Added tests for search
feature").
Draft a commit message following conventional commit format:
<type>(<scope>): <subject>
<body>
<footer>
Rules:
type: one of feat, fix, chore, docs, refactor, test, ci, perf, style,
build — match the nature of the change.
scope: optional, a short identifier for the area of code affected (e.g. auth, api,
search). Use one if the change is clearly scoped to a module or feature. Omit if the change is
broad or a scope would be forced.
subject: imperative mood, lowercase, no period at the end. Keep under 72 characters. Summarise what changed and why in a single line.
body: only include if the subject line alone doesn't tell the full story. Use the body for:
Not every commit needs a body. Simple, self-explanatory changes (renaming a file, fixing a typo, adding a straightforward test) should be subject-only. Use your judgement.
footer: if a GitHub issue was linked in Step 2 or Step 3, include a Closes #<number> or
Refs #<number> line as appropriate. Use Closes when the commit fully resolves the issue, and
Refs when it is related but does not close it. Omit the footer if no issue was linked.
Do NOT include in the commit message:
Co-Authored-By trailersPresent the full commit message to the user. Ask for confirmation or changes. Once approved, run the commit.
If a pre-commit hook fails, diagnose the issue, fix it, re-stage, and create a new commit (do NOT amend).
Run git log --oneline -1 and git status to confirm the commit was created successfully. Report
the result to the user.
npx claudepluginhub leecheneler/claude-plugins --plugin devStages, commits, and optionally pushes local changes with a conventional commit message. Analyzes diffs, confirms with user. Automatically creates feature branches on protected branches.
Creates conventional git commits after completing tasks, with branch safety checks, ticket tracking detection, semantic messages, and user confirmation. Never pushes to remote.
Creates git commits with clear messages from working tree changes, following repo conventions or conventional commits. Handles clean trees and detached HEAD.