Conciseness

Nearly every line carries non-obvious information Claude would not already know — "Updates run at most every 300ms", "First line of stdout becomes the status line text", "JSON context passed via stdin", "chmod +x", the mock-JSON test command, and the no-restart note. There is no padding, no explanation of basic concepts, and the field table stays minimal while deferring the full schema to a reference file; every token earns its place.

Actionability

The guidance is fully executable and copy-paste ready: the exact `.claude/settings.json` block, a working bash template using jq and tput, the `chmod +x` command, and a runnable test command (`echo '{"model":{"display_name":"Test"}}' | ./statusline.sh`). Common cases beyond the simple template (git-aware, context usage, cost tracking) are covered by named example reference files, so there are no gaps in covering the common cases.

Workflow Clarity

All steps are present and unambiguous — write the script from the template, make it executable, add the settings.json config, test with mock JSON, and inform the user that no restart is needed — and the mock-JSON test acts as a validation checkpoint (this is not a destructive or batch skill, so no cap applies). Not 5 because the steps are laid out as parallel sections rather than an explicitly sequenced workflow, and testing appears under "Tips" as an optional suggestion rather than an explicit checkpoint.

Progressive Disclosure

Good structure: a mandatory "You MUST read the reference files" section lists five clearly described, one-level-deep reference files (all verified to exist with no nested references), and the quick-reference field table appropriately defers to json-schema.md. Not 5 because the bundle contains a sixth reference file, example-git-context-remaining.md, that is never linked from SKILL.md, leaving it undiscoverable from the overview — a minor organization gap.

Specificity

The description names the domain and several concrete actions — "create a statusline", "customize the status line", "display git branch, context usage, model name, or session costs" — with only minor coverage gaps. It is not 3 (more than 1-2 concrete actions are listed) but not 5 because the actions appear only as quoted user-trigger phrasings; the skill never states its own capabilities declaratively (e.g., "Create custom status lines that display contextual information").

Completeness

The "when" is explicit and rich ("This skill should be used when the user asks to... Also suggest when the user wants to display..."), satisfying the use-when requirement, and the "what" is legible through the quoted actions. Not 5 because the "what" is never directly stated as a capability statement — it is only implied via trigger phrases — which mirrors anchor 4's one-side-could-be-more-explicit profile rather than a fully explicit what-and-when.

Trigger Term Quality

Good natural keyword coverage including both spellings ("statusline" / "the status line") and data-type triggers users would actually say ("git branch", "context usage", "model name", "session costs"). Not 5 because a few natural variations are missing (e.g., "status bar", "show token usage") and "add a custom prompt" is a phrase users would more naturally use for prompt customization than for a statusline.

Distinctiveness Conflict Risk

"Claude Code statusline" carves a clear niche with distinct triggers, so conflict risk is low overall. Not 5 because "add a custom prompt" creates minor overlap risk with closely related prompt/customization skills — a user asking to add a custom prompt usually means something other than a statusline.