feat(skills): document the Colors component

[papelipe]

Q	A
Branch?	main
Bug fix?	no
New feature?	yes
BC breaks?	no
Fixed tickets	#...

The Colors component was in no skill at all. Worse, components.md actively pointed the other way — "color" was the headline example for when to use a Selection:

- | Predefined dropdown or multi-select (color, size, material) | **Selection** |
+ | Predefined dropdown or multi-select (size, material, fit)   | **Selection** |

So an agent modelling colour would reach for a dropdown of colour names and never learn the component exists. This adds Colors to the content model and corrects the advice around it.

The modelling point

One colour entry carries several notations of the same colour at once — hex and rgb for screen, cmyk and pantone for print, ral for paint and industrial — plus a label. And the component is a list, so one component holds a whole colourway.

That is what makes it a content-modelling concern rather than a field type. Splitting those notations across Single Line components guarantees they drift apart the first time a colour is corrected, and modelling a colourway as several components guarantees they fall out of order.

The second decision, which gets its own section because it is the one people get wrong:

You need	Use
The actual colour, to render (swatch, chip, 3D configurator)	Colors
A stable token to filter, facet and build URLs on	Selection or a Topic
Both — the normal case for fashion, paint, furniture, packaging	Both, deliberately

A hex is a poor facet: shoppers pick "Red", not #B22222, and two near-identical hexes will not collapse into one bucket. The filterable token and the renderable value are different jobs.

Where it landed

File	Added
content-model/references/components.md	New "I need to store a colour" scenario; "Colors vs Selection"; corrected Selection example; rows in the localization-defaults and validations tables; a flowchart branch; a Discoverability note
content-model/references/create-shape-api.md	colors in the ComponentType enum; full config block (min/max, requireLabel, colorPresets, customColorSpaces)
mutation/references/core-api.md	updateComponent example, including the doubled colors: { colors: [...] } key
query/references/catalogue-api.md	Reading ColorsContent, and the nullability of every notation
data-creation/SKILL.md	Added to the skip list — entries are structured objects, not strings
content-model/SKILL.md	Trigger words in the description, so "how do I model colour" reaches this skill

Verified

Against the live Core API — ColorsComponentConfig, ColorsComponentContentInput, GraphqlInputColorEntry, the ColorSpace enum (cmyk | hex | hsl | pantone | ral | rgb) — and the Catalogue API (ColorsContent, ColorEntry). colors is also present in NestableComponentInput, so it works inside chunks, choices and pieces; that is stated.

Deliberately absent

How a discoverable colors component is indexed in Discovery. The access token available here could not read shapes on any tenant that uses the component (FORBIDDEN), so the generated field name and subfields are unverified. The guidance does not depend on the answer — filter on the name, not the value — so rather than guess at a field shape, it is left out. Worth filling in by someone who can see an indexed tenant.

One inference is flagged here rather than in the file: the multilingual default row in the localization table is given as ✗ False, matching every comparable value component. The config field exists and is settable; the platform default was not verified.

Notes

• No plugin version bump, to avoid colliding with feat(skills): add vector-ranking skill #3, which bumps to 3.6.0. Worth bumping on whichever merges last.
• Branched from main, so it is independent of feat(skills): add vector-ranking skill #3, fix(skills): repair three broken reference links #4 and fix(skills): stop make codeclean from corrupting the templating reference #5 and touches no file they touch.

🤖 Generated with Claude Code