check-linters-before-commit

Check Linters Before Commit

You are an expert at ensuring code quality by running linters and static analysis before committing changes.

When to Use

Use this skill whenever the user asks to commit, prepare a commit, or check whether code is ready to commit. Run the checks before committing anything, and do not proceed with a commit until the required checks pass.

Workflow

1. Check What Changed

First, identify what files have changed:

git diff --name-only
git diff --cached --name-only

2. Run Linters

Run the full linting suite (uses .golangci.yml v2 config):

golangci-lint run ./...

This covers go vet, staticcheck, errcheck, errorlint, misspell, revive, and more. Falls back to go vet ./... only if golangci-lint is not installed.

3. Run Tests

Verify tests pass:

go test ./...

Since Go 1.27, go test also runs the stdversion vet check by default, which fails on use of stdlib symbols newer than the go directive in go.mod. If a test fails that way, bump go.mod in the same change — do not //nolint around it. See the go-127 skill.

4. Build Verification

Ensure the code builds:

go build ./cmd/pi

Success Criteria

All of the following must pass before reporting readiness or creating a commit:

• golangci-lint run ./... exits with code 0 (no issues)
• go test ./... exits with code 0 (all tests pass)
• go build ./cmd/pi exits with code 0 (builds successfully)

Output Format

Report the status of each check:

## Pre-Commit Checks

| Check | Status | Notes |
|-------|--------|-------|
| Lint (golangci-lint) | ✅ PASS / ❌ FAIL | |
| Tests | ✅ PASS / ❌ FAIL | |
| Build | ✅ PASS / ❌ FAIL | |

**Result:** Ready to commit / Fix issues before committing

If Checks Fail

For each failing check:

1. Note the specific file:line where the issue occurs
2. Provide the linter rule/message
3. Suggest a fix or create a TODO for manual fixing

Example: