What problem does it solve?
Use this skill before editing code when the task changes runtime behavior or anything that might look like a compatibility concern. The goal is to keep implementations simple while protecting real released contracts.
Core Features & Use Cases
- Identify the surface you are changing: released public API, unreleased branch-local API, internal helper, persisted schema, wire protocol, CLI/config/env surface, or docs/examples only.
- Determine the latest release boundary from origin first, and only fall back to local tags when remote tags are unavailable: BASE_TAG from origin should guide compatibility decisions and avoid churn on unreleased work.
- Judge breaking-change risk against that latest release tag, not against unreleased branch churn or post-tag changes already on main, and note if the result may be stale if local tags are used.
- Prefer the simplest implementation that satisfies the current task, and update callers, tests, docs, and examples directly instead of preserving superseded unreleased interfaces.
- Add a compatibility layer only when there is a concrete released consumer, an otherwise supported durable external state boundary that requires it, or when the user explicitly asks for a migration path.
Quick Start
Identify the surface you are changing, determine the latest release boundary, assess breaking-change risk, and implement the simplest compatible solution with updated tests/docs.
