hard-cut

Replace legacy outward contracts with a single canonical contract by removing compatibility logic.

3|Updated Apr 14, 2026
One-click install
npx skills add https://github.com/joshka0/foxctl --skill hard-cut-joshka0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hard-cut
Source: https://github.com/joshka0/foxctl/tree/main/configs/skills-pack/hard-cut
Command: npx skills add https://github.com/joshka0/foxctl --skill hard-cut-joshka0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The hard-cut skill helps you intentionally remove legacy compatibility logic so your project uses one clean, canonical contract instead of carrying transitional shapes.

Core Features & Use Cases

  • What I do: Plan and guide a deliberate break from an old outward contract to a single canonical shape with no fallback, shims, or adapters.
  • Scope of change: Applies to user-facing surfaces like APIs, routes, events, UI/CLI commands, configuration shapes, prompts, docs, fixtures, and tests.
  • Use case: You are replacing an old set of API field names and route patterns with a new product noun and schema, and you want every producer/consumer/docs/tests to match only the new contract.

Quick Start

Use it when you want to refactor your system by replacing the legacy contract with a single canonical shape and explicitly removing compatibility behavior.

Frequently Asked Questions about hard-cut

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

FAQPage Schema
How do I remove legacy API compatibility logic and enforce a single canonical contract?

To remove legacy API compatibility logic, you replace transitional shapes with a canonical contract by eliminating fallbacks, shims, aliases, and dual-shape runtime behavior. This ensures all producers, consumers, and tests match only the new schema.

When should I do a hard cut instead of maintaining backward compatibility for schema migrations?

A hard cut for schema migrations is appropriate when backward compatibility is explicitly not desired. You apply it to intentionally break legacy outward contracts, removing transitional shapes and dual-runtime behavior to simplify the canonical schema.

What is the best way to break contract changes across routes, events, and configuration shapes?

The best way to break contract changes is replacing the legacy outward contract with a single canonical shape. This removes compatibility logic across routes, events, and configuration shapes while updating all docs and examples to match.

How do I update producers and consumers when deprecating legacy API field names?

To update producers and consumers during legacy API deprecation, you enforce no fallbacks or legacy discriminator branches. All components, fixtures, and tests are updated to match only the new canonical contract.

Can I use this approach to break contracts for prompts, fixtures, and CLI commands?

Yes, you can break contracts for prompts, fixtures, and CLI commands. The approach applies to user-facing surfaces, removing compatibility logic and legacy branches to ensure they match only the canonical contract.

What limitations exist when removing shims and aliases during a legacy deprecation?

Limitations include enforcing no fallbacks, shims, aliases, or dual-shape runtime behavior. You must update all producers, consumers, docs, and examples simultaneously, as no backward compatibility is maintained during the legacy deprecation.