contract-golden-test

Creates golden tests that detect drift between duplicated contract schemas across packages.

Updated Mar 4, 2026
One-click install
npx skills add https://github.com/gmolike/Claude-Template --skill contract-golden-test-gmolike
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: contract-golden-test
Source: https://github.com/gmolike/Claude-Template/tree/main/.claude/skills/contract-golden-test
Command: npx skills add https://github.com/gmolike/Claude-Template --skill contract-golden-test-gmolike

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires vitest, and includes assets (resource) components.

What problem does it solve? When a contract or schema (Zod schema, type, wire format) is mirrored or shimmed in more than one package, each consumer's unit tests stay green because producer and assertion come from the same local copy — while the copies silently diverge, causing HTTP 400s, ZodErrors on save, or silently skipped records. This Skill sets up a golden test that catches exactly that cross-package drift. ## Core Features & Use Cases - Round-trip pattern: Implements the build → serialize → validate → read sequence, where the save schema validates the serialized wire form (not the in-memory object), crossing a real package boundary at every step. - One shared fixture set: Establishes a single fixture package imported by every consumer, with the test running in each consumer's gate so local copies cannot hide. - Mandatory RED verification: Requires swapping in the old (v1) implementation to prove the test actually fails before trusting it. - Use Case: Your monorepo has an API shim and a web app both re-declaring the same slot layout schema. Roll out the provided Vitest template in each consumer, point it at the shared fixtures, and any future divergence between the copies fails the gate immediately. ## Quick Start Ask the agent to set up a contract golden test for the duplicated schema, following the template in assets/contract.golden.example.ts and the shared fixture set in assets/fixtures.example.ts.

Frequently Asked Questions about contract-golden-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test that duplicated schemas across packages stay in sync?

Create a golden test that runs the round-trip build → serialize → validate → read in every consumer's gate, with all consumers importing one shared fixture set. Serializing with JSON.parse(JSON.stringify(x)) before validation is essential because the API only ever sees the wire payload.

Why do my unit tests pass while the API returns HTTP 400?

Each consumer tests against its own local copy of the contract, so producer and assertion are internally consistent and stay green while the copies diverge. Only a round-trip test crossing a real package boundary catches the divergence between copies.

Should I validate the object before or after JSON.stringify?

Validate after serialization. The save schema must check the wire form, because JSON serialization changes values like Date, undefined, Map, and class instances. Validating the in-memory object first lets exactly those divergences slip through.

Can I copy the shared fixtures into each package and adjust them?

No. The fixture set must live in exactly one package and be imported by every consumer. A copied fixture drifts together with the copy it sits next to, so the test then only confirms the local truth and becomes worthless.

What are the limitations of a contract golden test?

It proves all copies speak the same form, not that the form is correct — a jointly wrong schema stays green. A new shim that forgets the shared fixture import is invisible to the test, and N consumers means N test runs for the same assurance.

Why is a type-only test not enough for contract drift?

Type-only tests using import type are erased at compile time, so the test merely asserts its own literals and stays green even after a field is deleted. The golden test must run at runtime against the real modules.