# Contract Consistency Validation

> Use when user modifies public interfaces/APIs, changes behavior of exposed methods, or requests compatibility checks. Validates breaking changes, requires user confirmation, enforces SemVer, and mandates ADR for pre-1.0 relaxations or v1+ exceptions.

- Skill: `tomevault-io/contract-consistency-validation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/contract-consistency-validation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/contract-consistency-validation/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/contract-consistency-validation

---


# Contract Consistency Validation

## Overview

Ensure contract changes are validated for compatibility and breaking changes are confirmed before implementation.

**REQUIRED:** superpowers:test-driven-development, superpowers:verification-before-completion

## When to Use

- Modifying public interfaces, APIs, or shared contracts
- Changing behavior of exposed methods (null handling, error codes)
- Preparing releases with interface changes
- Modifying method signatures, return types, or error handling

## Core Workflow

1. **Detect contract change** (interface, behavior, schema modification)
2. **Classify change type:**
   - **Additive:** New optional fields/endpoints (Minor bump)
   - **Breaking:** Removed fields, behavior changes, signature changes (Major bump)
   - **Deprecation:** Marking for future removal (Minor bump + documentation)
3. **For breaking changes:**
   - Flag explicitly and **halt**
   - Assess consumer impact
   - Present alternatives (versioning, deprecation, additive)
   - **Require explicit user confirmation**
4. **For pre-1.0 relaxation:** Require ADR documenting scope and consequences
5. **For v1+ exceptions:** Require justification, approvals, and rollback plan
6. **Update artifacts:** OpenAPI specs, schemas, CHANGELOG with migration guidance

See [Breaking Change Checklist](references/breaking-change-checklist.md) and [Contract Testing Strategies](references/contract-testing-strategies.md).

## Rationalizations Table

| Excuse                                 | Reality                                                 |
| -------------------------------------- | ------------------------------------------------------- |
| "Adding fields is always safe"         | Consumers with strict schemas reject unexpected fields  |
| "Product owner approved"               | Product approval does not override technical validation |
| "Pre-1.0 allows anything"              | Allowed, but requires ADR and documentation             |
| "Behavior improvement justifies break" | Better design does not make it non-breaking             |

## Red Flags - STOP

- "Adding fields is safe" (without validation)
- "Customer approved the change"
- "Pre-1.0 so anything goes"
- "Just need to ship this"

**All mean: Validate compatibility, require user confirmation.**

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/mcj-coder) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-14 -->