name: lint-check description: Run pre-commit hooks and golangci-lint to verify code quality before finishing work
Lint Check
Run all quality checks (pre-commit hooks and golangci-lint) before considering work complete. Use this skill when finishing a task, before committing, or when preparing a PR.
When to Use
- After completing a code change or task
- Before creating a commit
- Before pushing to remote
- When explicitly requested by the user
- When you've made changes to Go code or documentation
Workflow
Step 1: Check for Modified Files
First, check what files have been modified:
git status --short
If there are no modified files, inform the user and exit.
Step 2: Run Pre-commit Hooks
Run pre-commit on all modified files:
pre-commit run --files <list-of-modified-files>
Important: If pre-commit modifies files (like prettier formatting), stage those changes:
git add <files-modified-by-pre-commit>
Then re-run pre-commit to verify all checks pass.
Step 3: Run golangci-lint
If any Go files were modified, run the full lint suite:
make lint
This runs both pre-commit hooks and golangci-lint with the project's configuration.
Step 4: Report Results
If all checks pass:
Present a success message:
✅ All quality checks passed!
Pre-commit: Passed
golangci-lint: 0 issues
Your changes are ready to commit.
If checks fail:
- Show the specific errors/warnings
- If the fixes are simple (formatting), apply them automatically
- If the fixes require code changes, explain what needs to be fixed
- Offer to help fix the issues
Step 5: Suggest Next Steps
After successful checks, suggest appropriate next steps:
- If changes are staged: "Ready to commit. Would you like me to create a commit?"
- If not staged: "Would you like me to stage these changes?"
- If on a feature branch: "Would you like me to create a PR?"
Error Handling
Pre-commit Failures
- Formatting issues (prettier, trailing whitespace): Auto-fix by staging the changes pre-commit made
- Linting issues (markdownlint, yamllint): Show errors and offer to fix
- Security issues (gitleaks, detect-private-key): Alert immediately and DO NOT commit
golangci-lint Failures
- Code style issues: Show the issues and offer to fix following the patterns in the codebase
- Unused code: Offer to remove unused functions/variables
- Missing error handling: Add proper error handling
- Copyright headers: Add missing headers using
.copyright-header.tmpl
Special Cases
Large Output
If lint output is too large (>30KB), read the full output file and summarize:
- Total number of issues
- Breakdown by linter/severity
- Top 5 most common issues
- Actionable suggestions
Tools Directory
If changes are in tools/ directory, also run:
cd tools && make lint
Documentation Only
If only documentation files (*.md) were changed:
- Run pre-commit (includes markdownlint)
- Skip golangci-lint
- Report success faster
Important Rules
- Never skip checks: Always run both pre-commit and golangci-lint for Go changes
- Auto-stage formatting fixes: If pre-commit reformats files, stage them automatically
- Clear reporting: Always show what passed/failed clearly
- Actionable feedback: If something fails, explain how to fix it
- Context awareness: If in tools/ directory, run tools-specific checks too
Example Usage
User says: "I'm done with this feature"
- Run git status to see changes
- Run pre-commit on all modified files
- Stage any formatting fixes from pre-commit
- Run make lint for full quality check
- Report results with ✅ or specific errors
- Suggest next steps (commit, PR, etc.)