Dart Language

Write clear Dart that fits the project's SDK constraint and established style.

Decisions

• Read the SDK constraint in pubspec.yaml before using newer syntax.
• Prefer simple types and direct control flow over abstractions with no demonstrated reuse.
• Model closed variants with sealed types when exhaustive switching improves correctness.
• Use records for small structural values; use named domain types when identity, validation, documentation, or evolution matters.
• Use pattern matching when it makes branching or destructuring clearer, not as a novelty.
• Preserve public API compatibility unless a breaking change is requested.
• Keep mutable state private and expose the smallest useful surface.

Follow Effective Dart naming, documentation, usage, and design guidance. Match repository lint rules rather than adding conflicting style policy.

Verification

Use Dart MCP semantic lookup and analysis when the current environment exposes them; otherwise inspect source and use the project CLI. Run formatting, static analysis, and the narrowest relevant tests. When changing a public package API, check examples and downstream call sites.

Boundaries

• Async, streams, cancellation, and isolates: use dart-concurrency.
• Flutter widget composition or state ownership: use the relevant Flutter skill.
• JSON and persistence schema behavior belongs to the corresponding data skill.

Sources

• Dart language
• Effective Dart
• Dart and Flutter MCP server