---
name: golden-file-normalizer
description: Guidance and recipes for writing normalization rules that make SUT output files deterministic for golden-file regression testing. Use when designing or extending the normalizer module, or when diagnosing diff noise.
---

# Golden-file normalizer skill

When writing or reviewing normalization rules for recordingtest, apply this checklist.

## Canonical sources of non-determinism

| Category | Example patterns | Rule strategy |
|----------|------------------|---------------|
| Timestamps | ISO8601, Unix epoch, `"saved": "2026-..."` | Replace with `<TS>` or strip key |
| GUIDs / UUIDs | `xxxxxxxx-xxxx-...` | Replace with `<GUID-N>` (stable index per occurrence) |
| Absolute paths | `C:\Users\...\`, `D:\MYCLAUDE_PROJECT\...` | Replace repo root with `<REPO>`, user with `<USER>` |
| Recent files | `RecentFiles.json` | Empty the list or mask entirely |
| Float precision | `3.14159265358979` | Round to configured epsilon (default 1e-6) |
| Collection ordering | unsorted dict/list | Sort by canonical key |
| Machine name / locale | `DESKTOP-XXXX`, `ko-KR` | Mask or pin |
| GPU/driver hashes | inside render metadata | Strip |

## Rule authoring principles

1. **Rules are versioned** — bump the normalizer profile when adding/removing rules; scenarios pin a profile.
2. **Never hide real bugs** — mask only fields proven non-deterministic across 3+ clean runs.
3. **Text first** — parse JSON/XML semantically; use regex only as fallback.
4. **Bidirectional tests** — every rule has a unit test with before/after samples.
5. **Log what you normalized** — emit a sidecar `normalization.log` listing replacements for diagnostics.

## Output

When the user asks for a new rule, produce:
- Rule name and profile membership
- Regex or parser snippet (C#)
- Unit test sample input/output
- A note on which SUT file(s) it applies to