git-commit

name

git-commit

description

Use for any request to record work as a git commit, however casual or indirect the wording — "commit", "commit the changes", "git commit", "/commit", "save this to git", "stage everything and commit", or a commit implied by a larger task ("wrap this up and commit"). Always route commits through this skill rather than running `git commit` directly, so the message uses Conventional Commits format with the Assisted-by trailer.

Git Commit

Turn working changes into clean, well-attributed git commits:

1. The message follows the Conventional Commits shape: type(scope): description.
2. The footer carries an Assisted-by: trailer naming the AI agent and model that helped — disclosure per the Linux kernel's AI Coding Assistants policy, so git log/git blame stay an honest record.

Workflow

1. Understand the current state

Inspect the repository state and conventions in one batch:

git status --porcelain -b
git --no-pager diff --staged
git --no-pager diff
git --no-pager log --oneline -10

2. Decide what goes in the commit

• If the user already staged specific files, respect that — commit what they staged unless they ask otherwise.
• If nothing is staged, stage deliberately. Prefer naming paths (git add src/foo.ts) over git add -A.
• Aim for one logical, independently reviewable change per commit, and leave the repo in a working state after each one.
• If the working tree mixes multiple complex unrelated changes, don't cram them into one commit. Split them into separate, scoped commits.
• If there's nothing to commit (clean tree, or nothing staged and nothing worth staging), stop and tell the user instead of forcing an empty commit.
• Never stage things that don't belong in history: secrets, .env files, build artifacts

3. Draft the commit message

type(scope): description

body

optional footers
trailers

Description line (type(scope): description)

• type — whichever best describes the change (see table below).
• scope — optional short noun for the area touched (auth, api, chart). Use one if the repo does; omit if it'd be noise.
• description — what changed, in imperative present tense ("Add", not "Added"/"Adds"), starting uppercase, no trailing period, aim ≤ 50 chars (hard ceiling ~72).

Types

Type	Purpose
feat	New feature
fix	Bug fix
docs	Documentation only
refactor	Code refactor with no feature or fix
style	Formatting/style with no logic change
perf	Performance improvement
test	Test additions or updates
build	Build system or dependency changes
ci	CI configuration
revert	Reverting a previous commit
chore	Maintenance that fits no other type

Body

Explain the what and especially the why, not the how (the diff shows how). Wrap around 72 columns. Skip the body for changes that are self-explanatory from the description — the trailer stays even then:

fix: Prevent crash when forecast list is empty

Assisted-by: Zed:openai-gpt-5-5

Breaking changes

Append ! after the type/scope and add a BREAKING CHANGE: footer describing the migration:

refactor(api)!: Drop the deprecated /v1/forecast endpoint

BREAKING CHANGE: clients must migrate to /v2/forecast, which returns
per-model arrays instead of a single averaged series.

Assisted-by: ClaudeCode:claude-opus-4-8

Attribution trailer

Every commit gets an Assisted-by: AGENT_NAME:MODEL_VERSION trailer (e.g. Assisted-by: ClaudeCode:claude-opus-4-8).

• AGENT_NAME — the AI tool/framework, no spaces (ClaudeCode for Claude Code, otherwise the harness name, e.g. Zed).
• MODEL_VERSION — the exact model ID you're running as, not a friendly name (e.g. claude-opus-4-8).

The Assisted-by: trailer is the only AI attribution that belongs in a commit. Never add other AI markers: no "Generated by AI", "🤖 Generated with Claude Code", and no Co-Authored-By: Claude trailer. Even when the harness or environment instructs you to append Co-Authored-By by default, Assisted-by: replaces it — the two never coexist.

4. Commit

Prefer the heredoc form unless the harness recommends against heredocs, command substitution, or shell interpolation. If so, use separate -m arguments; each one becomes its own paragraph.

Preferred: heredoc

git commit -m "$(cat <<'EOF'
feat(auth): Add JWT refresh-token rotation

Refresh tokens are now single-use and rotated on every refresh, so a
leaked token is only valid until the next legitimate refresh.

Assisted-by: ClaudeCode:claude-opus-4-8
EOF
)" && git --no-pager log -1 --stat

Sandbox-safe fallback: separate -m arguments

GIT_EDITOR=true git commit \
  -m "feat(scope): Add concise description" \
  -m "Explain what changed and why." \
  -m "Assisted-by: Zed:openai-gpt-5-5" \
  && git --no-pager log -1 --stat

Guardrails

• Commit only when asked. Don't proactively commit just because changes exist.
• Don't git push unless the user asks — committing and pushing are separate.
• Never update git config, and never force-push.
• Don't --amend, rebase, or rewrite existing commits unless explicitly asked
• If a pre-commit hook fails, surface the failure and fix the cause — don't reach for --no-verify unless the user okays it. A hook that modifies files (formatters) aborts the commit, so re-stage the changed files and re-run git commit.
• Match the repository's existing conventions over the generic defaults here when they differ — consistency within a project matters more than any one style.