evanca/flutter-ai-rules: 36 Flutter and Dart Skills Your Coding Agent Loads on Its Own

The problem: rules files that go stale and docs you forget to mention

Most Flutter teams that use an AI coding agent end up maintaining a rules file. Someone writes conventions into it, someone else stops updating it, and the agent keeps generating code against a snapshot of how the project worked six months ago. The alternative habit is worse in a different way: remembering to @-mention the right documentation page every time you touch authentication or a provider.

evanca/flutter-ai-rules targets that gap. It is a set of 36 skills, each one a folder containing a SKILL.md file. The README describes the intended loop plainly: your agent reads the description, decides a task matches, and pulls in the guidance. Install once, and Firebase Auth guidance shows up when you touch auth, Riverpod guidance when you touch providers.

The audience is narrow and identifiable. You need an agent that supports the skills convention, and you need to be writing Flutter or Dart. The repository also ships rules/ and combined/ directories, which matter for agents that consume a rules file rather than a skill folder, and a plugin.json plus per-agent manifests under .claude-plugin/, .codex-plugin/, .cursor-plugin/ and .agents/plugins/. The project describes its content as almost non-opinionated, derived from official Flutter, Dart, Firebase and package documentation rather than personal preference. That claim is the whole pitch: if you disagree with a house style, this set will not encode it for you.

How skill selection works and where the files live

The mechanism is delegation. A skill is a directory with a SKILL.md inside it, and the agent chooses which directory to open based on the description text. Nothing in the README suggests a routing table or an index file that a human maintains. The skills/ directory is the single source of truth, and the plugin manifests all point at it, so the plugin route and the manual route install the same content.

That design has a consequence worth stating. Because selection is a judgement the agent makes from a description, the quality of the outcome depends on how well each description matches your phrasing. The README frames the benefit as not pasting anything into a rules file and not remembering to @-mention a doc. The trade-off is the inverse: you lose the ability to guarantee a skill loads. When you want certainty, the project offers an escape hatch. With a .skills/ folder in your project you can point at a file directly, for example Read @.skills/bloc/SKILL.md and create test coverage for the new methods.

The catalogue is organised by area. Foundations cover flutter-best-practices, effective-dart, dart-3-updates, flutter-app-architecture, architecture-feature-first, flutter-errors, flutter-use-column-row-first and flutter-pre-caching. State management has bloc, riverpod, provider and flutter-change-notifier. Testing and review has testing, mockito, mocktail, patrol-e2e-testing and code-review. The Firebase group is the largest, running from flutterfire-configure and firebase-auth through firestore, database, storage, analytics, crashlytics, messaging, in-app messaging, remote config and app check. The README table lists the trigger condition for each skill, which is the closest thing to documentation of when an agent will reach for it.

Installing with the Skills CLI and running a first task

The quick start is a single command, and it requires Node 22.20 or newer. On older versions the README states the CLI exits with SyntaxError: ... does not provide an export named 'styleText' before it does anything, so a failure here is a Node version problem, not a repository problem.

npx skills add evanca/flutter-ai-rules

The Skills CLI discovers the packages under skills/ and installs them for supported agents. If you would rather look before you install, or take a single skill, the README gives both forms.

npx skills add evanca/flutter-ai-rules --list
npx skills add evanca/flutter-ai-rules --skill flutter-best-practices

For Claude Code the project doubles as a plugin marketplace, and the manifests live at .claude-plugin/, .codex-plugin/, .cursor-plugin/, .agents/plugins/ and plugin.json. The Claude Code route is two slash commands.

/plugin marketplace add evanca/flutter-ai-rules
/plugin install flutter-ai-skills@flutter-ai-rules

After that, the README says skills load as flutter-ai-skills:bloc, flutter-ai-skills:riverpod and so on, which is what you should see when the plugin is registered correctly. Codex uses an equivalent pair of commands, codex plugin marketplace add followed by codex plugin install. Cursor takes /add-plugin inside the editor, or the repository URL under Dashboard, Settings, Plugins, Import from Repo. Antigravity clones the repository shallowly and runs agy plugin install ./flutter-ai-rules. For a hand install, copy or symlink a skill folder into your agent's skills directory: .claude/skills/, .cursor/skills/, .codex/skills/, .agents/skills/ or .windsurf/skills/. The README also shows vendoring the whole set into a project under .skills/.

