agentleFS
jhd3197jhd3197/CachiBot/.claude/skills/lint-fix/SKILL.md

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

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.
  • NVIDIASkill

    docstring

    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

  • HashiCorpSkill

    changelog

    Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.

    Also in 5 projects that use this

  • SentrySkill

    commit

    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

  • CloudflareSkill

    security-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

  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

  • GoogleSkill

    tdd

    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

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
  1. Distinctive:

    Run every linter the project uses, collect all violations, and fix them in a single pass.

    line 8
  2. Distinctive:

    Run all four checks in parallel and collect their output:

    line 15
  3. Very specific:

    Important: When parsing mypy output, discard any finding whose file path is outside cachibot/ (e.g., errors in installed packages like …

    line 25
  4. Distinctive:

    If zero findings remain after filtering, tell the user everything is clean and stop.

    line 30
  5. Distinctive:

    Run the auto-fixers first to knock out the easy ones:

    line 34
  6. Distinctive:

    If the long line is a string literal inside a dict/list, wrap it with implicit string concatenation using parentheses:

    line 48
  7. Distinctive:

    If the long line is a function call or dict literal, break it into multi-line format.

    line 56
  8. Distinctive:

    If the long line is an import, use multi-line import with parentheses.

    line 58
  9. Distinctive:

    Never shorten user-facing strings by removing words — prefer wrapping.

    line 59
  10. Very specific:

    Add missing imports (from typing import Any, etc.) as needed.

    line 66
  11. Distinctive:

    Read both the call site and the target signature before deciding the fix.

    line 74
  12. Distinctive:

    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 …

    line 78
  13. Very specific:

    If removing it would break the type contract, keep it as _name and add an eslint-disable comment for that line only.

    line 80
  14. Distinctive:

    Read the file, understand the context, and apply the minimal fix.

    line 90
  15. Distinctive:

    If a fix would change runtime behavior, flag it in the summary rather than applying it silently.

    line 91
  16. Distinctive:

    Run all four linters again (same commands as Phase 0).

    line 96

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. ruff check cachibot/ — lint errors (E501, F841, etc.)
  2. ruff format --check cachibot/ — formatting drift
  3. mypy cachibot/ — type errors (only in cachibot/, NOT transitive errors from prompture or other installed packages)
  4. 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:

  1. ruff check --fix cachibot/ — auto-fix simple lint issues
  2. ruff format cachibot/ — reformat any drifted files
  3. cd 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 of Model(**data).
  • For str passed where a Literal[...] 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 _name and 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.