Every file that opens with `import 'package:flutter/material.dart';` has to open with `import 'package:material_ui/material_ui.dart';` instead [3]. That is a regex and a pubspec line. It is also the part an assistant gets plausibly wrong rather than obviously wrong: the first failure the dev.to walkthrough lists is a model inventing a deprecated import path or a package name that does not exist [9]. A bogus import string breaks the build, so you find it immediately. That is the good case.
The other two failures on that list are not string problems [14]. One is that the model does not know the Dart analyzer ships data-driven fix rules for this migration, so it hand-edits what the toolchain would rewrite for it [9]. The other is localization delegates, specifically `GlobalMaterialLocalizations` [9]. Delegate wiring compiles fine, then surfaces later, well removed from the diff that caused it.
The interesting claim in the post isn't that an agent can do the migration -- it's the ordering. The runbook's first phase hands the mechanical edit to the built-in Dart toolchain fix runner rather than to the model; the supplied text cuts off mid-command, after `dart f` [13]. That is the right instinct. A deterministic rewriter with a rule table beats a token predictor at bulk edits, and the model's job shrinks to the residue the fix rules do not cover.
The delivery mechanism is a checked-in file. `dart-sdk-skills` is a repository of version-by-version agent skills for the Dart and Flutter SDKs, written against the open Agent Skill specification as `SKILL.md`, disclosing rules, API matrices and upgrade runbooks progressively instead of as one prompt-sized dump [10]. Installation is `npx skills add RandalSchwartz/dart-sdk-skills -g`, or a clone plus a symlink of `skills/flutter-sdk-changelog` into `~/.gemini/config/skills/` [11]. One of those three paths writes into a Gemini-specific directory, so "global" here means global to one tool [16].
Why this route at all: the packages postdate the models. The post's argument is that Claude Code, Google Antigravity, Cursor, GitHub Copilot and Cline all still generate the monolithic `package:flutter/material.dart` import because of training cutoffs [7][8], and Material and Cupertino now live at `material_ui` `^1.1.0` and `cupertino_ui` `^1.0.1` on pub.dev, maintained by the Flutter team, layered over `package:flutter/widgets.dart` in the core SDK [3][4][2][5].
What would have to be true for the one-prompt result to transfer to your repo. Your project needs to be on an SDK version the repository actually carries a skill for, since the skills are cut per version [10]. Your Material usage needs to sit inside whatever the analyzer's fix rules cover, because everything outside that boundary is back to being generated text [9]. And you need a test that fails when a localization delegate is wrong, which is a harder thing to own than an import audit.
None of that is checkable from the material. The supplied text stops at the first phase [13], so there is no file count, no diff size and no reported outcome. Treat the migration as a workload description from someone else's project. The mechanism is sound; the runbook is a claim about a codebase you have not seen.
One durable consequence: the skill file now carries load-bearing authority over an API surface someone else owns [10]. Nothing in the build checks that it matches the packages it describes.
