القائمة
Behavioral guidelines for Flutter base tasks: clarify ambiguity, keep changes simple and surgical, and define verifiable success criteria before coding.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 |