| name | develop-flutter-scene-extensions |
| description | Build, change, review, and release packages and playground apps in the flutter_scene_extensions workspace. Use for Flutter Scene fork work, flutter_scene_vrm APIs, VRM parsing or humanoid behavior, renderer validation, Island or VRM playground changes, model provenance, MCP automation, upstream preparation, and pub.dev readiness. |
Develop Flutter Scene Extensions
Read the root AGENTS.md, then open only the directly relevant ground-truth
document it names.
Workflow
- Identify whether the change belongs to generic glTF/Scene behavior, the VRM
extension layer, or a non-published playground.
- Keep generic glTF behavior in the pinned Flutter Scene fork. Keep VRM types
in
packages/flutter_scene_vrm. Keep cameras, UI, platform channels, and
game state in playgrounds.
- Add targeted tests with each behavior change. Do not promote parsed-only
features to supported status.
- For UI or scene behavior, run the app through Dart MCP and verify the state
through Marionette custom extensions. Capture a screenshot when appearance
changes.
- Run
mise exec -- dart run tool/check.dart. Use --build when platform or
renderer compatibility can change.
- Update public API docs, the feature matrix, changelog, and upstream plan when
their claims change.
Asset changes
Before adding an asset, record its source URL, exact revision, SHA-256, license,
attribution, redistribution permission, and modification permission. Keep the
license beside the asset and update THIRD_PARTY_NOTICES.md. Do not infer that
a repository code license covers models, textures, audio, logos, or mascots.
Release and upstream boundary
Keep flutter_scene_vrm at 0.x and publish_to: none while it has a Git
dependency. Prepare upstream work as small generic glTF pull requests with
focused tests. Publish only after the package resolves exclusively through SDK
and hosted pub.dev dependencies.
Read references/commands.md when choosing validation
commands or MCP extensions.
