Conciseness

The body is lean: terse bullet guidance, copy-paste command blocks per option, and no explanation of concepts Claude already knows (it never explains what unit tests or Mocha are). Not anchor 5 because of minor redundancy — the multiple-files case is demonstrated twice (bare paths and repeated --run) and both the bare-path and --run sections cover overlapping ground that could be trimmed.

Actionability

Every shell option has a fully executable, copy-paste-ready example for both platforms (e.g., `./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --grep "should split lines"`). Not anchor 5 because the runTests tool section provides only an "Example (conceptual)" in prose with no actual tool invocation, a pseudocode stand-in without explicit justification.

Workflow Clarity

A clear decision sequence is present: prefer runTests, fall back to platform scripts when unavailable, use test-integration scripts for integration tests, and ensure compilation before running ("Ensure the `VS Code - Build` watch task is running... Test failures caused by stale output are a common pitfall"). Not anchor 5 because the compilation prerequisite is stated as a caution rather than an explicit verification step or command, and there is no error-recovery loop for stale-output failures.

Progressive Disclosure

The body is well organized with clear headers (Preferred tool / Fallback scripts / per-option sections / Integration tests / Compilation requirement) and the one external reference ("See the `integration-tests` skill") is clearly signaled and one level deep. Not anchor 5 because the option reference is entirely inline with no split of detailed material, and the referenced integration-tests material lives outside this skill without further navigation structure.

Specificity

Phrases like "Covers the runTests tool, scripts/test.sh (macOS/Linux) and scripts/test.bat (Windows)" and "supported arguments for filtering, globbing, and debugging tests" name several concrete tools and capabilities rather than vague actions. It falls short of anchor 5 because the actions are implied through 'Covers...' rather than enumerated (e.g., running, filtering, and collecting coverage are only partially represented), leaving minor coverage gaps.

Completeness

"Use when running unit tests in the VS Code repo" is an explicit, concrete 'when' clause, and the 'what' is explicitly stated (runTests tool, both platform scripts, and their supported arguments). Both what and when are clearly and explicitly answered with trigger phrases, matching anchor 5; anchor 4 would require the 'when' to be less explicit than it is.

Trigger Term Quality

Natural phrases users would say are present: "running unit tests", "VS Code repo", "filtering", "globbing", "debugging tests", plus concrete script names (test.sh, test.bat). Not anchor 5 because common variations like "run the tests", "test this file", or "Mocha" are missing.

Distinctiveness Conflict Risk

The description is tightly scoped to "the VS Code repo" and names repo-specific tooling (runTests tool, scripts/test.sh, scripts/test.bat), giving it a clear niche with distinct triggers and minimal overlap risk with generic test-running skills. It even implicitly separates from integration testing (the body defers that to a separate skill).