lint

Name: lint
Author: softspark

161stars21forks

How to install lint?

softspark/ai-toolkit/lint

$npx -y skills add softspark/ai-toolkit --skill lint

Installs into the current project.

Summary

Runs linter+typechecker with auto-detected toolchain (ruff/mypy, eslint/tsc, phpstan, golangci-lint, clippy). Triggers: lint, typecheck, static analysis.

Files · 1

View on GitHub

SKILL.md

1	# Lint Runner
2
3	$ARGUMENTS
4
5	Run linting and type checking based on detected project type.
6
7	## Project context
8
9	- Project files: !`ls pyproject.toml package.json composer.json pubspec.yaml go.mod 2>/dev/null`
10
11	## Auto-Detection
12
13	Run the bundled script to detect available linters:
14
15	```bash
16	python3 ${CLAUDE_SKILL_DIR}/scripts/detect-linters.py .
17	```
18
19	## Usage
20
21	```
22	/lint [path]
23	```
24
25	## Commands by Project Type
26
27	\| Project Type \| Lint Command \| Type Check \|
28	\|--------------\|--------------\|------------\|
29	\| Python \| `ruff check .` \| `mypy .` \|
30	\| TypeScript/Node \| `npx eslint .` \| `npx tsc --noEmit` \|
31	\| PHP \| `./vendor/bin/phpstan analyse` \| - \|
32	\| Go \| `golangci-lint run` \| - \|
33	\| Rust \| `cargo clippy` \| - \|
34	\| Flutter/Dart \| `dart analyze` \| - \|
35
36	## Python Projects
37
38	```bash
39	# Linting
40	ruff check .
41
42	# Type checking
43	mypy .
44
45	# Auto-fix
46	ruff check --fix .
47	ruff format .
48	```
49
50	## TypeScript/Node Projects
51
52	```bash
53	# Linting
54	npx eslint .
55
56	# Type checking
57	npx tsc --noEmit
58
59	# Auto-fix
60	npx eslint --fix .
61	```
62
63	## PHP Projects
64
65	```bash
66	# Static analysis
67	./vendor/bin/phpstan analyse
68
69	# Code style
70	./vendor/bin/phpcs
71	./vendor/bin/phpcbf # auto-fix
72	```
73
74	## Docker Execution (if applicable)
75
76	```bash
77	# Generic pattern - replace {container} with your app container
78	docker exec {container} make lint
79	docker exec {container} make typecheck
80	```
81
82	## Quality Gates
83
84	- Linting: 0 errors
85	- Type checking: 0 errors (for new code)
86
87	## Common Issues
88
89	\| Error \| Fix \|
90	\|-------\|-----\|
91	\| Missing type hints \| Add type annotations \|
92	\| Unused imports \| Remove or use `# noqa: F401` \|
93	\| Line too long \| Break line or disable for that line \|
94	\| Import order \| Let linter fix with `--fix` \|
95
96	## Rules
97
98	- MUST auto-detect the linter from project config (`pyproject.toml`, `package.json`, `.eslintrc.*`, `composer.json`, `go.mod`, `Cargo.toml`, `pubspec.yaml`) — do not assume
99	- MUST show the diff before applying any `--fix` run; the user owns the decision to accept auto-fixes
100	- NEVER suppress lint errors with blanket `# noqa` or `eslint-disable-next-line` without naming the specific rule and a reason
101	- NEVER run the formatter (ruff format, prettier, dprint) inside a lint pass unless the project has that wired explicitly — formatting and linting are separate concerns
102	- CRITICAL: report the error count before and after any auto-fix — delta visibility is what makes the run trustworthy
103	- MANDATORY: respect the project's lint config (`.ruff.toml`, `eslint.config.js`, `phpstan.neon`) — overriding project rules on the fly produces arguments during code review
104
105	## Gotchas
106
107	- `ruff check .` and `ruff format .` are separate commands in modern ruff (>0.1.0). Running only `ruff check` misses formatting drift; some repos expect both as part of "lint".
108	- `mypy` without `--strict` has a permissive default: missing annotations count as `Any`, so the type checker silently accepts untyped functions. Check whether the project pins `strict = true` in `pyproject.toml` before declaring "0 type errors".
109	- `eslint` follows `eslint.config.js` (flat config, ESLint 9+) OR `.eslintrc.*` (legacy). Mixing produces mysterious "no rules applied" errors. Check ESLint version first (`npx eslint --version`).
110	- `phpstan` levels (0-10) silently affect which rules apply. A repo at level 5 has different expectations than level 9; report the level alongside the error count.
111	- `golangci-lint` composes many linters; disabling one at the project level may still show its warnings if invoked with `--enable-all` flag. Check `.golangci.yml` before treating a warning as a new regression.
112	- Dart analyze reports on all files including generated `*.g.dart`. Some projects expect generated files to be excluded via `analysis_options.yaml`; without it, lint noise dominates real issues.
113
114	## When NOT to Use
115
116	- To fix the errors — use `/fix` after this skill surfaces them
117	- To run tests — use `/test`
118	- For code review of logic and design — use `/review`
119	- For security-specific static analysis (SAST) — use `/cve-scan` or `/security-patterns`
120	- For project-specific rule authoring — edit the linter's config directly

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

lint

