contract-versioning

Assess schema changes and bump @template/contracts versions with changelog updates.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/dtaborda/startup-saas-template --skill contract-versioning
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: contract-versioning
Source: https://github.com/dtaborda/startup-saas-template/tree/main/skills/contract-versioning
Command: npx skills add https://github.com/dtaborda/startup-saas-template --skill contract-versioning

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforces semantic versioning discipline for the shared @template/contracts package so schema shifts never slip through unnoticed and downstream packages avoid unexpected breaking changes.

Core Features & Use Cases

  • Semantic Versioning Governance: Determine whether schema edits require patch, minor, or major bumps based on optional versus breaking field changes.
  • Change Coordination Workflow: Update the version entry in packages/contracts/package.json, refresh the CHANGELOG.md, and assess impact across consuming packages with the audit checklist.
  • Use Case: When a contract field is renamed or removed, trigger a major bump, document the migration guidance, and confirm every consumer is aligned before release.

Quick Start

Run the contract-versioning skill to assess schema changes, bump the packages/contracts version, and update the changelog with impact notes.

Frequently Asked Questions about contract-versioning

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

FAQPage Schema
How do I determine if a contract schema change needs a major or minor version bump?

Semantic versioning for contract schema changes requires a major bump for breaking field removals or renames, a minor bump for new optional fields, and a patch bump for non-breaking edits. Evaluate field definitions to classify the change.

What is the best way to coordinate breaking changes in a shared contracts package across a monorepo?

Coordinating breaking changes in a shared contracts package involves bumping the version in package.json, updating the CHANGELOG.md with migration guidance, and running an impact audit across all monorepo consumers to confirm alignment before release.

When do I need to update the CHANGELOG.md for monorepo contract modifications?

You need to update CHANGELOG.md whenever schema or field definitions in the contracts package change, documenting whether the modification introduces new contracts, breaking fields, or deprecations alongside the corresponding version bump.

Does semantic versioning governance work for tracking deprecations in monorepo consumer packages?

Yes, semantic versioning governance tracks deprecations by evaluating impact with consumer searches across the monorepo, ensuring downstream packages avoid unexpected breaking changes when contract fields are deprecated or removed.

How to assess the impact of contract field renames on all consuming packages before release?

Assess the impact of contract field renames by triggering a major version bump, documenting migration guidance in the changelog, and performing an audit checklist search across all monorepo consumers to confirm every package is aligned.