Conciseness

Every sentence carries codebase-specific facts with no padding about concepts Claude already knows, but the dense multi-clause prose (e.g., "What Gets Resolved" bullets such as "resolve each token once, and reparse before policy defaults/validation; typed `oauth` and deferred directives are mutually exclusive" pack 5+ rules per item) and repeated empty-token/CR-LF and re-expansion warnings across the resolution, cookie, and transform sections mean the body could be tightened considerably. This matches "mostly efficient but could be tightened" rather than the minor-trim profile of a 4.

Actionability

Concrete caddyfile snippets ("password {env.SMTP_PASSWORD}", "secrets:<secret_id>:<key>"), exact function/test names (`ResolveRuntimeAppConfig`, `cfgutil.DecodeArgs`/`EncodeArgs`, `TestResolveRuntimeAppConfig`), field-level resolution lists, and a precise fixture convention (`<prefix>.Caddyfile`, `<prefix>.env`, `<prefix>_resolved.json`) make the guidance executable. It falls short of a 5 because no worked fixture example shows a source config and its resolved output side by side.

Workflow Clarity

The Guidance section sequences the key task ("check the authcrunch struct and validation path first", then `cfgutil.DecodeArgs`, replace each argument, `cfgutil.EncodeArgs`, and validation, or "explicit assignment in `caddyfile_resolve.go`"), and validation checkpoints are pervasive and explicit ("reject collisions before replacing the map", "Reject empty arguments and report the field/statement index without including secret values", "verifies a missing secret leaves the old deployment usable"). It is below a 5 because the main resolution workflow must be assembled from dense prose rather than an ordered, checklisted sequence.

Progressive Disclosure

There are no bundle files; the body is header-sectioned and delegates adjacent topics via clearly signaled, one-level links to sibling skills ("See [persistent runtime state](../configuration-state/SKILL.md)", "[cookie configuration](../configuration-authentication-cookies/SKILL.md#placeholders-and-json)", "[OAuth reference](../configuration-oauth-providers/references/shared-parser.md#runtime-references)"). The ~250-line monolithic body keeps it below the clear-split anchor 5 but comfortably above anchor 3 since references are clearly signaled and structure is good.

Specificity

"Configure and validate Caddy runtime placeholders, secret lookups, encoded instructions, and resolved fixtures" names the domain and several concrete actions (configure, validate, "determine which fields resolve and preserve exact values"), matching the anchor for several specific actions with minor gaps. It is below a 5 because coverage is incomplete relative to the skill's full scope (claim templates, cookie/token-refresh/OAuth snapshot handling are absent), and above a 3 because it lists more than 1-2 actions.

Completeness

The "what" is explicit (configure and validate placeholders, secret lookups, encoded instructions, resolved fixtures), and "Use to determine which fields resolve and preserve exact values" provides explicit trigger guidance, so it is not capped at 3. It falls short of a 5 because the "when" clause names only one narrow task rather than concrete user-mentionable trigger conditions.

Trigger Term Quality

"Caddy runtime placeholders", "secret lookups", and "fields resolve" match the natural vocabulary a user of this codebase would say. Good keyword coverage but a few natural terms are missing ("environment variables", "{env.*}" syntax), so it fits anchor 4 rather than the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

"Caddy runtime placeholders, secret lookups" carves out a clear niche, and "manager blocks belong to secrets" explicitly de-conflicts with the sibling secrets skill. Minor overlap risk remains with closely related sibling config skills (state, cookies, OAuth providers), matching anchor 4 rather than the minimal-conflict anchor 5.