Git Commit Workflow

VerifiedSafe

Guides the process of creating clean Git commits: selectively stages files (excluding .env, .pyc, etc.), runs pre-commit hooks (ruff, gitleaks), and formats messages using Conventional Commits. Helps maintain a consistent, secure commit history in any project.

Sby Skills Guide Bot
DevelopmentIntermediate
606/2/2026
Claude Code
#git#commit#conventional-commits#pre-commit

Recommended for

Our review

Creates a clean, well-formatted git commit with selective staging, pre-commit hooks, and conventional commit messages.

Strengths

  • Enforces conventional commits
  • Handles pre-commit hook failures gracefully
  • Prevents accidental commits of sensitive files
  • Provides clear step-by-step workflow

Limitations

  • Requires pre-commit hooks to be configured
  • May not handle merge conflicts
  • Does not push automatically
When to use it

Use this skill when you need to create a well-documented commit following project conventions.

When not to use it

Avoid if you need a quick, informal commit without conventional formatting.

Security analysis

Safe
Quality score92/100

The skill only runs standard git commands and pre-commit hooks (ruff, ruff-format, gitleaks) already present in the project. It explicitly excludes sensitive files from being staged and does not instruct destructive or exfiltrating actions. No external scripts are executed, and no secrets are exposed.

No concerns found

Examples

Commit staged changes with conventional message
I've made some changes to the RAG module. Can you commit them? The changes are: added author filtering to Qdrant search.
Commit all changes (todo)
Commit all changes with a message about fixing the inference endpoint.
Commit with specific files
Commit these files: application/rag/search.py, tests/test_rag.py with a chore message.

name: commit description: Stage changes, run pre-commit hooks, and create a well-formatted git commit allowed-tools: Bash, Read, Grep, Glob

Git Commit Workflow

Create a clean, well-documented git commit following this project's conventions.

Step 1: Review changes

git status
git diff --stat

Show the user a summary of what will be committed.

Step 2: Stage files

Stage files selectively (never git add . or git add -A blindly):

# Stage specific files
git add <file1> <file2> ...

Files to NEVER commit

| Pattern | Reason | |---------|--------| | .env | Contains HUGGINGFACE_ACCESS_TOKEN | | *.pyc, __pycache__/ | Compiled Python | | .DS_Store | macOS junk | | model_output/ | Downloaded models | | data/eval_results/ | Generated evaluation data | | output/ | Pipeline outputs | | .claude/settings.local.json | Personal Claude settings | | .claude/CLAUDE.local.md | Personal Claude memory |

If $ARGUMENTS says "all" or "todo", stage all modified/untracked files except those above.

Step 3: Pre-commit hooks

This project has pre-commit hooks configured in .pre-commit-config.yaml:

  • ruff (linter) - auto-fixes code style
  • ruff-format (formatter) - auto-formats code
  • gitleaks - scans for leaked secrets

If a hook fails:

  1. The commit is aborted (it did NOT happen)
  2. Fix the issues (ruff usually auto-fixes, just re-stage)
  3. Create a NEW commit (never --amend after a hook failure - that would modify the wrong commit)

Step 4: Commit message format

Use Conventional Commits:

<type>(<scope>): <description>

[optional body]

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Types

| Type | When to use | |------|-------------| | feat | New feature or functionality | | fix | Bug fix | | docs | Documentation changes (README, CLAUDE.md, comments) | | refactor | Code restructuring without behavior change | | chore | Maintenance (deps, configs, cleanup) | | style | Formatting, linting (no logic change) | | test | Adding or modifying tests | | perf | Performance improvements | | ci | CI/CD changes |

Scopes (optional, use the most relevant)

| Scope | Files | |-------|-------| | inference | model/inference/, infrastructure/inference_pipeline_api.py | | rag | application/rag/ | | eval | model/evaluation/ | | training | model/finetuning/ | | etl | application/crawlers/, configs/digital_data_etl_* | | dataset | application/dataset/ | | settings | settings.py, .env, configs/ | | deps | pyproject.toml, poetry.lock | | infra | docker-compose.yml, ZenML configs |

Examples

feat(rag): Add author filtering to Qdrant search
fix(inference): Add task parameter to HuggingFaceEndpoint
docs: Rewrite README for local-only setup
chore(deps): Upgrade langchain-huggingface to 1.2.0
refactor(eval): Replace OpenAI judge with HuggingFace

Step 5: Create the commit

Use HEREDOC for proper message formatting:

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

<body if needed>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
EOF
)"

Step 6: Verify

git log --oneline -3

Show the user the new commit hash and message.

After the commit

Do NOT push automatically. Tell the user they can push with /push or git push.

If pre-commit hook fails

  1. Check what failed: usually ruff auto-fixed files
  2. Re-stage the auto-fixed files: git add <fixed-files>
  3. Create a NEW commit (do NOT use --amend)
  4. If gitleaks fails: a secret was detected. Remove it from the staged files before retrying.
Related skills