lint-fix
Skill19 starsChanged 9 months agoMITView on GitHub
Run all project linters (ruff check, ruff format, mypy, eslint) and auto-fix every violation. Fixes line-length, type annotations, unused vars, and formatting in one pass.
17 other projects use a version of this.
Adopted by
Most recently taken up by
- dirien/yet-another-agent-harnesstheir own version, first seen Nov 8, 2026
- allanninal/claude-code-skillstheir own version, first seen Oct 17, 2026
- chrisselig/claude-code-toolkittheir own version, first seen Oct 9, 2026
- llp-dev/claude-skillstheir own version, first seen Sep 9, 2026
- llp42/claude-skillstheir own version, first seen Sep 9, 2026
- soumatheusgomes/agentvilletheir own version, first seen Aug 13, 2026
Used with
Projects with it also use docstring, changelog and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
NVIDIASkilldocstring
Write or review docstrings for public modules, classes, and functions in sdm/. Use when adding or reviewing docstrings to follow repo best practices (Args sections, paper citations, tensor shape notation).
Also in 3 projects that use this
HashiCorpSkillchangelog
Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.
Also in 5 projects that use this
SentrySkillcommit
Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.
Also in 5 projects that use this
CloudflareSkillsecurity-audit
Security guidance and vulnerability review for codebases, APIs, services, CLI tools, libraries, and daemons. Use for security questions, focused reviews, vulnerability research, security audits, or pen tests. Run the complete workflow only for explicit codebase audit or pen-test requests, full/comprehensive/end-to-end reviews, or requested report artifacts.
Also in 3 projects that use this
SentrySkillreview
Fixture review skill.
Also in 3 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 3 projects that use this
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 17
- getsentry/sentry★ 46ksame name
- dirien/yet-another-agent-harness★ 19same name
- minh2004pd/chatbotfullpipeline★ 18same name
- emaraschio/cursor-commands★ 9same name
- soumatheusgomes/agentville★ 9same name
- peopleforrester/claude-dotfiles★ 3same name
- fotoflo/claude-skills★ 2same name
- lodetomasi/claude-code-training-lab★ 2same name
- Pradnyeshp/Claude-Skills★ 2same name
- yu-iskw/meta-agent-skills★ 2same name
7 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cachibot-api-routeSkill
- cachibot-frontend-viewSkill
- cachibot-full-stack-entitySkill
- cachibot-pluginSkill
- cachibot-websocket-eventSkill
- code-reviewSkill
- create-prSkill
- review-fixSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 13 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 16 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Run every linter the project uses, collect all violations, and fix them in a single pass.
- Distinctive: line 15
Run all four checks in parallel and collect their output:
- Very specific: line 25
Important: When parsing mypy output, discard any finding whose file path is outside cachibot/ (e.g., errors in installed packages like …
- Distinctive: line 30
If zero findings remain after filtering, tell the user everything is clean and stop.
- Distinctive: line 34
Run the auto-fixers first to knock out the easy ones:
- Distinctive: line 48
If the long line is a string literal inside a dict/list, wrap it with implicit string concatenation using parentheses:
- Distinctive: line 56
If the long line is a function call or dict literal, break it into multi-line format.
- Distinctive: line 58
If the long line is an import, use multi-line import with parentheses.
- Distinctive: line 59
Never shorten user-facing strings by removing words — prefer wrapping.
- Very specific: line 66
Add missing imports (from typing import Any, etc.) as needed.
- Distinctive: line 74
Read both the call site and the target signature before deciding the fix.
- Distinctive: line 78
If the parameter is required by a callback signature but not used in the body, remove it entirely (JS/TS doesn't enforce arity on …
- Very specific: line 80
If removing it would break the type contract, keep it as _name and add an eslint-disable comment for that line only.
- Distinctive: line 90
Read the file, understand the context, and apply the minimal fix.
- Distinctive: line 91
If a fix would change runtime behavior, flag it in the summary rather than applying it silently.
- Distinctive: line 96
Run all four linters again (same commands as Phase 0).
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Lint Fix — Full Project Lint & Type Sweep
Run every linter the project uses, collect all violations, and fix them in a single pass. Handles Python (ruff + mypy) and TypeScript (eslint) together.
Instructions
Phase 0 — Run All Linters
Run all four checks in parallel and collect their output:
ruff check cachibot/— lint errors (E501, F841, etc.)ruff format --check cachibot/— formatting driftmypy cachibot/— type errors (only incachibot/, NOT transitive errors from prompture or other installed packages)cd frontend && npx eslint src/— TypeScript lint (errors only, warnings are informational)
Parse each tool's output into a list of { tool, file, line, code, message } findings.
Important: When parsing mypy output, discard any finding whose file path is
outside cachibot/ (e.g., errors in installed packages like prompture). Also
discard import-not-found errors for prompture.* and tukuy.* modules — those are
expected when the editable installs are out of sync and are not CachiBot bugs.
If zero findings remain after filtering, tell the user everything is clean and stop.
Phase 1 — Auto-Fix What Tools Can
Run the auto-fixers first to knock out the easy ones:
ruff check --fix cachibot/— auto-fix simple lint issuesruff format cachibot/— reformat any drifted filescd frontend && npx eslint src/ --fix— auto-fix simple TS issues
Phase 2 — Fix Remaining Violations
Re-run the linters from Phase 0 to see what remains after auto-fix.
For each remaining finding, apply the appropriate fix strategy:
ruff E501 (line too long)
- If the long line is a string literal inside a dict/list, wrap it with
implicit string concatenation using parentheses:
"description": ( "First part of the string" " second part of the string" ), - If the long line is a function call or dict literal, break it into multi-line format.
- If the long line is an import, use multi-line import with parentheses.
- Never shorten user-facing strings by removing words — prefer wrapping.
mypy type-arg (missing generic parameters)
dict→dict[str, Any](or more specific types if obvious from context)list→list[str](or the appropriate element type)tuple→ fill in the actual element types- Add missing imports (
from typing import Any, etc.) as needed.
mypy arg-type (incompatible argument types)
- For TypedDict → Pydantic model mismatches, use
Model.model_validate(data)instead ofModel(**data). - For
strpassed where aLiteral[...]is expected, change the parameter type annotation to use the Literal type. - Read both the call site and the target signature before deciding the fix.
eslint no-unused-vars
- If the parameter is required by a callback signature but not used in the body, remove it entirely (JS/TS doesn't enforce arity on callbacks).
- If removing it would break the type contract, keep it as
_nameand add an eslint-disable comment for that line only.
eslint react-hooks/exhaustive-deps
- These are warnings, not errors. Do NOT fix them unless the user explicitly asked to fix warnings too. Log them in the summary as "skipped warnings."
Other violations
- Read the file, understand the context, and apply the minimal fix.
- If a fix would change runtime behavior, flag it in the summary rather than applying it silently.
Phase 3 — Verify
Run all four linters again (same commands as Phase 0). If new violations appear from the fixes, fix those too (max 2 retry rounds to avoid infinite loops).
Phase 4 — Summary
Print a concise summary:
Lint fix complete.
ruff check: N fixed (was N violations)
ruff format: N files reformatted
mypy: N fixed (N filtered as external)
eslint: N errors fixed, N warnings skipped
Files modified:
- path/to/file.py (ruff E501, mypy type-arg)
- path/to/other.tsx (eslint no-unused-vars)Important Rules
- Read before edit — always read a file before modifying it.
- Minimal changes — fix exactly the violation, nothing more. Don't refactor surrounding code, add docstrings, or "improve" things.
- Don't fix warnings — eslint warnings (react-hooks/exhaustive-deps, react-refresh/only-export-components) are informational. Only fix errors.
- Filter external errors — mypy errors in prompture, tukuy, or other installed packages are NOT CachiBot bugs. Discard them.
- Don't create files — this is a fix pass. No new files.
- Don't run tests — lint fixing doesn't require test execution.
- Preserve behavior — every fix must be semantically equivalent. If you're unsure a fix is safe, skip it and note it in the summary.
- Max line length is 100 — this is the ruff config for the project.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

