skill: guard prop and colour names in examples, not just component and icon names

[IgorShevchik]

Background

Follow-up from #93 / PR #343.

test/utils/skill-manifest.spec.ts now validates every identifier an example uses: B24* / Prose* component names against src/runtime/components/**, icon imports against @bitrix24/b24icons-vue's info-metadata.json, links, the manifest, and routing in both directions. What it cannot see is props and prop values, and #343 had to fix several of those by hand:

defect	files	why it is invisible
variant="ghost" on B24Button	task-form.md ×5, landing.md ×2	there is no variant prop; the attribute falls through as a dead DOM attribute, so the intended styling silently never applies
color="neutral" on B24Button	landing.md ×2	matches no key in src/theme/button.ts
'neutral' on B24Badge	data-tables.md	same, for src/theme/badge.ts — every "Inactive" row rendered uncoloured
mode="drawer" on Modal/Slideover	component-selection.md	the prop does not exist on either component
form.clearErrors()	forms.md	the exposed method is clear()

All five read as correct. None throws. Three of them were contradicted by another file in the same package — forms.md already stated "B24Button has no variant prop — pick a color", two files away from seven usages of it.

Why this is worth doing mechanically

The same argument as the component-name check that already exists. Prose does not compile, so the only thing standing between an agent and a dead attribute is a human noticing — and the evidence says humans did not, for months, in a package whose entire purpose is to be correct.

Sketch

Both halves are already available at test time:

• Colours. src/theme/<component>.ts exports the color variant map. For a fenced example, match <B24X … color="Y"> and assert Y is a key of that component's map. Deprecated bare names (success, secondary, …) still resolve, so they should probably warn rather than fail, or be allowed with a note — the skill's own design-system guideline already says to prefer air-*.
• Props. Harder, and probably not worth a full parse. A cheap 80% version: collect the prop names declared in each component's Props interface and assert every kebab-or-camel attribute in a <B24X …> tag is either one of them, a known global (class, style, id, v-*, @*, :* bindings of the above), or a slot/template directive. Expect false positives from v-bind spreads and fall-through attributes, so it likely needs an escape hatch.

Start with colours: it is a closed set, exactly matches how three of the five defects failed, and needs no prop parsing at all.

Not in scope

General prose quality (typos, duplicated paragraphs). #93's EN sweep found several — "for find icons", "ou are using", a paragraph stated twice — and those are not mechanically checkable without a spellchecker dependency, which is a heavier ask than this guard's spirit.

[IgorShevchik]

Widening the scope note: this issue was written around props and colour values, and the #346 review rounds found two more fact-classes of exactly the same shape that it does not currently cover.

CSS custom properties. design-system.md told readers to set --b24ui-header-heights in main.css. The variable is singular everywhere it is actually declared — src/runtime/index.css, src/theme/header.ts, the CSS-variables docs page — and this was the only occurrence of the plural form in the repository. Setting it does nothing, silently.

Composable option names. conventions.md documented whenever: [isFormValid] on a defineShortcuts entry. ShortcutConfig has exactly two fields, handler and usingInput; whenever is an upstream nuxt/ui idiom with no counterpart in this fork. The unknown key is ignored, so the shortcut fires unconditionally — the guard reads as present and does nothing.

Both are the same shape as the props and colours already listed: a name inside a fenced code block, contradicted by src/, that renders and runs without complaint. Neither is reachable by anything in test/utils/skill-manifest.spec.ts — the checks there validate component names, icon imports, links, routing and the manifest, all of which are identifiers the module registers, not values passed to them.

So the sketch in the issue body should read: colours (from src/theme/*.ts colour maps), CSS custom properties (from the real --b24ui-* declarations), and prop/option names (from the component Props interfaces and composable config types).

The colour check remains the right place to start — it is a closed set, needs no parsing, and covers three of the six defects found so far. A CSS-custom-property check is the cheapest sibling: grep the declared --b24ui-* tokens, assert every one referenced under skills/ exists. That is the same ~20-line shape as the existing icon check, and it would have caught --b24ui-header-heights directly.

Prop and option names are the harder half and probably want a separate pass — see the issue body's own note about v-bind spreads and fall-through attributes.

Context: #344 is closed, #346 delivers the generated manifest. Nothing there bears on this issue; it is still the right next thing to build, and it targets the failure mode that matters most here — these render fine and are wrong, where a missing manifest entry at least resolves to nothing.

---

Generated by Claude Code