Where it does not work: Copilot, Node versions and agents that ignore SKILL.md

The README is unusually direct about the gaps, and they are the first thing to check against your toolchain. GitHub Copilot does not read SKILL.md at all, according to the README, which points Copilot users at the rules and combined sets instead. That is a different consumption model, and it means the automatic selection described in the introduction is not what you get there.

Windsurf and Devin sit in a middle position. There is no plugin manifest for them, but Cascade already scans .agents/skills/ and ~/.agents/skills/, so the manual copy is the install path rather than a fallback. If you expect a plugin command for Windsurf, the repository does not offer one.

The Node constraint cuts the other way. The npx route needs Node 22.20 or newer, but the README states that every other install route works on any Node version, or none at all. Teams pinned to an older Node for other tooling should go straight to the plugin or manual path rather than treating the CLI as the default.

There is a subtler limitation in the skill model itself. A set derived from official documentation will not settle questions the official documentation leaves open, such as which state management library your team should standardise on. The README frames the collection as almost non-opinionated and free of invented conventions. That is a feature for correctness and a limitation for decisions. If what you want is an agent that enforces your house architecture, these skills will describe the options rather than pick one for you.

Compared with a hand-written rules file or a project AGENTS.md

The obvious alternative is the one most teams already have: a single rules file committed to the repository, or an AGENTS.md at the root. The repository itself contains an AGENTS.md, so the maintainers use that pattern too. The difference is scope of loading. A rules file is read in full, every session, whether or not the task touches the subject. Skills are loaded on demand, one folder at a time, chosen by the agent from the description.

That distinction decides which tool fits. A rules file is the right place for things that are always true of your codebase: the package name, the folder you keep widgets in, the lint rules you enforce. It is a poor place for Firebase Auth specifics, because most sessions never touch auth and the text is dead weight in the context window. Skills invert that. They are good for broad, task-specific knowledge that applies occasionally, and bad for project constants that must never be missed.

The two are not mutually exclusive, and the repository layout suggests the maintainers agree: rules/, combined/, skills/ and AGENTS.md all exist side by side. The combined/ directory exists precisely because some agents want a rules-style artefact rather than a skill folder. If you are choosing, the question is not which format is better in the abstract. It is whether your agent supports the skills convention and whether the knowledge you want to inject is task-shaped or project-shaped.

Maintenance, licensing and what upgrading actually involves

The repository is not archived, and the last push was on 2026-09-14. There are no releases retrieved for it, so version pinning is not available in the usual sense. Updating means re-running the install command or, for plugin users, refreshing through the plugin marketplace, which the README describes as installing the whole set and keeping it updated in place.

That is the practical cost model. Because the content is documentation-derived rather than code, drift comes from upstream: a new Flutter release, a changed Firebase API, a package that renames a concept. The repository ships an ATTRIBUTION.md alongside the LICENSE, which is consistent with sourcing everything from official documentation. The licence is MIT, which permits commercial use and modification, and the attribution file is where the provenance of the underlying documentation is recorded. That is a description of the repository's terms, not legal advice; if you redistribute the skills inside a product, read the LICENSE and ATTRIBUTION.md yourself.

The upgrade risk to watch is behavioural rather than syntactic. A skill that changes its description can start loading in situations where it previously stayed quiet, and you will notice that as a change in agent output rather than as a changelog entry. Vendoring the set into .skills/ gives you a diff to review on each pull; the plugin route gives you the current version with less friction. Teams that need to know exactly what guidance the agent saw should vendor.

Editorial conclusion

Adopt evanca/flutter-ai-rules if your agent supports SKILL.md and you want Firebase, Bloc, Riverpod or testing guidance to appear without pasting rules into a config file. Skip it if you use GitHub Copilot, which the README says does not read SKILL.md, or if you need a Node version below 22.20 for the npx route and cannot use the plugin or manual copy instead. Before committing, run npx skills add evanca/flutter-ai-rules --list to see the skill names, then check one SKILL.md under skills/ to confirm its description matches the tasks you actually delegate.

Frequently asked questions

Official sources

1. evanca/flutter-ai-rules on GitHub
2. Issues
3. License: MIT
4. README