Run Linters
Execute linters after code changes are complete to ensure code quality and consistency.
When to Use
- After completing a set of code changes (not after each small edit)
- Before creating a commit or PR
- When asked to verify code quality
Step 1: Run Linters
Execute the linters command which auto-detects active linters in the current repository and runs them with proper configurations:
linters
Step 2: Analyze Results
- If no issues: Report success and proceed
- If issues found: Continue to Step 3
Step 3: Fix Issues
For each issue reported:
- Read the affected file
- Understand the linting error
- Fix the issue in the source code using Edit tool
- Re-run
linters to verify the fix
Repeat until all issues are resolved.
Important Rules
- Do NOT run after every small change - wait until a logical set of changes is complete
- Fix all issues before reporting completion
- NEVER modify linter configuration files to suppress or ignore issues
- NEVER add inline disable comments (e.g.,
// eslint-disable, # noqa, // nolint) to bypass issues
- Always fix the actual code, not the linter rules
- If an issue seems impossible to fix properly, ask the user for guidance
Forbidden Files - NEVER Modify
The following configuration files must NEVER be edited to work around linting issues:
JavaScript/TypeScript:
.eslintrc, .eslintrc.js, .eslintrc.json, .eslintrc.yml
.prettierrc, .prettierrc.js, .prettierrc.json
eslint.config.js, eslint.config.mjs
tsconfig.json (for strict mode or type checking options)
Python:
.flake8, setup.cfg (flake8 section)
pyproject.toml (tool.flake8, tool.pylint, tool.ruff sections)
.pylintrc, pylintrc
ruff.toml, .ruff.toml
mypy.ini, .mypy.ini
Ruby:
.rubocop.yml, .rubocop_todo.yml
Go:
.golangci.yml, .golangci.yaml
Rust:
clippy.toml, .clippy.toml
rustfmt.toml, .rustfmt.toml
Markdown:
.markdownlint.json, .markdownlint.yaml, .markdownlint.yml
.markdownlintrc
General:
.editorconfig
- Any file that defines linting rules or ignores
Forbidden Patterns - NEVER Use
Do NOT add these patterns to bypass linting:
# JavaScript/TypeScript
/* eslint-disable */
// eslint-disable-line
// eslint-disable-next-line
/* prettier-ignore */
// @ts-ignore
// @ts-nocheck
# Python
# noqa
# type: ignore
# pylint: disable
# ruff: noqa
# Go
//nolint
//nolint:all
# Ruby
# rubocop:disable
# Rust
#[allow(...)]
#![allow(...)]
If you encounter an issue that seems unfixable, explain the problem to the user and ask how they want to proceed.
1---2name: run-linters3description: Run linters after code changes to verify code quality. Use this skill after completing code modifications to catch and fix any linting issues.4---5
6# Run Linters
7
8Execute linters after code changes are complete to ensure code quality and consistency.
9
10## When to Use
11
12- After completing a set of code changes (not after each small edit)
13- Before creating a commit or PR
14- When asked to verify code quality
15
16## Step 1: Run Linters
17
18Execute the `linters` command which auto-detects active linters in the current repository and runs them with proper configurations:
19
20```bash
21linters
22```
23
24## Step 2: Analyze Results
25
26- If no issues: Report success and proceed
27- If issues found: Continue to Step 3
28
29## Step 3: Fix Issues
30
31For each issue reported:
32
331. Read the affected file
342. Understand the linting error
353. Fix the issue **in the source code** using Edit tool
364. Re-run `linters` to verify the fix
37
38Repeat until all issues are resolved.
39
40## Important Rules
41
42- Do NOT run after every small change - wait until a logical set of changes is complete
43- Fix all issues before reporting completion
44- **NEVER modify linter configuration files** to suppress or ignore issues
45- **NEVER add inline disable comments** (e.g., `// eslint-disable`, `# noqa`, `// nolint`) to bypass issues
46- Always fix the actual code, not the linter rules
47- If an issue seems impossible to fix properly, ask the user for guidance
48
49## Forbidden Files - NEVER Modify
50
51The following configuration files must NEVER be edited to work around linting issues:
52
53**JavaScript/TypeScript:**
54
55- `.eslintrc`, `.eslintrc.js`, `.eslintrc.json`, `.eslintrc.yml`
56- `.prettierrc`, `.prettierrc.js`, `.prettierrc.json`
57- `eslint.config.js`, `eslint.config.mjs`
58- `tsconfig.json` (for strict mode or type checking options)
59
60**Python:**
61
62- `.flake8`, `setup.cfg` (flake8 section)
63- `pyproject.toml` (tool.flake8, tool.pylint, tool.ruff sections)
64- `.pylintrc`, `pylintrc`
65- `ruff.toml`, `.ruff.toml`
66- `mypy.ini`, `.mypy.ini`
67
68**Ruby:**
69
70- `.rubocop.yml`, `.rubocop_todo.yml`
71
72**Go:**
73
74- `.golangci.yml`, `.golangci.yaml`
75
76**Rust:**
77
78- `clippy.toml`, `.clippy.toml`
79- `rustfmt.toml`, `.rustfmt.toml`
80
81**Markdown:**
82
83- `.markdownlint.json`, `.markdownlint.yaml`, `.markdownlint.yml`
84- `.markdownlintrc`
85
86**General:**
87
88- `.editorconfig`
89- Any file that defines linting rules or ignores
90
91## Forbidden Patterns - NEVER Use
92
93Do NOT add these patterns to bypass linting:
94
95```text
96# JavaScript/TypeScript
97/* eslint-disable */
98// eslint-disable-line
99// eslint-disable-next-line
100/* prettier-ignore */
101// @ts-ignore
102// @ts-nocheck
103
104# Python
105# noqa
106# type: ignore
107# pylint: disable
108# ruff: noqa
109
110# Go
111//nolint
112//nolint:all
113
114# Ruby
115# rubocop:disable
116
117# Rust
118#[allow(...)]
119#![allow(...)]
120```
121
122If you encounter an issue that seems unfixable, explain the problem to the user and ask how they want to proceed.