// Use when the user wants Docker-based FRB development or Tart-based iOS Simulator validation.
| name | frb-dev-env |
| description | Use when the user wants Docker-based FRB development or Tart-based iOS Simulator validation. |
Use this skill before setting up, diagnosing, or running flutter_rust_bridge commands with a container-based development workflow.
Use Docker for normal FRB development checks that fit Linux containers: Rust tests, Dart tests, web tests, code generation, lint, and most ./frb_internal commands. Docker is the default reproducible baseline when local host toolchains are missing or suspected to have drifted.
Use Tart only for checks that need macOS and Xcode, especially iOS Simulator validation. The Tart workflow is intentionally separate from Docker; it gives each worktree a reusable macOS VM cloned from a prepared base VM, then runs FRB commands inside that VM.
Do not use the Tart macOS VM as the Android emulator strategy. macOS Tart guests do not support nested virtualization, so Android emulator runtime coverage needs a host or runner with virtualization support. Android SDK compilation checks can still use Docker when they do not need a running emulator.
./frb_internal over ad hoc direct invocations.frb_generated.*, *.freezed.dart, *.g.dart) as the final fix.Before running tests, lint, code generation, or setup:
git rev-parse --show-toplevel
git status --short
git submodule status --recursive
If submodules are uninitialized, initialize them locally:
git submodule update --init --recursive
Use Docker for container-based FRB development. Each worktree should have one long-lived local container that is reused for tests, lint, code generation, and setup commands.
Use frb_dev_env.py next to this skill to inspect, create, start, and reuse the per-worktree container. The script derives the container name from the canonical worktree root only:
frb-<worktree-root-sha256-prefix-12>
It mounts the canonical worktree root and git common root at their host-like absolute paths, and labels the container with:
frb.dev.repo=flutter_rust_bridge
frb.dev.worktree=<canonical worktree root>
frb.dev.git-common-root=<git common root>
frb.dev.layout-version=3
Commands run from the host-like worktree path inside the container. There is intentionally no /workspace alias, because linked git worktrees and submodule gitdir references need the same path shape that they have on the host.
Typical usage:
.claude/skills/frb-dev-env/frb_dev_env.py docker info
.claude/skills/frb-dev-env/frb_dev_env.py docker create
.claude/skills/frb-dev-env/frb_dev_env.py docker exec -- bash -lc './frb_internal --help'
Delete a worktree's Docker container when the worktree is no longer needed, or when local Docker resources are getting crowded:
.claude/skills/frb-dev-env/frb_dev_env.py docker delete
The delete command validates the container labels before removing it. Use --force only when intentionally removing a mismatched container.
Use the project frb-docker skill for image, devcontainer, and Dockerfile details.
Use Tart for iOS Simulator validation when Docker cannot provide the required macOS/Xcode runtime. The script uses one reusable Tart VM per worktree, named from the canonical worktree root:
frb-tart-<worktree-root-sha256-prefix-12>
By default, create clones from a prepared local base VM named frb-tart-base. Override it with FRB_TART_BASE_VM or --base-vm.
Read frb-tart-prepare before creating or changing the base VM. The base VM should be cloned directly from a pinned OCI artifact and treated as immutable; do not boot it and manually install tools into it.
For linked git worktrees, the Tart helper shares both the canonical worktree root and the git common root into the VM, then mounts them at host-like absolute paths with mount_virtiofs. This keeps worktree .git files and submodule gitdir references valid inside the VM.
Typical usage:
.claude/skills/frb-dev-env/frb_dev_env.py tart info
.claude/skills/frb-dev-env/frb_dev_env.py tart create
.claude/skills/frb-dev-env/frb_dev_env.py tart start
.claude/skills/frb-dev-env/frb_dev_env.py tart ip --wait 180
.claude/skills/frb-dev-env/frb_dev_env.py tart exec -- sw_vers
Run iOS Simulator tests by starting the worktree VM, booting an iOS simulator inside it, then running the existing FRB test command inside the VM:
.claude/skills/frb-dev-env/frb_dev_env.py tart exec -- xcrun simctl boot <UDID>
.claude/skills/frb-dev-env/frb_dev_env.py tart exec -- xcrun simctl bootstatus <UDID> -b
.claude/skills/frb-dev-env/frb_dev_env.py tart exec -- ./frb_internal test-flutter-native --flutter-test-args '--device-id <UDID>' --package <package>
Delete the worktree VM when it is no longer needed:
.claude/skills/frb-dev-env/frb_dev_env.py tart stop
.claude/skills/frb-dev-env/frb_dev_env.py tart delete
After applying this environment policy, also read the relevant project-level frb-* skills for the actual task, such as code generation, tests, lint, Docker details, CI triage, or PR preparation.
Use when preparing or explaining the FRB Tart base VM for iOS Simulator validation, including local OCI registry mirroring, direct OCI clone, and base VM hygiene.
Explain how cargokit is sourced, copied, and analyzed inside flutter_rust_bridge. Use when working on `integration_template/**/cargokit`, `frb_example/**/cargokit`, integrate/generate output drift, or any diff that mentions cargokit and you need to identify the true source of truth before judging the change.
Use when about to create a PR or push changes in flutter_rust_bridge to ensure code generation is up to date
Use when implementing a GitHub issue, bug fix, or feature in flutter_rust_bridge end-to-end: develop the change, add regression coverage, prepare and open a PR, monitor CI until green, request and resolve Gemini review, and keep following up on a 5 minute cadence until the PR is ready.
Review a flutter_rust_bridge PR before treating it as ready, including subagent checks for correctness and test weakening plus Gemini review.
Use when needing to run tests locally in flutter_rust_bridge, or when debugging test failures before pushing