Schema Validator

Schema validator

A skill for validating that design token files conform to their expected format — DTCG 2025.10 (token files and resolver documents), Style Dictionary 3, 4 or 5, Tokens Studio, or a custom schema. Catches structural issues before they break build pipelines, cause silent failures, or produce incorrect output.

Before you begin: verify references

Confirm that every path in this skill's frontmatter references: exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example npx skills install) dropped the repo-root knowledge-notes/ directory. Tell the user to reinstall by a method in 1-INSTALL.md and run verify-install.sh from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

Context

Token files are infrastructure. When a token file is malformed — a missing $type declaration, a $value that resolves to nothing, an alias that points to a deleted token — the failure mode is rarely loud. The build might still succeed. The wrong value might ship. The design intent might be silently lost.

Schema validation is the first line of defence. It answers a simple question: do these files meet the structural contract they claim to meet? A DTCG file must have $value on every token. A Style Dictionary file must have valid reference syntax. A Tokens Studio export must preserve group hierarchy.

This skill is not about naming conventions or architectural quality — those belong in token-audit. This skill is about structural integrity: can the file be parsed, transformed, and consumed by downstream tools without error?

Boundaries

This skill validates token file structure only. It does not assess naming quality (use naming-audit), token architecture health (use token-audit), or token usage in code (use token-compliance). If the token source format is not recognisable as DTCG, Style Dictionary, Tokens Studio, or a declared custom schema, ask the user to identify the format before proceeding. If no token files are provided or accessible, there is nothing to validate — stop and confirm the file location with the user.

---

Configuration

If .ds-ops-config.yml exists, follow the configuration-and-recurring knowledge note (../../knowledge-notes/configuration-and-recurring.md) for loading, integration fallbacks and recurring runs. This skill reads:

• system.token_format — pre-selects the primary format to validate against (dtcg, style-dictionary-v3, style-dictionary-v4, tokens-studio, custom)
• integrations.style_dictionary — if enabled, use Style Dictionary's built-in validation as a cross-check
• severity.schema_* — overrides for finding severity (e.g. schema_missing_type: critical)

Auto-pull integrations

Run the tool the repo already has, first. Hand-validation is the fallback, not the method.

• Style Dictionary 4 or 5 (integrations.style_dictionary.enabled: true, or a config file in the repo): run npx style-dictionary build --config [path] into a scratch output directory to get its own reference and parse errors. Version 5 reads DTCG natively; version 4 needs usesDtcg: true; version 3 uses value/type and doesn't read DTCG at all.
• Terrazzo (a terrazzo.config.* file, or @terrazzo/cli in package.json): run npx terrazzo lint for DTCG validation and npx terrazzo build for alias resolution.
• Reconcile: every error the tool reports appears in this report with the tool named as its source; anything this skill finds that the tool didn't is reported as this skill's own check.

---

Step 1: Identify files and target format

Ask for or confirm:

1. Path to token files — directory or specific files to validate
2. Target format — which specification to validate against:
   • DTCG 2025.10 (W3C Design Token Community Group specification)
   • Style Dictionary v3 (legacy JSON with value property)
   • Style Dictionary v4 or v5 (JSON with DTCG alignment, $value property; v5 reads DTCG natively)
   • Tokens Studio (Figma Tokens plugin export format)
   • Custom — if custom, ask for the schema or describe the expected structure
3. Strictness level — strict (every violation is an error) or lenient (warnings for non-critical issues)

If the token files contain format indicators (e.g., $type fields suggest DTCG), auto-detect the format and confirm with the user.

Step 2: Parse and inventory

For each file in the provided path:

1. Attempt to parse — JSON, YAML, JS module, or CSS custom properties
2. Record parse status — parsed successfully, failed with error, or empty file
3. Count tokens — total token definitions found
4. Identify format signals — which format the file appears to use (based on property names, structure)

Produce the file inventory:

Figures in this and later examples are illustrative.

Step 3: Validate against target format

For each successfully parsed file, run format-specific validation:

DTCG 2025.10 checks

1. $value required — every leaf token must have a $value property
2. $type resolvable — resolve each token's type in order: its own $type; if its value is an alias, the resolved type of the target; otherwise the closest parent group's $type. Flag only tokens with none of these.
3. $type values valid — must be one of the 13 DTCG 2025.10 types listed in the token-architecture note. fontStyle is not a type.
4. $description optional but typed — if present, must be a string
5. Alias syntax correct — aliases must use {group.token} syntax with curly braces
6. Alias targets exist — every alias must resolve to a real token (no broken references)
7. No circular aliases — alias chain must terminate at a concrete value
8. Composite token structure — the six composite types (strokeStyle, border, shadow, typography, transition, gradient) must have correct sub-properties; strokeStyle also accepts a plain keyword such as "dashed"
9. Value shapes — in 2025.10, color is an object (colorSpace, components, optional alpha and hex), dimension is { value, unit } with px or rem only, and duration is { value, unit } with ms or s (see the token-architecture note). String values such as "#ff0000" or "16px" are the older draft format: report them as a migration item, not a broken file.
10. Units valid — em, % and other units in a dimension are outside the spec; flag them
11. No $ prefix on non-spec properties — custom properties should not start with $ to avoid confusion with spec properties
12. Extensions namespace — custom metadata should live under $extensions if present, keyed by reverse-domain name
13. Name rules — token and group names must not begin with $ and must not contain {, } or .; a dotted name breaks alias syntax and is an error, not a style point
14. $deprecated — if present, must be true, false or a string; a group's value applies to its children unless a token overrides it