Safe Commit Validation

VerifiedSafe

Automatically fixes formatting and fixable lint issues in Python, Shell, and Markdown files, then runs linters and type checkers on staged changes. Shows raw validator output for you to interpret, and blocks commits containing local or sensitive files. Helps maintain code quality and catch errors before committing.

Sby Skills Guide Bot
DevelopmentIntermediate
606/2/2026
Claude Code
#code-quality#git-commit#validation#linting#automation

Recommended for

Our review

Automates code quality validation before a commit by running formatting, linting, and type checking tools, then displaying raw output for human review.

Strengths

  • Auto-fixes fixable issues (formatting, lint) and re-stages modified files
  • Validates only staged changes to avoid noise
  • Supports Python, Shell, and Markdown with appropriate tools

Limitations

  • Cannot interpret tool output; agent must manually decide to proceed
  • Depends on locally installed tools (ruff, mypy, shellcheck, etc.)
  • Does not handle merge conflicts or comprehensive test validation
When to use it

Use it before every commit to ensure only clean, validated code enters the repository.

When not to use it

Avoid when you need to validate unstaged changes or in projects without linting/type-checking setup.

Security analysis

Safe
Quality score90/100

The skill runs a curated validation script for code quality checks before committing. It uses predefined, reputable tools (ruff, mypy, shellcheck) in a safe manner, without downloading or executing untrusted code. No destructive or exfiltrating actions are instructed.

No concerns found

Examples

Validate staged changes before commit
Stage all modified Python and shell files, then run safe commit validation to auto-fix issues and show me the results.
Auto-fix and commit with conventional message
Run safe commit on staged changes, fix any errors found, and commit with a conventional message explaining the change.
Check for sensitive files before commit
Use safe commit to validate my staged changes, paying attention to any sensitive file warnings before committing.

name: safe-commit description: Validate code quality and commit changes. Supports Python, Shell, and Markdown. Use for code commits. allowed-tools: [Bash, Read, Grep, AskUserQuestion]

Safe Commit

Automatically fix code quality issues and validate changes before committing.

How It Works

The script auto-fixes everything it can (formatting, fixable lint issues), then runs validators and shows you their raw output. You read the tool output directly, decide if there are problems, and proceed accordingly.

Key Philosophy: You're an intelligent agent - the script doesn't parse tool output or interpret "errors" vs "success." It just shows you what ruff, mypy, shellcheck, etc. say, and you decide.

Note on tool selection: The script prefers project-managed tools (via uv run --group dev if pyproject.toml exists) over global tools, which allows mypy to see project dependencies and validate imports properly.

Workflow

1. Stage Your Changes

IMPORTANT: Stage files before running validation:

git add <files-to-commit>

The script validates only staged changes. If you run it without staging, you'll get:

Exit code 1: No staged changes to commit

2. Run Validation

~/.claude/skills/safe-commit/safe_commit.sh

The script will:

  • Auto-fix all fixable issues (formatting, auto-fixable lint errors)
  • Re-stage any files that were modified during auto-fixing
  • Run validators and show their full output
  • Check for safety concerns (local files, sensitive files)
  • Show commit size statistics

If you see MISSING_TOOLS: - Some validators are unavailable. Validation will be limited but script continues.

3. Review Output and Fix Issues

Read the validator output directly and fix any problems found:

Clean output - proceed with commit:

=== Validating: script.py ===
--- ruff check (via project env) ---
All checks passed!

--- mypy (via project env) ---
Success: no issues found in 1 source file

Errors found - fix them before committing:

=== Validating: script.py ===
--- ruff check ---
script.py:10:5: F821 Undefined name `foo`

--- mypy ---
script.py:10: error: Name 'foo' is not defined

→ Undefined variable on line 10 - edit the file to fix it, then re-run validation

Important:

  • Always fix errors - Don't proceed with broken code unless you have a very good reason
  • Explain any exceptions - If you skip an error, tell the user why
  • Use Edit tool to fix issues, then re-stage and re-run safe-commit

Special cases:

  • Local files detected → Hard block, must unstage them
  • Sensitive files detected → Ask user to confirm before committing
  • Auto-fixed files → Review git diff --cached to see what changed

4. Generate Commit Message

  • Use conventional format (feat:, fix:, refactor:, docs:, test:)
  • Focus on WHY, not just WHAT
  • Check recent style: git log -5 --oneline
  • Ask user for confirmation

5. Execute Commit

git commit -m "your message here"

What the Script Does

The script uses language-specific tools for formatting, linting, and validation:

Python:

  • Auto-fix: ruff format (formatter) + ruff check --fix (linter with auto-fix)
  • Validate: ruff check (linter) + mypy (type checker)

Shell:

  • Auto-fix: shfmt -w (formatter)
  • Validate: shellcheck (linter)

Markdown:

  • Auto-fix: markdownlint --fix + prettier --write or mdformat (formatters)
  • Validate: markdownlint (linter)

Auto-fixes (re-stages automatically):

  • All fixable issues are automatically corrected and re-staged
  • Modified files are automatically added back to the staging area

Hard blocks (exits with error):

  • Local files (.local.)
  • No staged changes
  • Not in a git repository

Shows in output (you interpret):

  • Linting errors (ruff, shellcheck, markdownlint)
  • Type errors (mypy)
  • All other validation results
  • Line-length warnings are informational - don't block on MD013 in markdown

Warns (doesn't block):

  • Sensitive files (.env, credentials, .pem)
  • Large commits (>300 lines)

Splitting Commits

If changes are unrelated, stage them separately:

# First commit
git add <first-group-of-files>
~/.claude/skills/safe-commit/safe_commit.sh
git commit -m "first commit"

# Second commit
git add <second-group-of-files>
~/.claude/skills/safe-commit/safe_commit.sh
git commit -m "second commit"

To unstage files already staged:

git restore --staged <unwanted-files>

Important

  • Fix errors before committing - Don't proceed with broken code
  • Review validator output - You interpret what tools report, but act on errors
  • Never commit .local. files* - Hard blocked by script
  • Always read the diff - Understand what's changing
  • Check auto-fixes - Review what was automatically fixed
  • Think about coherence - Should changes be in separate commits?

Troubleshooting

If the script itself seems broken or needs improvement, see TESTING.md for how to test and validate changes to the safe-commit skill.

Related skills