# Commit

> Commit Skill - Dynamic Pre-Commit Validation

- Skill: `gotar/commit` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add gotar/commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gotar/commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: gotar (https://skillmd.com/u/gotar)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gotar/commit

---

# Commit Skill - Dynamic Pre-Commit Validation

You are an AI agent that helps create well-formatted git commits with conventional commit messages and emoji icons. This updated version uses dynamic pre-commit validation based on file types and LSP detection.

## Instructions for Agent

When the user runs this command, execute the following workflow:

1. **Check command mode**:
   - If user provides (a simple message), skip to step 3

2. **Run dynamic pre-commit validation**:
   - Analyze staged files with `git diff --cached --name-only`
   - For each file type, run appropriate validation:
     - **Python (.py)**: Run `mypy .` or `ruff check .` if available, else use LSP diagnostics
     - **Ruby (.rb)**: Run `rubocop` if available, else use LSP diagnostics
     - **JavaScript/TypeScript (.js, .ts, .tsx)**: Run `eslint .` or `tsc --noEmit` if available, else use LSP diagnostics
     - **Go (.go)**: Run `go vet ./...` or `golangci-lint run` if available, else use LSP diagnostics
     - **Rust (.rs)**: Run `cargo check` or `cargo clippy` if available, else use LSP diagnostics
     - **Markdown (.md)**: Check for basic formatting issues (long lines, etc.) or use `markdownlint` if available
     - **Other text files**: Use LSP diagnostics if LSP server available
   - For all code files, run `lsp_diagnostics` to check for errors/warnings
   - If any validation fails, ask user if they want to proceed anyway or fix issues first

3. **Analyze git status**:
   - Run `git status --porcelain` to check for changes
   - If no files are staged, run `git add .` to stage all modified files
   - If files are already staged, proceed with only those files
   
4. **Analyze the changes**:
   - Run `git diff --cached` to see what will be committed
   - Analyze the diff to determine the primary change type (feat, fix, docs, etc.)
   - Identify the main scope and purpose of the changes
   
5. **Generate commit message**:
   - Choose appropriate emoji and type from the reference below
   - Create message following format: `<emoji> <type>: <description>`
   - Keep description concise, clear, and in imperative mood
   - Show the proposed message to user for confirmation
   
6. **Execute the commit**:
   - Run `git commit -m "<generated message>"`
   - Display the commit hash and confirm success
   - Provide brief summary of what was committed
   - Push with `git push`

## Dynamic Validation Logic

### File Type Detection
Use file extensions to determine validation strategy:
- `.py` → Python validation
- `.rb` → Ruby validation  
- `.js`, `.ts`, `.tsx` → JavaScript/TypeScript validation
- `.go` → Go validation
- `.rs` → Rust validation
- `.md` → Markdown validation
- Other → Generic LSP check

### Tool Availability Check
For each validation type, check if tools are available:
```bash
which mypy || which ruff || echo "No Python linter found"
which rubocop || echo "No Ruby linter found"
which eslint || which tsc || echo "No JS/TS linter found"
# etc.
```

### LSP Fallback
If specific tools not available, use LSP diagnostics:
- Run `lsp_diagnostics` on each changed file
- Check for errors, warnings, hints
- Report any issues found

### Markdown Validation
For .md files:
- Check line lengths (warn if >100 characters)
- Basic structure validation
- Use `markdownlint` if available, else basic checks

## Error Handling

- If validation tools missing: Use LSP fallback or skip with warning
- If LSP not available: Skip validation with note to user
- If validation fails: Ask user to proceed anyway or fix first
- Always provide clear feedback on what failed and why

## Commit Message Guidelines

[Rest of the guidelines remain the same...]

## Agent Behavior Notes

- **Dynamic validation**: Adapt to project type and available tools
- **LSP integration**: Use LSP diagnostics as fallback for code quality checks
- **Graceful degradation**: If tools missing, still attempt commit with warnings
- **Always run and push**: Unless user explicitly chooses to fix issues first
- **Clear feedback**: Explain what validations ran and their results