161stars21forks

View on GitHub

How to install lint?

softspark/ai-toolkit/lint

$npx -y skills add softspark/ai-toolkit --skill lint

Installs into the current project.

Summary

Runs linter+typechecker with auto-detected toolchain (ruff/mypy, eslint/tsc, phpstan, golangci-lint, clippy). Triggers: lint, typecheck, static analysis.

Files · 1

View on GitHub

SKILL.md

1	# Lint Runner
2
3	$ARGUMENTS
4
5	Run linting and type checking based on detected project type.
6
7	## Project context
8
9	- Project files: !`ls pyproject.toml package.json composer.json pubspec.yaml go.mod 2>/dev/null`
10
11	## Auto-Detection
12
13	Run the bundled script to detect available linters:
14
15	```bash
16	python3 ${CLAUDE_SKILL_DIR}/scripts/detect-linters.py .
17	```
18
19	## Usage
20
21	```
22	/lint [path]
23	```
24
25	## Commands by Project Type
26
27	\| Project Type \| Lint Command \| Type Check \|
28	\|--------------\|--------------\|------------\|
29	\| Python \| `ruff check .` \| `mypy .` \|
30	\| TypeScript/Node \| `npx eslint .` \| `npx tsc --noEmit` \|
31	\| PHP \| `./vendor/bin/phpstan analyse` \| - \|
32	\| Go \| `golangci-lint run` \| - \|
33	\| Rust \| `cargo clippy` \| - \|
34	\| Flutter/Dart \| `dart analyze` \| - \|
35
36	## Python Projects
37
38	```bash
39	# Linting
40	ruff check .
41
42	# Type checking
43	mypy .
44
45	# Auto-fix
46	ruff check --fix .
47	ruff format .
48	```
49
50	## TypeScript/Node Projects
51
52	```bash
53	# Linting
54	npx eslint .
55
56	# Type checking
57	npx tsc --noEmit
58
59	# Auto-fix
60	npx eslint --fix .
61	```
62
63	## PHP Projects
64
65	```bash
66	# Static analysis
67	./vendor/bin/phpstan analyse
68
69	# Code style
70	./vendor/bin/phpcs
71	./vendor/bin/phpcbf # auto-fix
72	```
73
74	## Docker Execution (if applicable)
75
76	```bash
77	# Generic pattern - replace {container} with your app container
78	docker exec {container} make lint
79	docker exec {container} make typecheck
80	```
81
82	## Quality Gates
83
84	- Linting: 0 errors
85	- Type checking: 0 errors (for new code)
86
87	## Common Issues
88
89	\| Error \| Fix \|
90	\|-------\|-----\|
91	\| Missing type hints \| Add type annotations \|
92	\| Unused imports \| Remove or use `# noqa: F401` \|
93	\| Line too long \| Break line or disable for that line \|
94	\| Import order \| Let linter fix with `--fix` \|
95
96	## Rules
97
98	- MUST auto-detect the linter from project config (`pyproject.toml`, `package.json`, `.eslintrc.*`, `composer.json`, `go.mod`, `Cargo.toml`, `pubspec.yaml`) — do not assume
99	- MUST show the diff before applying any `--fix` run; the user owns the decision to accept auto-fixes
100	- NEVER suppress lint errors with blanket `# noqa` or `eslint-disable-next-line` without naming the specific rule and a reason
101	- NEVER run the formatter (ruff format, prettier, dprint) inside a lint pass unless the project has that wired explicitly — formatting and linting are separate concerns
102	- CRITICAL: report the error count before and after any auto-fix — delta visibility is what makes the run trustworthy
103	- MANDATORY: respect the project's lint config (`.ruff.toml`, `eslint.config.js`, `phpstan.neon`) — overriding project rules on the fly produces arguments during code review
104
105	## Gotchas
106
107	- `ruff check .` and `ruff format .` are separate commands in modern ruff (>0.1.0). Running only `ruff check` misses formatting drift; some repos expect both as part of "lint".
108	- `mypy` without `--strict` has a permissive default: missing annotations count as `Any`, so the type checker silently accepts untyped functions. Check whether the project pins `strict = true` in `pyproject.toml` before declaring "0 type errors".
109	- `eslint` follows `eslint.config.js` (flat config, ESLint 9+) OR `.eslintrc.*` (legacy). Mixing produces mysterious "no rules applied" errors. Check ESLint version first (`npx eslint --version`).
110	- `phpstan` levels (0-10) silently affect which rules apply. A repo at level 5 has different expectations than level 9; report the level alongside the error count.
111	- `golangci-lint` composes many linters; disabling one at the project level may still show its warnings if invoked with `--enable-all` flag. Check `.golangci.yml` before treating a warning as a new regression.
112	- Dart analyze reports on all files including generated `*.g.dart`. Some projects expect generated files to be excluded via `analysis_options.yaml`; without it, lint noise dominates real issues.
113
114	## When NOT to Use
115
116	- To fix the errors — use `/fix` after this skill surfaces them
117	- To run tests — use `/test`
118	- For code review of logic and design — use `/review`
119	- For security-specific static analysis (SAST) — use `/cve-scan` or `/security-patterns`
120	- For project-specific rule authoring — edit the linter's config directly

People who liked this also viewed

6 picks

Type