Conciseness

Lean and directive throughout: every line is either an instruction, a project-specific constraint, or a non-obvious operational detail ("Prefer `localhost` to `127.0.0.1`, because dev servers often listen on IPv6 only"; "Never use `pkill -f` with a pattern that also appears in your own command line"). No concept explanations Claude already knows and no padding to trim.

Actionability

Fully executable guidance: a copy-paste-ready command ("pnpm exec playwright test <file> --timeout=15000 --max-failures=1"), a concrete pid pattern ("cmd & pid=$!"), complete file templates for test-plan.md and ledger.md with example rows, a screenshot naming convention ("screenshots/ac2-filter-after-reload.png"), and example ledger lines. The only unavoidably abstract parts (the tests themselves) are task-specific and delegated to references/playwright.md, which supplies the concrete patterns.

Workflow Clarity

Clear sequence with explicit validation checkpoints and a feedback loop: read inputs → sort criteria into observable/internal → write one test, "Run only that test", and on failure "read the failure, and only then the product code it points at… Fix the test with a small edit and run it again". The failure-is-a-finding rule ("Do not weaken the assertion and do not change product code") and the closing checklist ("Every criterion must have a row in the test plan or a ledger line with a reason") complete the loop.

Progressive Disclosure

A 73-line overview with well-signaled, one-level-deep references, both verified real: "For Playwright projects, follow [references/playwright.md]" and "Return only the `factory.qa.v1` template in [references/output.md]". Playwright-specific patterns and the output template are appropriately split out of the main file, and the references do not nest further.

Specificity

The description lists multiple concrete actions that comprehensively cover the skill's capabilities: "prove one task's acceptance criteria with observable end-to-end tests against the real product", "record a test plan and a test-gap ledger", and "capture screenshots for the pull request". No generic filler; not score 4 because the coverage is comprehensive rather than having minor gaps.

Completeness

Clearly answers both what ("Prove one task's acceptance criteria with observable end-to-end tests… record a test plan and a test-gap ledger… capture screenshots") and when ("Use for the QA stage, after work and before review, when FACTORY.json enables stages.qa") with an explicit, concrete trigger clause.

Trigger Term Quality

Good natural keyword coverage: "acceptance criteria", "end-to-end tests", "test plan", "screenshots", "pull request", "QA stage", "FACTORY.json", "stages.qa". Not score 5 because common synonyms and variations are missing (e.g. "E2E tests", "QA testing", "regression"); not score 3 because coverage goes well beyond "some relevant keywords".

Distinctiveness Conflict Risk

Clear niche with distinct, gated triggers: the QA stage of a factory pipeline, positioned "after work and before review" and gated on "FACTORY.json enables stages.qa". It names skill-specific artifacts (test-gap ledger) that no generic testing or review skill would claim, so conflict risk is minimal.