Run codegen
General, reusable Flutter engineering skills for AI coding agents — architecture, Riverpod 3.x, testing, persistence, i18n/RTL, accessibility, navigation & more. Agent Skills open standard; works with Claude Code, Cursor, Codex & 70+ agents.
npx -y skills add zakariaf/Flutter-Skills --skill run-codegenAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Runs the deterministic build_runner codegen pass (drift_dev, freezed, json_serializable, riverpod_generator) as one pinned command with --delete-conflicting-outputs, always before flutter analyze, never hand-editing or force-committing generated *.g.dart / *.freezed.dart / *.drift.dart output, watch only in local dev. Use when regenerating codegen, fixing "missing part file" / "conflicting outputs" / undefined generated-class analyzer errors, after editing a drift table or DAO, a freezed value object, a riverpod Notifier or provider, or a json_serializable model, or after a fresh git clone, branch switch, or pull.
SKILL.md
7.2 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it
Run codegen (build_runner)
A deterministic, low-freedom runbook: regenerate all annotation-driven code in
one pass, then analyze. Run the pinned command exactly as written — do not
modify it, add flags, or hand-edit generated files. Applies whenever a source
file carries a codegen annotation (@freezed, @JsonSerializable,
@riverpod, @DriftDatabase, a drift table) and its *.g.dart /
*.freezed.dart / *.drift.dart part is missing or stale.
Non-negotiable rules
- Run codegen BEFORE
flutter analyze. A fresh clone, branch switch, or freshly edited annotated file has no generated part on disk. Analyzing that tree produces misleading "missing part file" and undefined-class errors that describe the missing output, not a real code defect — regenerate, then analyze. - Use the pinned command verbatim, always with
--delete-conflicting-outputs. Without it, build_runner refuses to overwrite an output it did not write this run and fails with a wall of "conflicting outputs" text. That is a stale-file collision, not a bug — do not go hunting for one. - Never hand-edit a generated file. The next build silently reverts it and takes your edit with it. Change the annotated source — the drift table, the freezed class, the Notifier, the ARB — and rerun.
- Never
git add -fa generated file. Whether generated code is committed or gitignored is one decision owned bycodegen-and-toolchain; whichever the repo chose, never force-add an artifact past the ignore rules or commit one the current source would not reproduce. watchis a local-dev convenience, never CI or a pre-commit hook. CI and the pre-analyze step always use the one-shotbuild.- Fix hand-written source first. The generator reads a resolved AST; it
cannot generate from source that does not analyze. An unrelated error
anywhere in
lib/can block generation of a table or provider — clear those before blaming codegen.
The canonical command
Run from the package root (single-package app) or the workspace root (multi-package repo):
dart run build_runner build --delete-conflicting-outputs
This is the first step in every CI lane and on every fresh clone, before format and analyze.
Standard sequence on a fresh clone, pull, or branch switch
flutter pub get(resolve dependencies).dart run build_runner build --delete-conflicting-outputs(regenerate).- Only then
flutter analyze.
Skipping step 2 is the single most common cause of a red analyzer on a clone whose code is actually fine.
Dev iteration (optional watch)
For an active edit loop on annotated sources, run the watcher instead of a one-shot build; it rebuilds affected outputs on save:
dart run build_runner watch --delete-conflicting-outputs
Stop the watcher before running the one-shot build — two concurrent
build_runner processes over the same tree race on outputs.
When multi-package (workspace)
build_runner runs per-package: one invocation regenerates the current package
plus its path-dependency packages, not automatically every sibling in the
workspace. So running the single command at the workspace root covers the
root package and its path dependencies in one pass, but a coordinator-style root
that does not itself depend on every member will not regenerate those siblings.
For full multi-package regeneration, use the repo-level fan-out wrapper (e.g.
melos run gen) that runs the command over every workspace member; prefer it
when the workspace is bootstrapped. To deliberately scope one package during
development, run the same command from that package's directory. Builder scoping
(which files each builder reads) lives in each package's build.yaml, owned by
codegen-and-toolchain.
When codegen and the analyzer disagree
The analyzer reads files on disk; build_runner writes them. A disagreement almost always means the disk is behind, not that the code is wrong.
| Symptom | Do this |
|---|---|
| Analyzer flags an undefined class/getter that codegen should produce | Rerun the pinned build, then restart the analysis server. Do not "fix" the call site. |
Errors reported inside a *.g.dart / *.freezed.dart / *.drift.dart file | The file is stale or the analyzer excludes are wrong. Regenerate first; never hand-edit generated output. |
| build_runner fails with analyzer errors in hand-written source | Fix the hand-written source — the generator cannot resolve an unanalyzable AST. |
| "Conflicting outputs" wall of text | Re-run with --delete-conflicting-outputs; it clears stale outputs from renamed/deleted sources. |
Anti-patterns
- Running
flutter analyzebefore codegen on a fresh tree — you chase phantom missing-part errors that regeneration erases. - Dropping
--delete-conflicting-outputs— the first rename or deletion fails the whole run on a stale-output collision. - Editing a
.g.dart/.freezed.dart/.drift.dartby hand — the next build reverts it; the fix belongs in the annotated source. git add -fon a gitignored generated file — bypasses the repo's committed-vs-gitignored decision and ships a possibly-stale artifact.build_runner watchin CI or a pre-commit hook — non-deterministic; CI must use the one-shotbuild.
Definition of done
- The pinned
dart run build_runner build --delete-conflicting-outputsran at the package/workspace root without "conflicting outputs" errors. - It ran before
flutter analyze, which is now green. - No generated file was hand-edited or force-added.
- No
build_runner watchprocess is wired into CI or hooks.
Related skills
- See
codegen-and-toolchainfor the knowledge behind this runbook:build.yamlbuilder scoping, the commit-vs-gitignore-generated-code decision, SDK pinning, and analyzer/coverage excludes for generated files. - See
run-migrationfor the drift schema-snapshot and migration ritual that wrapsdrift_dev make-migrationsaround this codegen pass. - See
ci-pipeline-and-gatesfor the CI freshness gate that reruns this command and diffs the tree. - See
lint-and-style-configfor the analyzer excludes that keep generated files out of lint scope.
References
- build_runner: https://pub.dev/packages/build_runner
- Dart tools — build_runner usage: https://dart.dev/tools/build_runner
- drift codegen: https://drift.simonbinder.eu/docs/getting-started/
- freezed: https://pub.dev/packages/freezed
- riverpod_generator: https://pub.dev/packages/riverpod_generator
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most pr commit review skills give in ~1.5k tokens
Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07
- Use conventional commits formatin 127 of 888, across 115 files
- Keep subject line under 72 charactersin 62 of 888, across 48 files
- Delete branches after mergein 51 of 888, across 38 files
- Use imperative mood in subject linein 51 of 888, across 42 files
- Use imperative mood in commit messagesin 44 of 888
- Verify directory is ignored before creating worktreein 43 of 888, across 12 files
- Generate a conventional commit messagein 43 of 888
- Add unignored worktree directories to gitignorein 42 of 888, across 10 files
- Make atomic commitsin 39 of 888, across 27 files
- Run tests before committingin 36 of 888, across 25 files
- Verify clean test baselinein 35 of 888, across 9 files
- Split unrelated changes into separate commitsin 35 of 888, across 30 files
Said here and by no other author read
- run codegen before analyze
- run flutter pub get first
- use the pinned build command verbatim
- always include delete-conflicting-outputs
- fix hand-written source errors first
- stop the watcher before running one-shot build
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.