mcpField
D
dart-language

dart-language

github.com/thienqoDevelopment1799 installsUpdated 1d ago
Repository

About dart-language

A coding skill for writing Dart that respects a project’s SDK constraint, established conventions, and Effective Dart guidance. It also covers API compatibility, generated-file boundaries, and verification through formatting, analysis, and tests.

Key features

  1. 01Check SDK constraints in pubspec.yaml
  2. 02Follow Effective Dart and repository lints
  3. 03Preserve public API compatibility
  4. 04Avoid editing generated files by hand
  5. 05Run formatting, static analysis, and relevant tests

Use cases

  1. 01Implement features in an existing Dart project
  2. 02Model closed variants and clear branching
  3. 03Change a public package API and check callers
  4. 04Verify changes involving code-generation sources

MCP support

When available in the environment, it uses Dart MCP for semantic lookup and analysis. Otherwise, it inspects source and uses the project CLI.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/thienqo/flutter-skills --skill dart-language

After installing, type/dart-languagein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
code-generation-with-build-runner.md
patterns-and-records-migration.md
sealed-class-hierarchies.md

Details

From the project README

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.
  • Never hand-edit a generated file (*.g.dart, *.freezed.dart, or any file marked as generated); edit the annotated source and regenerate through the project's command.

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.
  • Regenerating after a code-generator or build_runner version bump belongs to flutter-dependency-upgrades; this skill owns writing correctly against an already-pinned generator version.

References

  • Read patterns and records migration when adopting pattern matching, destructuring, switch expressions, or multiple returns.
  • Read sealed class hierarchies when designing algebraic data types, closed result models, or exhaustively verified state families.
  • Read code generation with build_runner when a class uses freezed, json_serializable, or another build_runner generator, or when generated code is stale, conflicting, or failing to build.

Sources

Comments

Markdown supported