Conciseness

The body is dense with earned, non-obvious rules ("Imported functions and mocks are not smoke checks", "hidden duplicates (mobile menus, templates) cause false failures") and contains no explanations of concepts Claude already knows — every line instructs, fitting the lean anchor 5 rather than anchor 4's "minor instances of over-explanation".

Actionability

Concrete copy-paste commands ("npx ai-devkit@latest memory search --query \"<project> smoke setup\" --tags \"smoke\"\", "git diff against the base branch") plus exact assertion requirements ("asserts output, files, HTTP status, or exit code, not just 'it ran'; API checks also assert the body and one error case") make the guidance fully executable, with the code bulk correctly delegated to the real, verified template files.

Workflow Clarity

The 8-step workflow has an explicit error-recovery feedback loop ("On a failure, first rule out a wrong check (selector, timing, setup), then rerun it on the base commit in a separate worktree") plus validation checkpoints ("wait until they respond", "read it [the screenshot] before judging a failure", "say what was not checked instead of faking a pass"), matching anchor 5.

Progressive Disclosure

The ~38-line body stays an overview while the executable bulk lives in well-signaled, condition-scoped, one-level-deep references — "references/smoke-template.sh (CLI, API) or references/web-smoke-template.mjs (browser)" — both verified to exist as real 121/117-line template files, matching the clear anchor-5 structure.

Specificity

"Smoke-test the user flows a change affects (CLI, API, UI) end to end with a disposable sandboxed script against the real app" names the action plus mechanism, scope, and mode — richer than the 1-2-concrete-actions anchor (3), but it centers on a single verb rather than the comprehensive multi-action list of anchor 5.

Completeness

The 'what' is explicit ("Smoke-test the user flows a change affects... with a disposable sandboxed script against the real app") and the 'when' is an explicit Use-clause with multiple concrete trigger situations, matching the anchor-5 pattern rather than anchor 4's more generic 'when'.

Trigger Term Quality

"when users ask for a smoke, e2e, or impact check", "before calling a feature or fix done", and "when unit tests pass but the flow is untested" are natural phrases users would say, but common variations like "sanity check" or "integration test" are absent, keeping it below anchor 5's comprehensive synonym coverage.

Distinctiveness Conflict Risk

The niche (disposable, sandboxed pre-completion smoke verification of changed flows) is clear and mostly distinct, but triggers like "e2e" and "impact check" carry minor overlap risk with closely related testing or impact-analysis skills, so it sits at anchor 4 rather than 5.