| name | commit |
| description | Use this skill whenever the user types /commit or asks to "commit changes", "make a commit", "commit my work", or similar. Reads the current git branch state, diffs against the target branch (pulling latest first), drafts a well-structured conventional commit message, confirms with the user before pushing. Never adds "Co-Authored-by" lines. Always follow this skill for any commit workflow — do not improvise a different approach.
|
/commit — Smart Commit Workflow
Overview
This skill handles the full commit lifecycle: inspect → message → confirm → push.
Never commit without explicit user approval. Never include "Co-Authored-by" or any AI attribution.
Step 1 — Determine target branch
git remote show origin | grep "HEAD branch"
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
Typical target is main or master. If ambiguous, ask the user once.
Step 2 — Pull latest on target branch
Fetch without switching:
git fetch origin <target-branch>
Do NOT git checkout — stay on the current branch.
Step 3 — Inspect changes
git status --short
git diff origin/<target-branch>...HEAD --stat
git diff origin/<target-branch>...HEAD
Also check for unstaged or untracked files and mention them to the user if they exist but aren't staged.
Step 4 — Stage changes (if needed)
If nothing is staged, stage all tracked modifications:
git add -u
If there are untracked files the user likely wants included, ask whether to add them.
Step 5 — Write the commit message
Follow Conventional Commits strictly.
Format
<type>(<scope>): <short summary>
<body — what changed and why>
<footer — breaking changes, issue refs if relevant>
Types
| Type | When to use |
|---|
feat | New feature or capability |
fix | Bug fix |
refactor | Code restructure, no behavior change |
perf | Performance improvement |
test | Adding or updating tests |
docs | Documentation only |
chore | Build, tooling, dependency updates |
ci | CI/CD changes |
style | Formatting, whitespace, no logic change |
Rules for the summary line
- Imperative mood: "add X" not "added X" or "adds X"
- Lowercase after the colon
- No trailing period
- ≤ 72 characters total
Body rules
- Explain what and why, not how
- Use bullet points for multiple distinct changes
- Skip if the summary is self-explanatory for a tiny change
Footer rules
BREAKING CHANGE: <description> if applicableCloses #<issue> / Fixes #<issue> if relevant- Never include
Co-Authored-by, Generated by, or any AI attribution
Examples
feat(eval): add 14-metric weighted LLM-as-a-judge scoring system
Replace the previous 4-metric abstract evaluator with a comprehensive
scoring framework covering:
- conversation quality and goal achievement
- tool call accuracy and timing
- STT/TTS pipeline correctness
- latency and error handling metrics
Weighted scoring allows per-scenario tuning via YAML config.
fix(pipeline): resolve dangling async tasks on ServiceSwitcher teardown
Tasks were not cancelled when the switcher received a disconnect event,
causing CPU spikes under load. Added explicit cancellation in
`_on_disconnect` and a grace-period join.
Closes #312
chore(deps): upgrade pipecat 0.0.95 → 0.0.100
Step 6 — Present and confirm
Show the user the full proposed commit message in a code block. Ask:
"Does this commit message look good, or would you like to adjust anything before I push?"
Wait for explicit approval ("yes", "lgtm", "go ahead", "push it", or similar).
If they request changes, revise and re-confirm. Do not proceed until approved.
Step 7 — Commit and push
git commit -m "<subject>" -m "<body>"
git push origin <current-branch>
If the body is multi-paragraph, use multiple -m flags or a heredoc.
Report success with the commit hash and remote URL.
Edge Cases
- Nothing to commit: Report it clearly, don't error out silently.
- Merge conflicts or diverged branches: Surface the issue and stop; don't try to resolve automatically.
- Detached HEAD: Warn the user and ask how to proceed.
- First push on a new branch: Use
git push -u origin <branch>.
