| name | git-commit |
| description | Safe git commit workflow for this project. Runs relevant tests first, then proposes which files to stage and a conventional commit message, and waits for user confirmation before executing the commit. Never includes Co-Authored-By attribution. Use this skill whenever the user asks to commit, says "commit my changes", "save to git", "commit and push", or asks to wrap up / finish an iteration. Also trigger when the user types /commit or asks to commit after completing a feature.
|
Safe Git Commit Workflow
This skill gates every commit behind a test run and user confirmation. The goal is
to avoid broken commits and ensure the message accurately reflects the change.
Step 1 — Detect what changed
Run git status and git diff HEAD --name-only to see which files are modified,
staged, or untracked. Group them by area:
- src/ → backend tests
- webapp/ → frontend tests
If nothing has changed, tell the user and stop.
Step 2 — Run tests for affected areas
Run only the tests relevant to what changed. This keeps the feedback loop fast.
| Changed area | Command |
|---|
src/ | mvn test |
webapp/ | cd webapp && npm run build && npm run lint && npm test --run |
Run each applicable command. If any test run fails, stop immediately and show
the failure output. Do not proceed to staging or committing. Explain which area
failed and what the user should fix.
If all tests pass, summarise the result briefly (e.g. "✓ 111 tests passed in api
module") and continue.
Step 3 — Propose files to stage
List the files you intend to stage. Use git diff HEAD --name-only and
git ls-files --others --exclude-standard for untracked files.
Exclude files that should not be committed:
.claude/settings.local.json (personal local settings).env* filestarget/ or node_modules/ contents (should be gitignored, but flag if not)
Present the proposed file list to the user clearly. If there are files you are
unsure about, flag them and ask.
Step 4 — Generate a commit message
Analyse the diff with git diff HEAD and draft a commit message following the
project's convention:
<type>: <short description>
<optional body — bullet points describing key changes>
Types: feat, fix, refactor, docs, test, chore, perf, ci
Keep the subject line under 72 characters. Use the body to capture the why and
what when the change is non-trivial. Do not include Co-Authored-By lines.
Step 5 — Ask for confirmation
Present a summary to the user before doing anything irreversible:
Files to stage:
<list of files>
Commit message:
<type>: <subject>
<body if any>
Proceed? (yes / edit message / cancel)
Wait for the user's response:
- yes (or any affirmative) → proceed to Step 6
- edit message / user provides new message → use their version, then proceed
- cancel → stop, do nothing
Step 6 — Stage and commit
Stage only the files from Step 3 (add them individually, not with git add -A
or git add ., to avoid accidentally staging sensitive files).
Commit with the confirmed message using a heredoc to avoid shell escaping issues:
git commit -m "$(cat <<'EOF'
<type>: <subject>
<body>
EOF
)"
Do not append Co-Authored-By or any attribution footer.
After the commit, run git log --oneline -3 and show the user the result so they
can confirm everything looks correct.
Notes
- If the user asks to also push after committing, do so with
git push.
- If the user is on a new branch with no upstream, use
git push -u origin <branch>.
- If the user already staged files themselves before invoking the skill, respect
that staging and skip the "propose files" step — just show what's staged and
confirm the message.
