Content
67%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.
The body is a dense, well-organized rule set with genuinely concrete anchors and correctly deferred code examples, but the Anti-Patterns section duplicates the Core Rule Anchors almost verbatim, costing tokens without adding information. Navigation to the reference file works, though its label understates that it holds executable Kotlin examples.
Suggestions
Merge the Anti-Patterns section into the Core Rule Anchors (each rule already states its ban), or reduce each anti-pattern to the one-phrase smell name — five bullets currently repeat five rules nearly verbatim.
Rename the reference link from "[Test Rules](references/implementation.md)" to something like "Executable Kotlin test templates (MainDispatcherRule, Hilt+Compose, saved-state, TalkBack)" so the label signals the actual content.
Add a short ordered checklist (choose layer → pick scope/DI pattern → apply naming + assertion rules → run via the reference templates) to convert the rule set into an explicit workflow with the bug-first checkpoint embedded.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The rules are stated tersely, but the "Anti-Patterns & Banned Smells" section restates five of the six Core Rule Anchors nearly verbatim (e.g. "[MOB-TEST-03] Echo tests: Ban testing auto-generated code, trivial getters, or repeating literal assignments" duplicates rule 03), which is clear tightening opportunities. Not 4: the duplication is more than 'minor instances'; not 2 because there is no concept-explanation padding. | 3 / 5 |
Actionability | Concrete, specific guidance throughout: a real naming example ("submitOrder_whenCreditLimitExceeded_displaysBlockedBanner"), exact APIs ("runTest with MainDispatcherRule", "createAndroidComposeRule + Hilt (HiltAndroidRule)", "@TestInstallIn", Turbine "test {}", "touch bounds ≥ 48dp"), with full code correctly deferred to references/implementation.md. Not 5: the body alone leaves minor gaps (e.g. MainDispatcherRule setup requires opening the reference) and some rules state bans without showing the approved alternative inline. | 4 / 5 |
Workflow Clarity | Layer selection is explicitly ordered ("Unit > Compose UI > UiAutomator"), each layer has defined scope/DI/tooling, and MOB-TEST-05 gives a sequenced checkpoint ("introduce a failing test reproducing the defect before fixing it"). Not 5: there is no explicit end-to-end sequence (pick layer → write → run/verify) tying the rules into a checklist; not 3 because validation checkpoints for the risky path (bug fixes) are present. | 4 / 5 |
Progressive Disclosure | A lean ~40-line rule overview with code examples correctly split into a real, one-level-deep reference ([Test Rules](references/implementation.md) — verified to exist), plus a labeled cross-skill link. Not 5: the link label "Test Rules" mislabels what is actually implementation code examples, and the cryptic external pointer "10 mobile scope areas & C6 contract" signals its destination poorly. | 4 / 5 |
Total | 15 / 20 Passed |