agentleFS
hjdspacehjdspace/SpaceCode/.claude/skills/dart-fix-runtime-errors/SKILL.md

dart-fix-runtime-errors

Skill4 starsChanged 4 months agoMITView on GitHub

Uses get_runtime_errors and lsp to fetch an active stack trace, locate the failing line, apply a fix, and verify resolution via hot_reload.

5 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use dart-use-doc-examples and dart-write-documentation.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • flutterSkill

    dart-use-doc-examples

    How to inject external code examples into Dartdoc using the {@example} directive, and how to filter those files using #hide, #region, and #endregion tags.

    Also in 3 projects that use this

  • flutterSkill

    dart-write-documentation

    Rules and formatting guidelines for writing Dart /// API documentation and doc comments. Use when documenting Dart code, writing doc comments for any Dart declaration (libraries, classes, methods, variables, etc.), or when instructed to follow the Effective Dart documentation guidelines.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 3 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Generics & Collections: Add explicit type annotations to generic classes (e.g., List<T>, Map<K, V>).

    line 25
  2. Very specific:

    Downcasting: Avoid implicit downcasts from dynamic.

    line 26
  3. Very specific:

    Late Initialization: Use the late keyword for non-nullable variables guaranteed to be initialized before use.

    line 33
  4. Very specific:

    Wildcards: Use the _ wildcard variable (Dart 3.7+) for non-binding local variables or parameters to avoid unused variable warnings.

    line 34
  5. Very specific:

    Errors: Never explicitly catch Error or its subtypes (e.g., TypeError, ArgumentError).

    line 40
  6. Very specific:

    Rethrowing: Use rethrow inside a catch block to propagate an exception while preserving its original stack trace.

    line 41
  7. Distinctive:

    Use this sequential workflow to identify, fix, and verify static analysis errors in a Dart project.

    line 47
  8. Very specific:

    Use the dart fix tool to automatically resolve standard linting and analysis issues.

    line 62
  9. Distinctive:

    Verify if the variable can logically be null.

    line 74
  10. Very specific:

    If yes, use optional chaining (?.) or provide a fallback (??).

    line 75
  11. Very specific:

    If no, and initialization is guaranteed elsewhere, mark the declaration with late.

    line 76
  12. Very specific:

    Add explicit generic type annotations to the instantiation (e.g., <int>[] instead of []).

    line 79
  13. Very specific:

    Add the covariant keyword to the parameter if tightening the type is intentionally required by the domain logic.

    line 82
  14. Distinctive:

    Run the validator. Review errors.

    line 85

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Resolving Dart Static Analysis Errors

Contents

  • Core Concepts & Guidelines
    • Type System & Soundness
    • Null Safety
    • Error Handling
  • Workflows
    • Workflow: Static Analysis Resolution
  • Examples

Core Concepts & Guidelines

Type System & Soundness

Enforce Dart's sound type system to prevent runtime invalid states.

  • Method Overrides: Maintain sound return types (covariant) and parameter types (contravariant). Never tighten a parameter type in a subclass unless explicitly marked with the covariant keyword.
  • Generics & Collections: Add explicit type annotations to generic classes (e.g., List<T>, Map<K, V>). Never assign a List<dynamic> to a typed list (e.g., List<Cat>).
  • Downcasting: Avoid implicit downcasts from dynamic. Use explicit casts (e.g., as List<Cat>) when necessary, but ensure the underlying runtime type matches to prevent TypeError exceptions.
  • Strict Casts: Enable strict-casts: true in analysis_options.yaml under analyzer: language: to force explicit casting and catch implicit downcast errors at compile time.

Null Safety

Eliminate static errors related to null safety by correctly managing variable initialization and nullability.

  • Modifiers: Apply ? for nullable types, ! for null assertions, and required for named parameters that cannot be null.
  • Late Initialization: Use the late keyword for non-nullable variables guaranteed to be initialized before use. Apply this specifically to top-level or instance variables where Dart's control flow analysis cannot definitively prove initialization.
  • Wildcards: Use the _ wildcard variable (Dart 3.7+) for non-binding local variables or parameters to avoid unused variable warnings.

