Patrol
Patrol drives a Flutter app and its native platform from Dart tests. This skill contains the leancodepl/patrol setup, test-authoring, test-key and diagnostic guidance, including existing corrections against Patrol's official documentation. LeanCode's module and key conventions remain source suite style, distinguished from API restrictions. Maestro and tester-army/e2e are separate tools and are not prerequisites. [leancodepl/patrol, patrol-write-test, test keys and setup; https://patrol.leancode.co/documentation]
Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]
| The job |
Read |
| Set up Patrol, run tests/MCP, write inline then extract modules, add shared Keys, handle native dialogs and diagnose failures |
PATROL.md |
The rules
- Match Patrol and CLI versions against the official compatibility table. Native automation runs under
patrol test or patrol develop, not flutter test. Importing flutter_test assertions and finders is allowed. [leancodepl/patrol, setup; https://patrol.leancode.co/documentation/compatibility-table]
- Prove the harness first. The source's first-time setup covers Android: use a minimal self-contained test and a fully booted emulator before app/backend scenarios. Other platforms need their official native setup. [leancodepl/patrol, setup]
- Preserve the selected suite style. LeanCode's convention writes inline first, proves it, moves Patrol calls into modules, and proves it again. Its Keys-only finder convention is not an API restriction. [leancodepl/patrol, patrol-write-test]
- Keep Keys shared with the app. Key only widgets involved in testing, use the feature key files, and avoid unrelated app changes. Accessibility-tree identifiers belong to outside-the-app runners and do not replace Patrol's Keys convention. [leancodepl/patrol, test keys; mobile-dev-inc/maestro-docs, Flutter comparison]
- Keep the assertion-style conflict explicit. LeanCode prefers assertions at the end; the owner's journey contract keeps separate intermediate observable assertions where outcomes matter. Follow the owner's authorized journey contract. [leancodepl/patrol, patrol-write-test; owner AGENTS.md]
- Handle native dialogs when triggered and diagnose from the actual error. Check the installed API before writing it; keep destructive cache cleanup cause-specific and authorized. [leancodepl/patrol, native dialogs and diagnostics; owner AGENTS.md]
Prove it
Use the Patrol-only acceptance in PATROL.md, for the platform and suite convention selected. Report exact runs and remaining limitations. Maestro hierarchy checks, tester-army/e2e scripts and Flutter Web setup are not Patrol acceptance steps. [leancodepl/patrol, test setup and patrol-write-test; owner AGENTS.md]
1---2name: patrol3description: "Sets up, writes and debugs Flutter end-to-end tests with Patrol: Dart tests, native automation, test keys, feature modules and platform failures. Use when a Flutter project uses Patrol, patrol_cli or Patrol MCP, or the user asks for Patrol tests."4metadata:5 source: https://skillmd.com/skills/quegenx/patrol6---78# Patrol910Patrol drives a Flutter app and its native platform from Dart tests. This skill contains the leancodepl/patrol setup, test-authoring, test-key and diagnostic guidance, including existing corrections against Patrol's official documentation. LeanCode's module and key conventions remain source suite style, distinguished from API restrictions. Maestro and tester-army/e2e are separate tools and are not prerequisites. [leancodepl/patrol, patrol-write-test, test keys and setup; https://patrol.leancode.co/documentation]1112Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]1314| The job | Read |15|---|---|16| Set up Patrol, run tests/MCP, write inline then extract modules, add shared Keys, handle native dialogs and diagnose failures | [PATROL.md](PATROL.md) |1718## The rules19201. **Match Patrol and CLI versions against the official compatibility table.** Native automation runs under `patrol test` or `patrol develop`, not `flutter test`. Importing `flutter_test` assertions and finders is allowed. [leancodepl/patrol, setup; https://patrol.leancode.co/documentation/compatibility-table]212. **Prove the harness first.** The source's first-time setup covers Android: use a minimal self-contained test and a fully booted emulator before app/backend scenarios. Other platforms need their official native setup. [leancodepl/patrol, setup]223. **Preserve the selected suite style.** LeanCode's convention writes inline first, proves it, moves Patrol calls into modules, and proves it again. Its Keys-only finder convention is not an API restriction. [leancodepl/patrol, patrol-write-test]234. **Keep Keys shared with the app.** Key only widgets involved in testing, use the feature key files, and avoid unrelated app changes. Accessibility-tree identifiers belong to outside-the-app runners and do not replace Patrol's Keys convention. [leancodepl/patrol, test keys; mobile-dev-inc/maestro-docs, Flutter comparison]245. **Keep the assertion-style conflict explicit.** LeanCode prefers assertions at the end; the owner's journey contract keeps separate intermediate observable assertions where outcomes matter. Follow the owner's authorized journey contract. [leancodepl/patrol, patrol-write-test; owner AGENTS.md]256. **Handle native dialogs when triggered and diagnose from the actual error.** Check the installed API before writing it; keep destructive cache cleanup cause-specific and authorized. [leancodepl/patrol, native dialogs and diagnostics; owner AGENTS.md]2627## Prove it2829Use the Patrol-only acceptance in [PATROL.md](PATROL.md#prove-it), for the platform and suite convention selected. Report exact runs and remaining limitations. Maestro hierarchy checks, tester-army/e2e scripts and Flutter Web setup are not Patrol acceptance steps. [leancodepl/patrol, test setup and patrol-write-test; owner AGENTS.md]
