commit

name	commit
description	Stage and commit changes using Lucas's conventional commit style. Use this skill whenever the user runs /commit, asks to "commit changes", "make a commit", "git commit", "stage and commit", or wants to save their current work to git. Always invoke this skill before doing any git add or git commit work.
argument-hint	[instruction]

Commit Skill

Stage and commit changes following the project's conventional commit style.

Arguments

/commit [instruction] — optional free-text instruction that modifies behavior. Examples:

• /commit only frontend — only stage and commit files under frontend/
• /commit don't push — commit but skip pushing to remote
• /commit skip cherry-pick — commit and push current branch only, don't sync sibling branches
• /commit message: my custom message — use the provided text as the commit message (still apply type prefix formatting)
• /commit squash last 3 — squash the last 3 commits into one before pushing

When an instruction is provided, follow it and override the default steps where it conflicts. The instruction takes priority over all defaults below.

Commit Message Format

<type>(<scope>): <title>

<optional description body>

• type: pick the one that best describes the nature of the change
  • feat — new feature or behavior added
  • fix — corrects a bug or broken behavior
  • refactor — restructuring without functional change
  • docs — documentation only (spec, README, comments-only edits)
  • chore — build, deps, tooling, config, housekeeping that isn't user-facing
  • test — adding or fixing tests with no functional change
  • perf — performance improvement without functional change
  • style — formatting / lint-only changes
  • revert — reverting a previous commit
  • merge — integration of one branch into another (use only on actual merge commits)
• scope (in parens, lowercase): the primary module / subsystem touched — e.g. api, workers, client, backtest, slm, db, ci, spec, tasks, deps. Pick the single most-affected area; if a change genuinely spans two equally, write feat(api+workers):. If the change is truly cross-cutting (e.g. a repo-wide rename), omit the scope and use <type>: <title>. Default behavior is to always include a scope — only omit when there is no meaningful single subsystem.
• title: lowercase, imperative mood, concise but specific — describe what changed, not how. Stays on one line.
• description body (optional): use when the title alone leaves out context worth keeping — e.g. benchmark deltas, tradeoffs taken, "why now," notable side effects. Keep it tight. Skip it when the title fully explains the change.
• No footer, no Co-Authored-By, no emoji, no issue references

Examples:

feat(backtest): edge-novelty filter — only edges with valid_from within N days fire
fix(api): expose advanced backtest knobs in BacktestConfig schema
docs(spec): record embedding-resolver win in baseline spec
chore(deps): bump sentence-transformers to 3.0.1
refactor(workers): split backtest.py into _backtest_loop + _backtest_signs
merge(develop): feat/embeddings-slm-triplets → develop | tier-3 SLM hints + embeddings

Steps

1. Check status — run git status and git diff to understand what changed
2. Stage files — add the relevant changed files by name (prefer explicit paths over git add -A to avoid accidentally including sensitive files like .env)
   • If the user specified which files to commit, use those
   • If not, add all tracked modified files (git add -u) unless there are clearly unrelated changes that should be separate commits
3. Craft the message — read the diff carefully and write a message that:
   • Picks the right type (feat, fix, refactor, docs, chore, test, perf, style, revert, merge)
   • Picks the right scope from the changed paths (e.g. client/ → (client), api/ → (api), workers/ → (workers), spec/ → (spec)); omit scope only if the change is genuinely cross-cutting
   • Describes the actual change in clear terms
   • Lists multiple key changes separated by commas if the commit touches multiple things
   • Title stays on one line, lowercase after the colon
   • Adds a description body only when the title alone misses important context (metrics, constraints, "why now"); otherwise leave it off
4. Commit — run git commit -m "<title>" for title-only commits, or use a HEREDOC for title + body:

   git commit -m "$(cat <<'EOF'
   <type>(<scope>): <title>
   
   <description body>
   EOF
   )"
   

5. Confirm — show the user the resulting commit hash and message

Remote Repos

After committing, always push to the remote:

1. Push current branch — run git push (or git push -u origin <branch> if no upstream is set)
2. Sibling branches — if the project has related branches that should stay in sync (check CLAUDE.md for branch strategy), cherry-pick the commit to those branches and push them too, then return to the original branch
3. Protected branches — do NOT push to main/master unless the user explicitly asks

What NOT to do

• Don't add Co-Authored-By lines
• Don't write a body just to restate the title — only add one when it carries information the title doesn't
• Don't use emoji
• Don't reference issue/PR numbers unless the user explicitly asks
• Don't use git add . or git add -A — prefer explicit files or git add -u
• Don't ask the user to confirm the message unless something is genuinely ambiguous about what changed
• Don't push to main/master unless explicitly asked
• Don't force push (--force) unless explicitly asked