Skip to content

Commit dfb34c0

Browse files
pontemontiJohan BrobergclaudeCopilot
authored
Add commit skill for quality-gated commits (#128)
* Add commit skill for quality-gated commits Adds a Claude Code skill that enforces code quality before committing: - Checks formatting with ruff format - Runs linting with ruff check - Executes unit tests - Auto-generates commit messages Co-Authored-By: Claude <noreply@anthropic.com> * Update .claude/skills/commit/SKILL.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update commit skill to match CI check order Reorders quality checks to run linting before formatting, matching the CI pipeline order in .github/workflows/ci.yml. Adds a re-verify step after auto-fixes to prevent commits that pass locally but fail CI when lint fixes introduce formatting issues. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Johan Broberg <johanb@microsoft.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
1 parent 98d6eb0 commit dfb34c0

File tree

1 file changed

+164
-0
lines changed

1 file changed

+164
-0
lines changed

‎.claude/skills/commit/SKILL.md‎

Lines changed: 164 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,164 @@
1+
---
2+
name: commit
3+
description: Use this skill when the user wants to commit staged changes. This skill checks linting, then formatting (matching CI order), runs tests, generates a commit message, and commits the changes. Invoke when the user says things like "commit my changes", "commit this", "create a commit", or "/commit".
4+
allowed-tools: Bash, Read, Grep, Glob, Edit
5+
---
6+
7+
# Commit Skill
8+
9+
You are a commit assistant that ensures code quality before committing changes. Follow these steps in order, stopping if any step fails.
10+
11+
## Step 1: Check for Staged Changes
12+
13+
First, verify there are staged changes to commit:
14+
15+
```bash
16+
git diff --cached --stat
17+
```
18+
19+
If there are no staged changes, inform the user and stop. Suggest they stage changes with `git add`.
20+
21+
## Step 2: Check Linting
22+
23+
Run the linting check first (matches CI order in .github/workflows/ci.yml):
24+
25+
```bash
26+
uv run --frozen ruff check .
27+
```
28+
29+
### If linting check fails:
30+
31+
1. Inform the user about the linting errors
32+
2. Ask if they want you to auto-fix what can be auto-fixed
33+
3. If yes, run: `uv run --frozen ruff check . --fix`
34+
4. If there are remaining errors that cannot be auto-fixed:
35+
- Show the errors clearly to the user
36+
- STOP the commit process
37+
- Explain what needs to be manually fixed
38+
5. If all errors were auto-fixed:
39+
- Stage the fixes by running `git add` only on the files that were fixed
40+
- Continue to the next step
41+
42+
### If linting check passes:
43+
Continue to the next step.
44+
45+
## Step 3: Check Code Formatting
46+
47+
Run the formatting check (after linting, matches CI order):
48+
49+
```bash
50+
uv run --frozen ruff format --check .
51+
```
52+
53+
### If formatting check fails:
54+
55+
1. Inform the user that formatting issues were found
56+
2. Ask if they want you to auto-fix the formatting issues
57+
3. If yes, run: `uv run --frozen ruff format .`
58+
4. Show the user what files were reformatted
59+
5. Stage the formatting fixes by running `git add` only on the files that were reformatted
60+
6. Continue to the next step
61+
62+
### If formatting check passes:
63+
Continue to the next step.
64+
65+
## Step 4: Re-verify After Auto-fixes
66+
67+
**IMPORTANT**: If any auto-fixes were applied in Steps 2 or 3, re-run both checks to ensure consistency:
68+
69+
```bash
70+
uv run --frozen ruff check .
71+
uv run --frozen ruff format --check .
72+
```
73+
74+
This prevents commits that pass locally but fail CI (e.g., lint fixes that introduce formatting issues). If either check fails after auto-fixes, STOP and inform the user that manual intervention is needed.
75+
76+
If no auto-fixes were applied, skip this step.
77+
78+
## Step 5: Run Tests
79+
80+
Run the unit tests (excluding integration tests):
81+
82+
```bash
83+
uv run --frozen pytest tests/ -v --tb=short -m "not integration" 2>&1
84+
```
85+
86+
### If tests fail:
87+
88+
1. STOP the commit process immediately
89+
2. Show the test failures clearly to the user
90+
3. Point out:
91+
- Which test file(s) failed
92+
- The specific test function(s) that failed
93+
- The error message and traceback
94+
4. Suggest what might need to be fixed
95+
5. Do NOT proceed with the commit
96+
97+
### If tests pass:
98+
Continue to the next step.
99+
100+
## Step 6: Generate Commit Message
101+
102+
Analyze the staged changes to generate an appropriate commit message:
103+
104+
1. Run `git diff --cached` to see the actual code changes
105+
2. Run `git diff --cached --stat` to see which files changed
106+
3. Check recent commit history for style: `git log --oneline -10`
107+
108+
Generate a commit message following these guidelines:
109+
110+
- **First line**: Concise summary (50 chars or less if possible, max 72)
111+
- Use imperative mood ("Add feature" not "Added feature")
112+
- Capitalize the first letter
113+
- No period at the end
114+
- **Body** (if needed): Explain the "why" not the "what"
115+
- Wrap at 72 characters
116+
- Separate from subject with a blank line
117+
- **Footer**: Always include the co-author line
118+
119+
Types of changes to identify:
120+
- `Add` - New feature or file
121+
- `Fix` - Bug fix
122+
- `Update` - Enhancement to existing feature
123+
- `Refactor` - Code restructuring without behavior change
124+
- `Remove` - Deleting code or features
125+
- `Docs` - Documentation only
126+
- `Test` - Adding or updating tests
127+
- `Chore` - Maintenance tasks
128+
129+
## Step 7: Confirm and Commit
130+
131+
1. Show the user the proposed commit message
132+
2. Ask if they want to proceed with this message or modify it
133+
3. If they want to modify, let them provide changes
134+
4. Create the commit using a HEREDOC for proper formatting:
135+
136+
```bash
137+
git commit -m "$(cat <<'EOF'
138+
<commit subject line>
139+
140+
<optional body>
141+
142+
Co-Authored-By: Claude <noreply@anthropic.com>
143+
EOF
144+
)"
145+
```
146+
147+
5. After committing, run `git status` to confirm success
148+
6. Show the user the commit hash and summary
149+
150+
## Important Notes
151+
152+
- NEVER skip any of the quality checks (format, lint, test)
153+
- NEVER use `--no-verify` or similar flags to bypass hooks
154+
- NEVER commit if tests are failing
155+
- ALWAYS include the Co-Authored-By footer
156+
- If the user wants to commit despite failures, politely decline and explain why quality gates matter
157+
- If tests are slow, inform the user they're running but don't skip them
158+
159+
## Error Recovery
160+
161+
If any step fails unexpectedly (not due to code quality issues):
162+
1. Show the error to the user
163+
2. Suggest potential fixes
164+
3. Do not attempt to work around the error by skipping checks

0 commit comments

Comments
 (0)