
Flutter Plugins
Scaffold a Flutter plugin with the right template—FFI, federated, or standard—and wire platform channels for other apps to consume native code.
Overview
flutter-plugins is an agent skill for the Build phase that scaffolds and configures Flutter plugin packages across FFI, method-channel, and federated architectures.
Install
npx skills add https://github.com/flutter/skills --skill flutter-pluginsWhat is this skill?
- Decision tree: plugin_ffi vs standard plugin vs federated multi-package layout
- Clarifies FFI template does not include method channels; hybrid needs manual FFI inside standard plugin
- Covers Android v2 embedding lifecycle interfaces and platform-specific native environments
- Federated pattern: app-facing, platform interface, and per-platform implementation packages
- Gemini 3.1 Pro–oriented generator metadata for scaffolding workflows
- 3-step decision tree for plugin architecture
- 2 plugin templates contrasted (plugin_ffi vs standard plugin)
Adoption & trust: 970 installs on skills.sh; 2.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want to ship a Flutter plugin but are unsure whether to use plugin_ffi, a monolithic plugin, or a federated multi-package layout.
Who is it for?
Indie mobile devs publishing a reusable native bridge for camera, sensors, or third-party SDKs across iOS and Android.
Skip if: Teams building a single Flutter app with no reusable package—use in-app platform channels or existing plugins instead.
When should I use this skill?
When scaffolding or configuring a Flutter plugin package that other apps will depend on, including FFI-only, hybrid, or federated layouts.
What do I get? / Deliverables
You get an architecture choice and scaffold aligned to FFI-only, channel-plus-FFI, or federated platform interfaces with embedding-ready native stubs.
- Plugin package skeleton
- Platform interface package layout when federated
- Configured native stub projects per platform
Recommended Skills
Journey fit
Canonical shelf is Build → integrations because the skill’s goal is creating plugin packages that bridge Dart and native platforms. Integrations fits method channels, FFI, Android v2 embedding, and federated platform-interface packages—not app UI screens alone.
How it compares
Skill package for generating plugin structure, not an MCP server or generic React Native module guide.
Common Questions / FAQ
Who is flutter-plugins for?
Flutter developers who need to create and configure plugin packages for pub.dev consumption, including FFI and federated setups.
When should I use flutter-plugins?
Use it in Build → integrations when starting a new native bridge package, choosing between plugin_ffi and standard templates, or splitting a federated plugin for multiple maintainers.
Is flutter-plugins safe to install?
It is scaffolding documentation; review the Security Audits panel on this Prism page and inspect generated native code and CI before publishing.
SKILL.md
READMESKILL.md - Flutter Plugins
# flutter-plugin-generator ## Goal Scaffolds and configures Flutter plugin packages, handling standard method channels, FFI integrations, and federated plugin architectures. It configures platform-specific native code environments, implements Android v2 embedding lifecycle interfaces, and establishes platform interface packages. ## Decision Logic Use the following decision tree to determine the plugin architecture and template: 1. **Does the plugin require C/C++ native code via `dart:ffi`?** * **Yes:** Use `--template=plugin_ffi`. * *Note:* FFI plugins support bundling native code and method channel registration, but *not* method channels themselves. * **No:** Proceed to step 2. 2. **Does the plugin require BOTH `dart:ffi` and Method Channels?** * **Yes:** Use `--template=plugin` (Non-FFI). You must configure FFI manually within the standard plugin structure. * **No:** Proceed to step 3. 3. **Will the plugin be developed by multiple teams or require highly decoupled platform implementations?** * **Yes:** Implement a **Package-Separated Federated Plugin** (App-facing package, Platform Interface package, Platform Implementation packages). * **No:** Implement a standard monolithic plugin. ## Instructions 1. **Gather Plugin Requirements** **STOP AND ASK THE USER:** * What is the plugin name? * What is the organization name (reverse domain notation, e.g., `com.example`)? * Which platforms should be supported (comma-separated: `android,ios,web,linux,macos,windows`)? * Do you need an FFI plugin or a standard Method Channel plugin? * Do you prefer Java or Kotlin for Android? Objective-C or Swift for iOS? * Should this be a federated plugin? 2. **Generate the Plugin Package** Execute the Flutter CLI command based on the user's parameters. *Standard Plugin Example:* ```bash flutter create --org com.example --template=plugin --platforms=android,ios,macos -a kotlin -i swift my_plugin ``` *FFI Plugin Example:* ```bash flutter create --template=plugin_ffi my_ffi_plugin ``` 3. **Configure Federated Plugin Architecture (If Applicable)** If the user requested a federated plugin, configure the `pubspec.yaml` of the app-facing package to endorse the platform implementations. ```yaml # App-facing pubspec.yaml flutter: plugin: platforms: android: default_package: my_plugin_android windows: default_package: my_plugin_windows dependencies: my_plugin_android: ^1.0.0 my_plugin_windows: ^1.0.0 ``` For the platform implementation packages, define the `implements` key: ```yaml # Platform implementation pubspec.yaml (e.g., my_plugin_windows) flutter: plugin: implements: my_plugin platforms: windows: pluginClass: MyPlugin ``` 4. **Prepare Native Environments for Editing** Before modifying native code, you MUST build the example app to resolve dependencies and generate necessary files. ```bash cd my_plugin/example flutter build apk --config-only # For Android flutter build ios --no-codesign --config-only # For iOS flutter build windows # For Windows ``` 5. **Implement Android v2 Embedding Lifecycle** Modify the Android plugin class (e.g., `android/src/main/kotlin/com/example/my_plugin/MyPlugin.kt`). Extract logic from `registerWith()` into a private method shared with `onAttachedToEngine()`. Implement `ActivityAware` or `ServiceAware` if context is needed. ```kotlin package com.example.my_plugin import androidx.annotation.NonNull import io.flutter.embedding.engine.plugins.FlutterPlugin import io.flutter.embedding.engine.plugins.activity.ActivityAware import io.flutt