Conciseness

Every line carries non-obvious information ("only the CLI does parallelism and profile aggregation", "--dry-run can't combine with -p", the parsed-flags-availability gotcha); there is no explanation of what Ginkgo or testing frameworks are, and tables compress the subcommand surface. Nothing reads as padding.

Actionability

Guidance is copy-paste ready: a runnable bash grammar block ("ginkgo <GINKGO-FLAGS> <PACKAGES> -- <PASS-THROUGHS>"), a complete executable PreviewSpecs Go function, an init() flag registration plus the corresponding invocation ("ginkgo -p -- --server-addr=..."), and the GinkgoConfiguration() override pattern. Common cases are covered with exact commands.

Workflow Clarity

Each task (run, randomize, multi-suite, preview, parameterize) has a clear, concrete command sequence with pitfalls called out (seed to reproduce a failing order, --keep-going vs --fail-fast scope). No destructive or batch operations require validation loops, so the anchor-5 requirement of explicit validate/fix/retry checkpoints does not apply; the gap to 5 is the absence of any explicit verification step for the parameterization workflows.

Progressive Disclosure

The body is well-sectioned (CLI surface, Randomization, Multiple suites, Previewing, Custom configuration, Where to go next) and cross-links to sibling skills are clearly signaled one level deep. No bundle files exist, and at ~105 lines some inline material (the full subcommand table or the PreviewSpecs example) could arguably live in a reference file, which keeps this just below anchor 5.

Specificity

The description enumerates the full command surface with concrete flags: "run, -r, -p, --dry-run, watch, build (precompiled .test binaries), generate, outline, unfocus, labels, version", plus "--randomize-all/--randomize-suites/--seed", "--keep-going/--skip-package/--compilers", and parameterization "via env vars or init()-registered flags after --". Coverage is comprehensive with no generic filler.

Completeness

"What" is answered exhaustively (subcommands, randomization, multi-suite, previewing, parameterization) and "when" is explicit: "Use when running suites locally, precompiling, watching for changes, or parameterizing a run from the command line", with a boundary pointer ("For a CI configuration see ginkgo:ci"). Both halves are concrete and explicit.

Trigger Term Quality

Strong natural phrasing users would actually say ("running suites locally", "precompiling", "watching for changes", "parameterizing a run") alongside the literal CLI keywords, but a few common variations (e.g. "run my specs", "go test", "parallel") are absent or only implied by flag names. Not clearly below anchor 5 (missing only some synonyms), so 4 fits.

Distinctiveness Conflict Risk

It is anchored to a named tool (Ginkgo, the ginkgo CLI) with distinct triggers, and explicitly routes adjacent intents elsewhere ("For a CI configuration see ginkgo:ci"), so it is unlikely to trigger for the wrong skill.