Conciseness

The ~40-line body is pure directive prose with zero concept explanation (it never explains what Flutter, emulators, or simulators are) and no padding; e.g. "Use the smallest target matrix that proves the changed behavior, then state what was and was not exercised." Every sentence instructs, matching anchor 5's 'lean and efficient; every token earns its place'.

Actionability

Concrete, executable anchors are present throughout: `flutter devices`, `flutter emulators`, `adb`, `simctl`, `idb`, `uiautomator`, `package:integration_test`, and the runner's dry-run/`--execute` gate. It is not a 5 because no complete launch or test command is shown inline (details are deferred to reference files) and some steps remain abstract ("Exercise the exact user flow and relevant lifecycle or platform states"), leaving minor gaps for anchor 4.

Workflow Clarity

The 6-step workflow is clearly sequenced with explicit validation checkpoints: "Resolve one target by stable identifier ... and wait until it is ready", "Verify target readiness ... before changing runtime state", "require the included runner's dry run to exit successfully with the expected plan before adding `--execute`", and error-path cleanup "attempted from its `finally` path after pass, failure, timeout, or command error". This matches anchor 5's explicit validation, feedback gating, and error-recovery coverage, including destructive-op safeguards ("Do not erase, reset, recreate, uninstall from, or clear data ... without explicit need and authorization").

Progressive Disclosure

The body is a lean overview and all six references are one level deep with conditional, clearly signaled triggers ("Read [Android emulator operations] ... when starting or controlling an Android virtual or physical target"); every referenced path exists in the bundle, cross-links between references are flat siblings rather than nested chains, and the bundled script `scripts/run_lifecycle_matrix.py` is integrated via the lifecycle reference. This matches anchor 5's 'clear overview with well-signaled one-level-deep references'.

Specificity

"Operate and verify Flutter apps" names the core actions, and the description enumerates five concrete target kinds ("emulator, simulator, browser, desktop, or physical device") plus specific use categories ("target lifecycle, platform-state checks, runtime evidence, and live integration flows"). It falls at anchor 4 rather than 5 because the action verbs themselves ('operate', 'verify') are broad rather than sharp concrete operations like 'extract text' or 'fill forms', and it is above anchor 3 because coverage clearly exceeds 1-2 actions.

Completeness

Both parts are present: a clear 'what' ("Operate and verify Flutter apps on a concrete emulator, simulator, browser, desktop, or physical device") and an explicit 'when' ("Use for target lifecycle, platform-state checks, runtime evidence, and live integration flows") plus a negative boundary ("do not select it for widget or golden-only work"). It stops short of anchor 5 because the when-clause lists capability categories rather than concrete user trigger phrases like 'when the user asks to run or test the app on an emulator or real device'.

Trigger Term Quality

Natural keywords users would say are present: "emulator", "simulator", "physical device", "integration flows", "lifecycle". It is not a 5 because common variations are missing (e.g., 'integration test', 'run the app on a device', 'adb', 'device testing'), and phrases like "platform-state checks" and "runtime evidence" lean technical rather than user-spoken; it is above a 3 because the main platform terms users actually use are all covered.

Distinctiveness Conflict Risk

It has a clear niche (device-level runtime operation/verification) with active disambiguation against sibling skills: "pair with flutter-navigation for route correctness" routes overlap away, and "do not select it for widget or golden-only work" excludes a major adjacent domain. This matches anchor 5's 'clear niche with distinct triggers; minimal conflict risk'.