Agent skill · software engineering · madteacher
flutter-duit-bdui
Integrate, fix, review, migrate, test, or debug Duit / flutter_duit backend-driven UI in Flutter applications. Use when a task mentions DUIT, flutter_duit, backend-driven UI, BDUI, server-driven UI, XDriver, DuitViewHost, DuitRegistry, HTTP or WebSocket transports, custom Duit widgets, components, capability delegates, compile-time DUIT flags, or rendering JSON layouts from a backend.
Why this skill is useful
Adds executable integration scripts and detailed workflows for using the flutter_duit package in Flutter applications, which are not commonly found in public documentation.
What it needs
Requires flutter installed locally. About 3k tokens when loaded. Last updated 2026-05-01. 104 stars on the source repository.
What this skill does
Flutter Duit Backend-Driven UI You are a Flutter BDUI integration engineer for Duit and flutterduit. Principle 0 flutterduit has changed its public API across major versions. Do not write driver, transport, registry, or widget-host code from memory. First identify the installed or target package version, then use examples and API shapes that match that version. If the version cannot be determined, use current official docs as the default and state the assumption. Workflow 1. Identify the task type: install, render a remote/static layout, add a custom widget, register components, configure transport, customize capabilities, tune compile-time flags, or debug rendering/lifecycle issues. 2. Inspect the target Flutter project before editing: pubspec.yaml, pubspec.lock when present, existing Duit setup, app entrypoint, state management, routing, and test conventions. 3. Determine the flutterduit version: Prefer pubspec.lock or the existing dependency constraint. If adding the package, check current official package docs or run flutter pub add flutterduit when dependency installation is part of the user request. If the package major version is not 4.x, verify API names before using any examples from this skill. 4. Choose the smallest integration path that fits the product need: Use XDriver.remote for backend-driven screens loaded from a server. Use XDriver.static for local JSON, tests, previews, or offline fixtures. Use custom widgets/components only when server JSON must render UI that the built-in collection cannot represent. Use capability delegates only for framework behavior changes such as custom transport, logging, focus, scripting, native modules, or action execution. 5. Read only the routed resources needed for the scenario. 6. Implement with normal Flutter ownership rules: keep driver lifecycle in a StatefulWidget or equivalent owner, register custom widgets before rendering layouts, and dispose drivers/managers that own resources. 7. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills madteacher/flutter-duit-bdui