Update to Autonom

{
  "description": "Route Flutter, native Android, native iOS, and device test/debug tasks to the smallest relevant Autonom skill set after inspecting the repository stack and runtime boundary.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 212
    }
  ],
  "name": "project-router",
  "skill_md_contents": "---\nname: project-router\ndescription: Route Flutter, native Android, native iOS, and device test/debug tasks to the smallest relevant Autonom skill set after inspecting the repository stack and runtime boundary.\n---\n\n# Project Router\n\n## Purpose\n\nFor the whole-system map — what Autonom can do, how it works, the end-to-end\ndevice loop — read the `autonom` skill first. This router is the dispatcher that\nnarrows that map to the smallest stack-specific skill set for the task at hand.\n\nClassify the repository and task before changing code or driving a device.\nA Flutter app contains `pubspec.yaml` with a Flutter SDK dependency. A native\nAndroid project normally starts from Gradle settings and Android modules. A native\niOS project starts from `*.xcodeproj`, `*.xcworkspace`, or `Package.swift`.\nHybrid repositories can contain several, so route by the layer being changed.\n\nFor **runtime QA / UI debug** on a device, emulator, or simulator, load\n`mobile-session` and `mobile-screen` (Autonom CLI) in addition to the\nstack-specific debugger. Load `mobile-network` when the task mentions an API,\nrequest, response, mock, HAR, proxy, or \"why is this call failing\". Load\n`mobile-flow` when the task mentions a repeatable flow, regression check,\nsmoke suite, replaying a journey, or a `.yaml` flow file.\n\nOnce the target app is known (a package/bundle id is in play), load\n`mobile-memory` and read `~/.autonom/apps/<package>/app.md` and any matching\n`flows/` runbook **before** driving the device — it carries the backend, network\nmodel, schema locations, and step-by-step flows worked out on earlier runs, so\nthe same digging is not repeated. Record a new flow there only when it is\ndurable, reusable, and evidence-backed.\n\nUse the repository-selected Flutter SDK for executable commands. When selection\nis ambiguous or FVM is pinned, resolve it without silently falling back:\n\n```bash\npython3 <marketplace-root>/scripts/flutter_exec.py --root . -- --version\n```\n\n\n## Routing workflow\n\n1. Inspect repository documentation and the project root.\n2. Run the shared toolchain snapshot when build layout or SDK state is unclear:\n\n   ```bash\n   python3 <plugin-root>/../../scripts/toolchain_snapshot.py . --execute\n   ```\n\n3. Detect the primary path:\n\n   - Flutter feature, Dart code, widgets, navigation, tests, or package work:\n     load the relevant `flutter-*` skills.\n   - Android manifest, Gradle, Kotlin, platform channels, app links,\n     notifications, permissions, or plugin native code inside a Flutter app:\n     load `flutter-android-platform` plus the narrow Android skill.\n   - Pure Kotlin or Compose project: load the native Android/Compose skills.\n   - `*.xcodeproj`, `*.xcworkspace`, `Package.swift`, or work inside a Flutter\n     app's `ios/` directory (plist, capabilities, Swift/Obj-C module, signing\n     configuration): load `ios-project-setup`, and `ios-debugger-agent` when the\n     app must actually run.\n4. Load runtime skills only when device evidence is required:\n   - session + screen: `mobile-session`, `mobile-screen` via `scripts/autonom.py`\n   - per-app knowledge and flows: `mobile-memory` (read `~/.autonom/apps/<package>/`)\n   - deeper debug: `android-debugger-agent` / `ios-debugger-agent` / `flutter-debugger-agent`\n   - network inspect or mock: `mobile-network`\n   - visual mirror: `android-emulator-browser`\n5. When the machine's capabilities are unclear, run\n   `python3 <autonom-root>/scripts/autonom.py doctor` — it reports which platforms\n   are usable and what is missing, instead of discovering it mid-task.\n6. Do not load every skill pre-emptively; progressive loading keeps the task\n   focused.\n\n## Default verification ladder\n\nFor Flutter:\n\n```bash\nflutter pub get\ndart format --output=none --set-exit-if-changed <changed-paths>\nflutter analyze <changed-paths-or-project>\nflutter test <narrow-test-path>\n```\n\nFor native Android:\n\n```bash\n./gradlew <narrow-task> --console=plain\n```\n\nBroaden checks when shared architecture, generated code, Gradle configuration,\nplatform integration, or release behavior changed.\n\n## Boundaries\n\n- Flutter UI behavior should be proven through widget or integration tests and\n  a running Flutter app, not inferred from Android views alone.\n- Native permission dialogs, platform views, notifications, and system surfaces\n  can require UI Automator, Espresso, Patrol, or manual device evidence.\n- Performance and memory claims need comparable runtime captures.\n"
}