Files
Cog-Sync/.claude/commands/commit.md
2026-03-18 20:04:29 +11:00

2.6 KiB

Use this skill when the user wants to commit changes to git. Trigger if the user says "commit", "save changes", "commit this", or asks to create a git commit. Examples: "commit", "commit and push", "save my changes".

Process

  1. Assess the working tree — Run git status (never use -uall) and git diff --staged and git diff to understand what changed.

  2. Guard rails — Before staging:

    • Never commit files that contain secrets (.env, credentials, tokens, keys). Warn if any are present.
    • Never commit build artifacts (dist/, *.tsbuildinfo).
    • Never commit node_modules/.
    • If there are no changes to commit, say so and stop.
  3. Stage selectively — Stage files by name. Prefer git add <file>... over git add -A or git add . to avoid accidentally including sensitive or unrelated files. Group related changes — if unrelated changes exist, ask whether to commit everything together or separately.

  4. Write the commit message — Use Conventional Commits format:

    • feat: new feature
    • fix: bug fix
    • refactor: code restructuring without behavior change
    • chore: maintenance, dependencies, config
    • docs: documentation only
    • style: formatting, whitespace
    • test: adding or updating tests
    • Scope is optional: feat(whatsapp): add voice note transcription
    • Subject line: imperative mood, lowercase, no period, under 72 chars
    • Body (if needed): blank line after subject, wrap at 72 chars, explain why not what
    • Always end with: Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
  5. Commit — Use a HEREDOC for the message to preserve formatting:

    git commit -m "$(cat <<'EOF'
    type(scope): subject line
    
    Optional body explaining why.
    
    Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
    EOF
    )"
    
  6. Verify — Run git status after committing to confirm success. Show the resulting git log --oneline -1.

Rules

  • Never push unless $ARGUMENTS contains "and push" or "push".
  • Never amend unless $ARGUMENTS contains "amend".
  • Never skip hooks (no --no-verify).
  • Never force push.
  • If a pre-commit hook fails, fix the issue, re-stage, and create a new commit (do not amend).
  • If $ARGUMENTS contains a message hint, use it to inform the commit message but still follow conventional format.

Arguments

$ARGUMENTS — Optional. May contain:

  • A message hint (e.g., /commit add voice transcription support)
  • "and push" to push after committing
  • "amend" to amend the previous commit instead of creating a new one
  • "all" to stage all changes without asking