Agent skill · software engineering · zed-industries
lint-creator
Add, modify, or test a custom dylint lint in `tooling/lints`. Covers the module/registration layout, UI test conventions (including negative tests and the gpui test fixture), how to run tests with the crate's pinned nightly and update `.stderr` files, and how to validate a lint against the real codebase with `single-lint`. Use whenever the user asks to write a new lint or debug an existing one.
Why this skill is useful
Codifies specific lint creation standards and testing requirements that the AI could infer but now doesn't have to guess.
What it needs
About 2k tokens when loaded. Last updated 2026-08-07. 88,167 stars on the source repository.
What this skill does
Adding a dylint to tooling/lints Before writing anything 1. Check whether clippy already covers the pattern (search https://rust-lang.github.io/rust-clippy/master/). If it does, stop and report that to the user instead of writing a redundant lint. Layout One module per lint: src/<lintname>.rs, declared in src/lib.rs. Register the lint in registerlints in src/lib.rs: add it to the lintstore.registerlints(&[...]) slice and add a registerlatepass call. Use src/notifyinrender.rs as the template: rustcsession::declarelint! with ### What it does / ### Why is this bad? doc sections, impllintpass!, and a LateLintPass impl that bails early with let ... else / early returns. Do NOT copy the diagnostics style of sharedstringfromstrliteral in lib.rs — it predates the rules below (it emits a machine-applicable suggestion). The two lints living directly in lib.rs also predate the one-module-per-lint rule. Reuse the helpers in src/renderhelpers.rs (isdirectlyinrendermethod, isgpuicontext) for render/gpui checks. Diagnostics rules Flag only; never suggest how to fix, and never use Applicability::MachineApplicable. Keep detection and reporting as simple as possible: prefer spanlint with a one-sentence message over spanlintandthen with notes. Skip macro-expanded code (expr.span.fromexpansion()). UI tests (required) Every lint needs ui/<lintname>.rs and ui/<lintname>.stderr. The .rs file must include negative cases: code that resembles the bad pattern but must produce no diagnostic. Their absence from the .stderr file is the assertion. UI tests that need gpui types use the fake gpui crate in testfixture/ (wired up by gpuifixturerustcflags in lib.rs). Extend the fixture if a type or method is missing — never add real gpui as a dependency. The crate is deliberately not part of the zed workspace and pins its own nightly (rust-toolchain.toml). …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills zed-industries/lint-creator