CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/xcuitest-suite

Authors XCUIest UI tests for iOS / iPadOS / tvOS and macOS desktop apps - uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via `xcodebuild test` with destination, parses the `xcresult` bundle. The macOS desktop delta (platform=macOS destination flags, TCC privacy-permission resets, per-device performance baselines) is in references/macos.md. Use when an iOS or macOS app needs UI tests in Apple's first-party framework (no external runtime; native to Xcode).

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, highly actionable skill body: sequenced steps, executable code and commands throughout, an anti-patterns table, and a correctly placed one-level-deep reference for the macOS delta. Remaining improvements are minor — trimming quoted Apple-doc rationale that duplicates the code examples and making the post-run results check an explicit step.

Suggestions

Drop or compress the block quotes restating the three-class pattern and `continueAfterFailure` rationale — the surrounding code already demonstrates both — and describe the macOS delta once instead of in both the "macOS desktop apps" section and References.

Make Step 7 an explicit validation checkpoint: after `xcresulttool` extraction, check the summary for failures/summary.json status and act on it (e.g. re-run with `-only-testing` to isolate a flake) rather than just forwarding to junit-xml-analysis.

DimensionReasoningScore

Conciseness

The body is code-first and lean — executable Swift per step, a destination-flag table, and an anti-patterns table instead of prose. Minor instances of over-explanation remain: Apple-doc quotes restate the three-class pattern and `continueAfterFailure` rationale, and the macOS delta is described twice (in the "macOS desktop apps" section and again in References). Fits "efficient; minor instances of over-explanation that could be trimmed" (4) rather than "every token earns its place" (5).

4 / 5

Actionability

Fully executable and copy-paste ready across common cases: the complete `xcodebuild test` invocation with `-destination`/`-resultBundlePath`, `xcrun xcresulttool get test-results summary --path TestResults.xcresult --format json`, concrete Swift for query/event/assert patterns including `waitForExistence(timeout:)`, and a runnable GitHub Actions workflow. Matches the 5 anchor.

5 / 5

Workflow Clarity

Steps 1–8 form a clear, correctly ordered sequence (add target → set identifiers → query → synthesize events → assert → run → parse → CI), reinforced by an anti-patterns table that acts as checkpoints ("Running against wrong destination … Pin OS version explicitly in CI"). Not a 5 because validation is implicit — there is no explicit check-the-results-then-retry/fix loop after the run/parse steps. Not a 3: the sequence is complete and checkpoints are mostly present.

4 / 5

Progressive Disclosure

SKILL.md is an overview-plus-core-steps; the macOS-only delta is appropriately split into references/macos.md (verified to exist), clearly signaled twice in the body ("is in [references/macos.md]") and in the References section. The bundle is one level deep — macos.md points to Apple docs and sibling skills, not to further nested bundle files — so navigation is easy. Matches the 5 anchor.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete, comprehensive, third-person, with an explicit 'Use when' clause and a clear first-party-vs-external-runtime niche. The only real defect is a typo ("XCUIest") that removes the framework's own correctly-spelled name — the most natural user trigger term — from the description.

Suggestions

Fix the "XCUIest" typo to "XCUITest" so the framework's own name — the most likely user keyword — appears correctly in the description.

Add the ".xcresult" file extension and terms like "XCUITest target" or "UI test bundle" to broaden natural trigger coverage (e.g. "parses the `.xcresult` bundle").

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions with comprehensive coverage of the workflow: "uses the three-class XCUIApplication / XCUIElement / XCUIElementQuery pattern, sets accessibility identifiers on production code, runs via `xcodebuild test` with destination, parses the `xcresult` bundle" — authoring, instrumenting, running, and parsing are all named. Coverage has no gaps, so it fits the 5 anchor rather than 4.

5 / 5

Completeness

Explicitly answers both: what = "Authors XCUIest UI tests … runs via `xcodebuild test` … parses the `xcresult` bundle", and when = "Use when an iOS or macOS app needs UI tests in Apple's first-party framework (no external runtime; native to Xcode)" with concrete trigger phrasing in third-person voice. Clearly matches the 5 anchor.

5 / 5

Trigger Term Quality

Good natural-term coverage ("UI tests", "iOS / iPadOS / tvOS and macOS desktop apps", "accessibility identifiers", "xcodebuild test", "xcresult", "Apple's first-party framework"), but the single most natural keyword — "XCUITest" — is misspelled as "XCUIest", so the framework's own name never appears as a correct trigger term. Solid but with a notable miss, fitting anchor 4 rather than 5.

4 / 5

Distinctiveness Conflict Risk

"Apple's first-party framework (no external runtime; native to Xcode)" carves out a clear niche explicitly contrasted with Appium/Detox, and the XCUI class names plus `xcresult` are unique to this domain, so conflict risk with other testing skills is minimal — anchor 5, not 4.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents