056-design-avoid-breaking-changes

Featured

Use 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

Web & Frontend 423 stars 89 forks Updated 3 days ago Apache-2.0

Install

View on GitHub

Quality Score: 93/100

Stars 20%
87
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Avoid Breaking Changes Review planned repository changes for breaking-change and compatibility risk before implementation or release promotion. **This is an interactive SKILL**. **What is covered in this Skill?** - Command contract compatibility: names, inputs, owning agents, outputs, safeguards, installer registration, and command inventories - Skill routing compatibility: identifiers, metadata, descriptions, triggers, references, generated local output, and acceptance coverage - Generated-output ownership: XML/source files versus `.agents/skills`, public `skills/`, `.cursor/commands`, `.cursor/rules`, and `docs/` - Source and generator contracts: XML, XInclude, XSLT, Maven modules, schema expectations, and module validation - README, localized README, changelog, migration, and deprecation guidance - External and runtime contracts: APIs, schemas, data formats, configuration keys, persistence, CLI behavior, and CI expectations - Structured compatibility reports with severity-ranked findings and validation guidance ## Constraints Keep the review evidence-based, read-only, and scoped to compatibility risk unless the user explicitly asks for implementation. - **MUST** read `references/056-design-avoid-breaking-changes.md` before producing compatibility guidance - **MUST** identify the source artifacts reviewed and the compatibility surfaces considered - **MUST** distinguish confirmed breaking changes, potential risks, non-breaking changes, and unknowns that need maintain...

Details

Author
jabrena
Repository
jabrena/plinth
Created
1 years ago
Last Updated
3 days ago
Language
Java
License
Apache-2.0

Integrates with

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Featured

042-planning-openspec

Use when creating or updating OpenSpec change artifacts from an issue, implementation plan, approved design, ADRs, existing OpenSpec artifacts, or a valid combination. The workflow assesses whether the scope is one change or multiple changes, records sources and derivation direction, and prevents silent synchronization. This should trigger for requests such as Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes. Part of Plinth Toolkit

423 Updated 3 days ago
jabrena
API & Backend Listed

api-break-check

Review an API change for backward-incompatible breaking changes before it ships and breaks existing consumers — removed or renamed fields, added required request parameters, narrowed types, tightened validation, changed status codes or error shapes, removed enum values, and (for gRPC) changed field numbers. Explains who breaks and why, then rewrites the change to be compatible: additive evolution, deprecate-then-sunset, or a new version with expand/contract. Use whenever writing, reviewing, or about to merge a change to an API contract — an OpenAPI / Swagger spec, a GraphQL schema, a protobuf / gRPC definition, or the handlers/DTOs/serializers behind them — especially for an API with consumers you don't control.

0 Updated 6 days ago
windchillscalanthes-ship-it
Code & Development Listed

skill-craft-review

Use when reviewing, auditing, or giving feedback on an agent skill (SKILL.md file), slash command, or plugin — before merging or publishing one, when a skill never triggers, misfires, or bloats context, or when asked whether a skill or plugin is well designed, safe to approve, or ready to ship.

0 Updated 4 days ago
MuhammadBahaa