/schema-validator

name: schema-validator
description: "Validate token files against DTCG 2025.10, Style Dictionary, or custom schemas. Trigger when someone says: validate token JSON, check my token files for errors, schema validation for tokens, are my token files valid, DTCG compliance check, validate token format, or anything about checking whether token files are structurally correct before they break builds."
references:
  - ../../knowledge-notes/token-architecture.md
  - ../../knowledge-notes/output-discipline.md

Schema validator

A skill for validating that design token files conform to their expected format — DTCG 2025.10, Style Dictionary v3/v4, Tokens Studio, or a custom schema. Catches structural issues before they break build pipelines, cause silent failures, or produce incorrect output.

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

Check for `.ds-ops-config.yml` in the project root. If present, load:

• `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

**Style Dictionary v4** (`integrations.style_dictionary.enabled: true`):

• Run `npx style-dictionary build --config [path] --dry-run` to get Style Dictionary's own validation errors
• Cross-reference Style Dictionary errors with this skill's findings for completeness

If no config exists, proceed with defaults.

---

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** (JSON with DTCG alignment, `$value` property)
• **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:

| File | Format detected | Tokens | Parse status | |------|----------------|--------|-------------| | colors.json | DTCG 2025.10 | 47 | ✓ Parsed | | spacing.json | Style Dictionary v3 | 12 | ✓ Parsed | | broken.json | Unknown | 0 | ✗ Parse error: unexpected token at line 23 |

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 present** — every token must declare `$type` (or inherit from a parent group's `$type`) 3. **$type values valid** — must be one of: color, dimension, fontFamily, fontWeight, duration, cubicBezier, number, strokeStyle, border, transition, shadow, gradient, typography, fontStyle 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** — composite types (border, shadow, typography, transition, gradient) must have correct sub-properties 9. **Color values valid** — hex, RGB, HSL, or named colour that resolves correctly 10. **Dimension values valid** — number + unit (px, rem, em, etc.) 11. **Group $type inheritance** — if a group declares `$type`, all children without their own `$type` inherit it 12. **No `$` prefix on non-spec properties** — custom properties should not start with `$` to avoid confusion with spec properties 13. **Extensions namespace** — custom metadata should live under `$extensions` if present

Style Dictionary v3 checks

1. **`value` required** — every leaf token must have a `value` property