dart-run-static-analysis
Execute `dart analyze` to identify warnings and errors, and use `dart fix --apply` to automatically resolve mechanical lint issues. Use during development to ensure code quality and before committing changes.
Install
npx skills add https://github.com/flutter/agent-plugins --skill dart-run-static-analysisSKILL.md
Analyzing and Fixing Dart Code
Contents
- Analysis Configuration
- Diagnostic Suppression
- Workflow: Executing Static Analysis
- Workflow: Applying Automated Fixes
- Examples
Analysis Configuration
Configure the Dart analyzer using the analysis_options.yaml file located at the package root.
- Base Configuration: Always include a standard rule set (e.g.,
package:lints/recommended.yamlorpackage:flutter_lints/flutter.yaml) using theinclude:directive. - Strict Type Checks: Enable strict type checks under the
analyzer: language:node to prevent implicit downcasts and dynamic inferences. Setstrict-casts: true,strict-inference: true, andstrict-raw-types: true. - Linter Rules: Explicitly enable or disable specific rules under the
linter: rules:node. Use a key-value map (rule_name: true/false) when overriding included rules, or a list (- rule_name) when defining a fresh set. Do not mix list and map syntax in the samerulesblock. - Formatter Configuration: Configure
dart formatbehavior under theformatter:node. Setpage_width(default 80) andtrailing_commas(automateorpreserve). - Analyzer Plugins: Enable custom diagnostics by adding plugins under the
analyzer: plugins:node. Ensure the plugin package is added as adev_dependencyinpubspec.yaml.
Diagnostic Suppression
When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly.
- File-level Exclusion: Use the
analyzer: exclude:node inanalysis_options.yamlto exclude entire files or directories (e.g.,**/*.g.dart) using glob patterns. - File-level Suppression: Add
// ignore_for_file: <diagnostic_code>at the top of a Dart file to suppress specific diagnostics for the entire file. Use// ignore_for_file: type=lintto suppress all linter rules. - Line-level Suppression: Add
// ignore: <diagnostic_code>on the line directly above the offending code, or appended to the end of the offending line. - Pubspec Suppression: Add
# ignore: <diagnostic_code>above the offending line inpubspec.yamlfiles (e.g.,# ignore: sort_pub_dependencies). - Plugin Diagnostics: Prefix the diagnostic code with the plugin name when suppressing plugin-specific issues (e.g.,
// ignore: some_plugin/some_code).
Workflow: Executing Static Analysis
Use this workflow to identify type-related bugs, style violations, and potential runtime errors.
Task Progress:
- 1. Verify
analysis_options.yamlexists at the project root. - 2. Run the analyzer using the
analyze_filesMCP tool (if available) or the CLI commanddart analyze <target_directory>. - 3. Review the diagnostic output.
- 4. If info-level issues must be treated as failures, append the
--fatal-infosflag. - 5. Resolve reported errors manually or proceed to the Automated Fixes workflow.
Workflow: Applying Automated Fixes
Use this workflow to resolve outdated API usages, apply quick fixes, and migrate code (e.g., Dart 3 migrations).
Task Progress:
- 1. Execute a dry run to preview proposed changes using the
dart_fixMCP tool or CLI commanddart fix --dry-run. - 2. Review the proposed fixes to ensure they align with the intended architecture.
- 3. If additional fixes are required, verify that the corresponding linter rules are enabled in
analysis_options.yaml. - 4. Apply the fixes using the
dart_fixMCP tool or CLI commanddart fix --apply. - 5. Format the modified code using the
dart_formatMCP tool or CLI commanddart format .. - 6. Run the static analysis workflow to verify all diagnostics are resolved.
Examples
Comprehensive analysis_options.yaml
include: package:flutter_lints/recommended.yaml
analyzer:
exclude:
- "**/*.g.dart"
- "lib/generated/**"
language:
strict-casts: true
strict-inference: true
strict-raw-types: true
errors:
todo: ignore
invalid_assignment: warning
missing_return: error
linter:
rules:
avoid_shadowing_type_parameters: false
await_only_futures: true
use_super_parameters: true
formatter:
page_width: 100
trailing_commas: preserve
Inline Diagnostic Suppression
// Suppress for the entire file
// ignore_for_file: unused_local_variable, dead_code
void processData() {
// Suppress for a specific line
// ignore: invalid_assignment
int x = '';
const y = 10; // ignore: constant_identifier_names
}
Related skills
improve-codebase-architecturemattpocock1MScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.codebase-designmattpocock691KShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.web-design-guidelinesvercel-labs676KReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".code-reviewmattpocock631KReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".