Conciseness

The steps are code-first and mostly tight, but the Overview quotes the same "TAP-compliant testing framework for Bash 3.2 or above" sentence verbatim from two sources, and repeated "Per [bats]: 'setup and teardown: Pre- and post-test hooks.'"-style attribution lines pad sections whose code is self-explanatory. It is not 4 because this explanatory padding is a consistent pattern rather than a minor instance; it is not 2 because the bulk is concrete, non-redundant, executable content.

Actionability

Every step ships copy-paste-ready material: install commands (npm/brew/submodules), complete .bats files, `run`/`$status`/`$lines[]` assertions, bats-assert usage, skip guards, and `bats test/` invocations, with the worked example showing expected TAP output. It is not 4 because the examples cover the common cases including failure paths and environment-dependent skips.

Workflow Clarity

The numbered "How to use" list maps cleanly onto Steps 1-9, and the worked example ends by running the suite and showing the expected "2 tests, 0 failures" output as a checkpoint. It is not 5 because there is no explicit feedback loop for what to do when a test fails (anti-patterns cover causes but not a fix-and-rerest cycle); it is not 3 because the sequence is explicit and the operations are non-destructive, so the missing loop is a minor gap.

Progressive Disclosure

SKILL.md is a well-sectioned spine and the single bundle file, references/ci-integration.md, exists, is one level deep, links back to SKILL.md, and is clearly signaled with its contents ("output formats, GitHub Actions job, Docker image") at each point of use and in the References section. It is not 4 because there is no content misplaced inline, no buried or nested references, and navigation is trivial.

Specificity

"Sets up Bats-core with @test blocks, run, status and output assertions, setup/teardown, shared helpers and TAP output for CI" lists six concrete capabilities spanning authoring, assertions, hooks, reuse, and CI output. It is not 4 because coverage of the core workflow is comprehensive rather than having minor gaps.

Completeness

Both halves are explicit: "Use whenever the code under test is a shell script, a CLI binary or anything run from Bash" answers when with concrete triggers, and the setup sentence answers what. It is not 4 because the when-clause is explicit and specific rather than merely present or vague.

Trigger Term Quality

Natural phrases users would say are present: "shell script", "CLI binary", "Bash", "argument parsing", "flags", "exit codes and output". It is not 5 because common variations like ".sh", "bash script", or "shell" as a bare term are missing, so a few natural triggers are uncovered.

Distinctiveness Conflict Risk

Bats-based shell/CLI testing is a clear niche with distinct triggers. It is not 5 because "anything run from Bash" is broad enough to occasionally overlap with general testing or CLI-behavior skills; it is not 3 because the Bats/shell-CLI framing keeps conflicts minor.