happier-compatibility

Audit and verify wire, persistence, and mixed-version compatibility across Happier components.

1.6k|141|Updated Dec 16, 2025
One-click install
npx skills add https://github.com/happier-dev/happier --skill happier-compatibility
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: happier-compatibility
Source: https://github.com/happier-dev/happier/tree/main/skills/happier-compatibility
Command: npx skills add https://github.com/happier-dev/happier --skill happier-compatibility

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Changes to protocols, schemas, migrations, or installers can silently break released clients, servers, and persisted data when old and new versions coexist. This Skill provides a disciplined workflow to classify affected surfaces, establish evidence-backed baselines, and verify upgrade, coexistence, and rollback paths before shipping.

Core Features & Use Cases

  • Surface Classification: Categorize changes as wire, semantic, persistence, operational/installer, or internal-only, and stop early when no external contract is affected.
  • Baseline & Skew Matrix: Resolve immutable release tags and artifacts, then build only the reachable old/new producer-consumer matrix with required, unreachable, or unsupported rationale.
  • Migration Governance: Classify migrations as local-only, development-exposed, or released, enforce append-only rules for published migrations, and define reconciliation paths for development databases.
  • Use Case: When changing a session serialization format, use this Skill to pin the released baseline, prove new-reader/old-writer compatibility with golden-vector tests, and plan a prepare/expand → activate/migrate → contract rollout.

Quick Start

Ask the assistant to audit your planned protocol or schema change for released and mixed-version compatibility risks using the happier-compatibility workflow.

Frequently Asked Questions about happier-compatibility

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

FAQPage Schema
How do I check if a schema change breaks older clients?

Classify the change surface, resolve the released baseline by immutable tag or artifact, then build a skew matrix of old and new producer-consumer directions. Prove each reachable direction with a discriminating contract or golden-vector test before shipping.

How to handle database migrations that were already released?

Released migrations are append-only: never modify their name or bytes. If a published migration is wrong, preserve it and design the smallest forward correction that works from the published state, then verify a clean upgrade from the baseline.

When is a compatibility shim or migration not needed?

When a change is internal-only and leaves external readers, writers, artifacts, and rollout behavior unchanged, no matrix, shim, migration, or compatibility test is required. Local unpublished draft migrations also do not justify product compatibility code.

Does this cover mixed-version client and server deployments?

Yes. New-client/old-server behavior must negotiate capabilities or degrade safely, while old-client/new-server behavior preserves released wire and semantics. Only reachable directions are tested, avoiding Cartesian-product expansion.

What is a split-brain and how is it resolved?

A split-brain is same-concept logic duplicated across producers, parsers, or registries. The workflow consolidates it at the canonical owner, letting compatibility adapters translate historical shapes while delegating domain decisions to that owner.