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:
Check command mode:
- If user provides (a simple message), skip to step 3
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
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
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
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
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:
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
1---2name: commit3description: Commit Skill - Dynamic Pre-Commit Validation4---5# Commit Skill - Dynamic Pre-Commit Validation67You 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.89## Instructions for Agent1011When the user runs this command, execute the following workflow:12131. **Check command mode**:14 - If user provides (a simple message), skip to step 315162. **Run dynamic pre-commit validation**:17 - Analyze staged files with `git diff --cached --name-only`18 - For each file type, run appropriate validation:19 - **Python (.py)**: Run `mypy .` or `ruff check .` if available, else use LSP diagnostics20 - **Ruby (.rb)**: Run `rubocop` if available, else use LSP diagnostics21 - **JavaScript/TypeScript (.js, .ts, .tsx)**: Run `eslint .` or `tsc --noEmit` if available, else use LSP diagnostics22 - **Go (.go)**: Run `go vet ./...` or `golangci-lint run` if available, else use LSP diagnostics23 - **Rust (.rs)**: Run `cargo check` or `cargo clippy` if available, else use LSP diagnostics24 - **Markdown (.md)**: Check for basic formatting issues (long lines, etc.) or use `markdownlint` if available25 - **Other text files**: Use LSP diagnostics if LSP server available26 - For all code files, run `lsp_diagnostics` to check for errors/warnings27 - If any validation fails, ask user if they want to proceed anyway or fix issues first28293. **Analyze git status**:30 - Run `git status --porcelain` to check for changes31 - If no files are staged, run `git add .` to stage all modified files32 - If files are already staged, proceed with only those files33 344. **Analyze the changes**:35 - Run `git diff --cached` to see what will be committed36 - Analyze the diff to determine the primary change type (feat, fix, docs, etc.)37 - Identify the main scope and purpose of the changes38 395. **Generate commit message**:40 - Choose appropriate emoji and type from the reference below41 - Create message following format: `<emoji> <type>: <description>`42 - Keep description concise, clear, and in imperative mood43 - Show the proposed message to user for confirmation44 456. **Execute the commit**:46 - Run `git commit -m "<generated message>"`47 - Display the commit hash and confirm success48 - Provide brief summary of what was committed49 - Push with `git push`5051## Dynamic Validation Logic5253### File Type Detection54Use file extensions to determine validation strategy:55- `.py` → Python validation56- `.rb` → Ruby validation 57- `.js`, `.ts`, `.tsx` → JavaScript/TypeScript validation58- `.go` → Go validation59- `.rs` → Rust validation60- `.md` → Markdown validation61- Other → Generic LSP check6263### Tool Availability Check64For each validation type, check if tools are available:65```bash66which mypy || which ruff || echo "No Python linter found"67which rubocop || echo "No Ruby linter found"68which eslint || which tsc || echo "No JS/TS linter found"69# etc.70```7172### LSP Fallback73If specific tools not available, use LSP diagnostics:74- Run `lsp_diagnostics` on each changed file75- Check for errors, warnings, hints76- Report any issues found7778### Markdown Validation79For .md files:80- Check line lengths (warn if >100 characters)81- Basic structure validation82- Use `markdownlint` if available, else basic checks8384## Error Handling8586- If validation tools missing: Use LSP fallback or skip with warning87- If LSP not available: Skip validation with note to user88- If validation fails: Ask user to proceed anyway or fix first89- Always provide clear feedback on what failed and why9091## Commit Message Guidelines9293[Rest of the guidelines remain the same...]9495## Agent Behavior Notes9697- **Dynamic validation**: Adapt to project type and available tools98- **LSP integration**: Use LSP diagnostics as fallback for code quality checks99- **Graceful degradation**: If tools missing, still attempt commit with warnings100- **Always run and push**: Unless user explicitly chooses to fix issues first101- **Clear feedback**: Explain what validations ran and their results