Menu
Behavioral guidelines for Flutter base tasks: clarify ambiguity, keep changes simple and surgical, and define verifiable success criteria before coding.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Scaffolds a new feature module under apps/main/lib/presentation/modules using the bundled module generator
Reviews UI-layer changes — screens, blocs, widgets, routes — against the template's StateBase + CoreBlocBase + fl_theme conventions
Awareness index of every reusable widget in fl_ui, fl_theme, fl_media, and core's common_widget — name, one-line purpose, when to reach for it instead of writing a new one
Builds the data layer with Freezed DTOs, Retrofit clients, the storage-seam local data manager, and repositories wired through injectable
Teaches and applies Flutter/Dart dependency injection with Injectable + GetIt, grounded in this repo's Clean Architecture and code generation conventions. Use when changing DI wiring, adding BLoCs/use cases/repositories/modules, using @Named/@preResolve/@factoryParam/env registrations, reviewing DI best practices, or setting up DI tests.
Writes unit and widget tests for blocs, repositories, and screens using bloc_test + mocktail
| name | fl-behavioral-guardrails |
| description | Behavioral guidelines for Flutter base tasks: clarify ambiguity, keep changes simple and surgical, and define verifiable success criteria before coding. |
| license | MIT |
| metadata | {"audience":"ai-coding-agents","framework":"flutter","pattern":"behavioral-guidelines"} |
Use this skill when writing, reviewing, refactoring, or planning code in the Flutter base template. It adapts the reusable ideas from the Karpathy-inspired claude-skills project to this repo's conventions.
Tradeoff: these guardrails bias toward caution over speed. For trivial one-line fixes, use judgment.
Do not silently choose an interpretation when the request is ambiguous.
Before implementing:
Flutter base examples:
fl-module-scaffold, fl-bloc-pattern, and fl-route-config rather than ad-hoc Flutter structure.Write the minimum code that solves the current request.
fl_ui, core, or module widget fits — check fl-ui-components for the catalog.fl-bloc-pattern.make lang.The test: if the same behavior can be expressed with an existing helper or pattern, reuse it.
Every changed line should trace back to the user request or to a required generator output.
When editing:
If a command causes broad churn, pause and ask whether to keep or revert it.
Turn each task into a verifiable outcome.
For multi-step work, track:
1. Change source of truth → verify generated/config output
2. Update call sites → verify stale references are gone
3. Run targeted checks → verify analyzer/tests pass
Prefer concrete checks:
rg for stale identifiers, locale codes, or old keys.make lang after localization CSV edits.make gen_core, make gen_main, or make gen_all only after relevant generated inputs change.fvm flutter analyze --no-pub from affected packages.Use these before editing derived files:
| Area | Source of truth | Regenerate/check |
|---|---|---|
| App IDs/display names | apps/main/app_identifier.yaml | sh gen_app_identifier.sh apps/main |
| App/core/media strings | */lib/l10n/localizations.csv | make lang |
BLoC _StateData / JSON / DI | annotated Dart files | make gen_core, make gen_main, or make gen_all |
| Theme tokens | plugins/fl_theme/ and existing extensions | fvm flutter analyze --no-pub |
| Navigation | IRoute, CustomRouter, coordinators | fl-route-config checklist |