Content
92%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-structured operational skill: executable commands throughout, an explicitly validated workflow with bounded error-recovery loops, and a clean split between the SKILL.md overview and genuinely needed reference files. The only weakness is repetition — the key warnings (static builds, webPreviewUrl handling) are restated enough that the body could be noticeably shorter without losing signal.
Suggestions
State the static-build/live-reload trap once in the mode-selection box and reference it from the table and Operating principle #5 instead of restating it four times.
Consolidate the duplicated webPreviewUrl guidance: keep the full browser-handoff rules in the core-loop section and drop the repetition in the agent-device 'open' row to a one-line cross-reference.
Trim the 'Always name the session' section to the rule list and 2–3 examples, and move the "≥ 20.3.0 as of writing" version pin out of the body since --help is already declared authoritative and npx --yes eas-cli@latest makes it moot.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Efficient and high-signal — no explanation of concepts Claude already knows, and every command is a full executable invocation — but the static-build/live-reload trap is stated four times (mode box, mode table, quick decision, Operating principle #5), the webPreviewUrl warning appears twice, and the ~30-line session-naming section could be tightened. Not 5: these repeats and the embedded version pin ("≥ 20.3.0 as of writing") are tokens that could be trimmed; not 3: nothing is padding. | 4 / 5 |
Actionability | The core loop is a copy-paste-ready bash block with comments, and commands are exact throughout: the availability gate, the exec wrapper pattern, concrete verb examples ("press 'label=\"Open\"' --timeout 120000"), and mode flags ("EXPO_UNSTABLE_TUNNEL_V2=1 expo start --tunnel"). Specific examples cover the common cases. | 5 / 5 |
Workflow Clarity | The sequence (check availability → start named → confirm IN_PROGRESS via simulator:get --json → pick mode → drive → stop + reset dotenv) is explicit, with auth verification, a ground-truth checklist, and a bounded feedback loop: "reset to baseline... redo the mode once; a second failure → stop and report" plus reset-don't-retry rules for daemon drops. | 5 / 5 |
Progressive Disclosure | The body stays at decision/overview level while full mode sequences, controller details, crash-log procedures, and error→fix tables live in four real, one-level-deep reference files, each with an explicit read-when signal ("read before running a mode", "read when the app crashes or misbehaves") and a summary References section. | 5 / 5 |
Total | 19 / 20 Passed |