agentsclimarketplace

Linting setup

Skill Amey-Thakur/AI-SKILLS/skills/code-quality/linting-setup

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill linting-setup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Triage lint rules so bug-catchers are errors, style is left to the formatter, and every suppression carries a reason. Use when configuring a linter, taming warning noise, or setting a suppressions policy.

SKILL.md

2.8 KB, 644 tokens by cl100k_base, as published. Nobody here has run it

Linting setup

A linter tuned to shout about every stylistic preference trains the team to ignore it, and the one rule that would have caught a real bug scrolls past in the noise. A useful lint config is triaged: bug-finding rules are errors, style is left to the formatter, and every suppression is narrow and justified.

Method

  1. Split rules into bugs, style, and noise. Set bug-finding rules to error (no-unused-vars, no-floating-promises, react-hooks/exhaustive-deps, eqeqeq, clang-tidy bugprone-*). Hand pure-style rules to the formatter and turn them off. Turn opinion-only rules off, not warn: warnings accumulate and get ignored.
  2. Start from a vetted base, then subtract. Extend eslint:recommended, @typescript-eslint/recommended, ruff's default set, or golangci-lint's defaults, and disable the specific rules that fight your codebase rather than assembling a config from nothing. Record why each disable exists in a comment beside it.
  3. Make warnings fail or make them nothing. Run with --max-warnings 0 in CI so warning and error collapse into one bar: the build passes or it does not. A pipeline that tolerates 400 warnings is a pipeline with no linter.
  4. Suppress narrowly and with a reason. A suppression names one rule on one line with a why: // eslint-disable-next-line no-await-in-loop -- sequential rate limit. Ban file-wide eslint-disable and bare # noqa; those switch the linter off for everything, not the one case.
  5. Enable type-aware rules where they exist. @typescript-eslint with type information, ruff's flake8-bugbear set, and clang-tidy's analysis catch defects a syntactic pass cannot: unhandled promises, mutable default arguments, use-after-move. They cost CI seconds and earn them.
  6. Ratchet on legacy code, do not boil the ocean. Lint only changed files in CI (lint-staged or a diff filter) so new code meets the bar while the backlog shrinks with each touch. A one-shot fix of 5000 findings gets reverted; a ratchet holds.

Signals

  • Does a lint error reliably mean a bug or a real risk, not a style opinion?
  • Does every suppression in the tree name a rule and a reason?
  • Is the CI warning budget zero, or is it quietly unbounded?

Boundaries

Linting overlaps a real type checker but does not replace one: for deep correctness lean on tsc, mypy, or the compiler. Formatting stays with the formatter. When a rule and the team's actual practice disagree, decide once and encode the decision in config, not in repeated review comments.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 327,132. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.