flutter_agent_lints #

Strict Dart and Flutter analysis options for codebases that are written mostly by coding agents.

Every lint rule and analyzer diagnostic of the targeted Dart SDK is either enabled as an error or explicitly disabled with a one-line reason. Nothing is left at its default. The goal is to minimize the solution space: where the language or the linter offers two ways to write something, exactly one is allowed, and the analyzer enforces it instead of a reviewer.

Install #

dart pub add dev:flutter_agent_lints

# analysis_options.yaml
include: package:flutter_agent_lints/analysis_options.yaml

The file works for Flutter apps and for pure Dart packages alike. Flutter specific rules are inert when Flutter is not imported.

To opt into the rules the SDK still marks experimental (they can be renamed or removed between SDK releases):

include: package:flutter_agent_lints/experimental.yaml

Principles #

In priority order:

1. Robustness. Anything that prevents a class of bugs is on: unawaited futures, bare catches, dynamic calls, unclosed sinks, BuildContext across async gaps.
2. One way to write it. Single quotes, package imports, final locals, expression bodies, sorted members. Style is decided in the file, not in review.
3. Token efficiency. Types and keywords are required only where they carry information the compiler cannot derive. Local variable types are omitted, closure parameter types are omitted, doc comments are not mandatory.

What the file contains #

lib/analysis_options.yaml is the whole product and is meant to be read. It has:

• Strict language modes: strict-casts, strict-inference, strict-raw-types.
• Formatter pinned to the defaults (page_width: 80, trailing_commas: automate) so they are never a project-level choice.
• Excludes for generated files (*.g.dart, *.freezed.dart, and friends).
• Every stable lint rule of the SDK, alphabetically, as true or false with a reason.
• Everything that is on is an error, including every warning- and info-level analyzer diagnostic (todo too). An agent can ignore a warning; it cannot ignore an error.

The reason a rule is on or off sits next to the rule in the file. That is the single source of truth; nothing here repeats it.

Contributing #

To propose a rule change, edit the rule's line in lib/analysis_options.yaml, state the new reason in the comment, and regenerate lib/errors.yaml:

dart run tool/generate.dart