056-design-avoid-breaking-changes
FeaturedUse when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review breaking changes in this spec; Check compatibility risks; Avoid breaking changes in this OpenSpec change; Review migration impact before release; Assess command and skill compatibility. Part of Plinth Toolkit
Install
Quality Score: 92/100
Skill Content
Details
- Author
- jabrena
- Repository
- jabrena/plinth
- Created
- 1 years ago
- Last Updated
- today
- Language
- Java
- License
- Apache-2.0
Integrates with
Bundled in these plugins
Similar Skills
Semantically similar based on skill content — not just same category
breaking-change-review
Use when reviewing changes to public APIs, events, configuration, feature flags, CLI behavior, schemas, or migrations for compatibility impact.
042-planning-openspec
Use when creating or updating OpenSpec artifacts from an issue, plan, approved design, ADRs, existing OpenSpec, or a valid combination. The workflow assesses reviewable scope, records source authority and derivation, handles conflicts, and prevents silent synchronization. Triggers include Create OpenSpec from an issue; Convert a plan into OpenSpec; Update an OpenSpec change; Split broad requirements into reviewable changes. Part of Plinth Toolkit
design-review
Review a plan or spec before any code exists. Use when a design doc is ready, before implementation starts, or when asked whether an approach is sound. Catches what code review cannot fix later — one-way doors, migration order, rollback, and what the plan omitted. Read-only.