/schema-validator

name: schema-validator
description: "Validate token files structurally against DTCG 2025.10 (including resolvers), Style Dictionary 3 to 5 or Tokens Studio: parse errors, $type/$value, name rules, broken or circular aliases. Trigger: validate token JSON, DTCG compliance, are my token files valid. Naming or architecture: token-audit."
allowed-tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(sort:*), Bash(tail:*), Bash(wc:*), Bash(npx style-dictionary:*), Bash(npx terrazzo:*)
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 (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:

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

Figures in this and later examples are illustrative.

Step 3: Validate against target format

For each successfully parsed fi