dart-async-correctnesslisted

Use for ANY Dart or Flutter work that touches a Future, async/await, .then(), or data loading — writing, fixing, refactoring, speeding up, or reviewing it. This is the default skill the moment async appears in Dart code. Concretely, reach for it when the task involves: marking a function async or chasing an "analyzer says missing await"; a slow screen that awaits independent loads one-by-one (wants Future.wait); loading data when a screen opens, or a FutureBuilder that re-fetches/flickers on rebuild; converting .then() chains to async/await; fire-and-forget calls in initState/dispose/handlers; using context/setState/Navigator/ScaffoldMessenger after an await; or reviewing a Dart diff that adds awaits, async functions, or unawaited calls. These bugs rarely throw — they leak widgets, swallow errors, rebuild with stale data, or add hidden latency, and flutter_lints catches almost none. Apply even when it "just adds one await." Dart/Flutter only — never TypeScript or other languages.
antgrid-ai/antgrid · ★ 2 · Code & Development · score 58

Install: claude install-skill antgrid-ai/antgrid

# Dart Async Correctness Async bugs in Dart are quiet. A missing `await`, a `BuildContext` used after a gap, a `.then()` that drops an error — none of these crash loudly or trip `flutter analyze` under this project's `flutter_lints` config. They surface later as leaked widgets, "setState after dispose", swallowed exceptions, UI flicker, or latency nobody can explain. So the discipline has to come from how the code is written, not from a tool catching it after the fact. This project (`app/`, `packages/antgrid_relay_client/`, `packages/antgrid_eval_client/`) already uses the right idioms: `unawaited(...)` for deliberate fire-and-forget, `mounted` / `context.mounted` guards after awaits, `Future.wait([...])` for concurrency, and Riverpod `AsyncValue` instead of `FutureBuilder`. Match those. The patterns below explain *why* each one matters so you can apply the judgment, not just the rule. ## The one question to ask every time **"This call returns a Future — what happens to it?"** Every Future has exactly three honest destinies: 1. **Awaited** — you need its result or its completion before continuing. 2. **`unawaited(...)`** — you deliberately don't wait, and you've made sure its errors can't vanish. 3. **Returned** — you hand it to your caller to await. A Future that is none of these (a bare `doThing();` where `doThing` is async) is a bug in waiting: its errors become unhandled, its ordering is undefined, and the analyzer won't warn you. If you find yourself writing one, s