What's wrong
plugins/claude-ops/skills/plugins/SKILL.md explains the unset-state behavior of
${user_config.install_new} in a sentence that itself contains that placeholder (line 145):
So for the common
default-config user — no `pluginConfigs` set anywhere — this line renders as the **literal
placeholder text** `${user_config.install_new}`, unchanged.Claude Code substitutes every occurrence, so when the key IS set the paragraph renders as:
this line renders as the literal placeholder text all, unchanged.
which asserts something false about its own rendering, immediately after line 138 has already
rendered **Configured value: all**. The reader cannot tell substitution apart from a literal —
both occurrences say the same word either way.
Why it matters
Step 4 of sync branches on this line's rendered value. Getting it wrong picks the wrong
new-plugin install policy: reading a set all as the unset state silently downgrades to ask, and
reading an unset placeholder as a value would flag a bogus invalid-value.
Hit live during a /claude-ops:plugins sync run. Resolving it needed a round-trip out to the raw
on-disk SKILL.md to check whether the source contained ${user_config.install_new} or the literal
word — an avoidable verification step the paragraph exists to prevent.
Suggested fix
Make the explanatory sentence name the placeholder without embedding it — describe its shape rather
than reproducing it (e.g. "renders as the literal user_config placeholder, unchanged"), or escape
the occurrence so it survives substitution. Line 138's **Configured value:** occurrence is the one
that must stay live; every occurrence in the surrounding prose is explanatory and should not
substitute.
Worth checking whether any other skill's userConfig documentation carries the same shape.
Notes
Found alongside #2520 during the same session; deliberately filed separately to keep that PR
single-purpose.
What's wrong
plugins/claude-ops/skills/plugins/SKILL.mdexplains the unset-state behavior of${user_config.install_new}in a sentence that itself contains that placeholder (line 145):Claude Code substitutes every occurrence, so when the key IS set the paragraph renders as:
which asserts something false about its own rendering, immediately after line 138 has already
rendered
**Configured value: all**. The reader cannot tell substitution apart from a literal —both occurrences say the same word either way.
Why it matters
Step 4 of
syncbranches on this line's rendered value. Getting it wrong picks the wrongnew-plugin install policy: reading a set
allas the unset state silently downgrades toask, andreading an unset placeholder as a value would flag a bogus invalid-value.
Hit live during a
/claude-ops:plugins syncrun. Resolving it needed a round-trip out to the rawon-disk
SKILL.mdto check whether the source contained${user_config.install_new}or the literalword — an avoidable verification step the paragraph exists to prevent.
Suggested fix
Make the explanatory sentence name the placeholder without embedding it — describe its shape rather
than reproducing it (e.g. "renders as the literal
user_configplaceholder, unchanged"), or escapethe occurrence so it survives substitution. Line 138's
**Configured value:**occurrence is the onethat must stay live; every occurrence in the surrounding prose is explanatory and should not
substitute.
Worth checking whether any other skill's
userConfigdocumentation carries the same shape.Notes
Found alongside #2520 during the same session; deliberately filed separately to keep that PR
single-purpose.