Error Handling

Distinguish between recoverable exceptions and unrecoverable errors.

  • Catching: Catch Exception subtypes for recoverable failures.
  • Errors: Never explicitly catch Error or its subtypes (e.g., TypeError, ArgumentError). Errors indicate programming bugs that must be fixed, not caught. Enforce this by enabling the avoid_catching_errors linter rule.
  • Rethrowing: Use rethrow inside a catch block to propagate an exception while preserving its original stack trace.

Workflows

Workflow: Static Analysis Resolution

Use this sequential workflow to identify, fix, and verify static analysis errors in a Dart project. Copy the checklist to track your progress.

Task Progress:

  • 1. Run static analyzer.
  • 2. Apply automated fixes.
  • 3. Resolve remaining errors manually.
  • 4. Verify fixes (Feedback Loop).

1. Run static analyzer Execute the Dart analyzer to identify all static errors in the target directory or file.

dart analyze . --fatal-infos

2. Apply automated fixes Use the dart fix tool to automatically resolve standard linting and analysis issues.

# Preview changes
dart fix --dry-run
# Apply changes
dart fix --apply

3. Resolve remaining errors manually Review the remaining analyzer output and apply conditional logic based on the error type:

  • If the error is a Null Safety issue (e.g., "Property cannot be accessed on a nullable receiver"):
    • Verify if the variable can logically be null.
    • If yes, use optional chaining (?.) or provide a fallback (??).
    • If no, and initialization is guaranteed elsewhere, mark the declaration with late.
  • If the error is a Type Mismatch (e.g., "The argument type 'List<dynamic>' can't be assigned..."):
    • Trace the variable's initialization.
    • Add explicit generic type annotations to the instantiation (e.g., <int>[] instead of []).
  • If the error is an Invalid Override (e.g., "The parameter type doesn't match the overridden method"):
    • Widen the parameter type to match the superclass, OR
    • Add the covariant keyword to the parameter if tightening the type is intentionally required by the domain logic.

4. Verify fixes (Feedback Loop) Run the validator. Review errors. Fix.

dart analyze .
dart test
  • If dart analyze reports errors: Return to Step 3.
  • If dart test fails with a TypeError: You have introduced an invalid explicit cast (as T) or accessed an uninitialized late variable. Locate the runtime failure and correct the type hierarchy or initialization order.

Examples

Example: Fixing Dynamic List Assignments

Input (Fails Static Analysis):

void printInts(List<int> a) => print(a);

void main() {
  final list = []; // Inferred as List<dynamic>
  list.add(1);
  list.add(2);
  printInts(list); // Error: List<dynamic> can't be assigned to List<int>
}

Output (Passes Static Analysis):

void printInts(List<int> a) => print(a);

void main() {
  final list = <int>[]; // Explicitly typed
  list.add(1);
  list.add(2);
  printInts(list);
}

Example: Fixing Method Overrides (Contravariance)

Input (Fails Static Analysis):

class Animal {
  void chase(Animal a) {}
}

class Cat extends Animal {
  @override
  void chase(Mouse a) {} // Error: Tightening parameter type
}

Output (Passes Static Analysis):

class Animal {
  void chase(Animal a) {}
}

class Cat extends Animal {
  @override
  void chase(covariant Mouse a) {} // Explicitly marked covariant
}

Example: Fixing Null Safety with late

Input (Fails Static Analysis):

class Thermometer {
  String temperature; // Error: Non-nullable instance field must be initialized

  void read() {
    temperature = '20C';
  }
}

Output (Passes Static Analysis):

class Thermometer {
  late String temperature; // Defers initialization check to runtime

  void read() {
    temperature = '20C';
  }
}

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.